harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [general] M3 - code frozen
Date Thu, 27 Sep 2007 07:10:40 GMT
Unfortunately I don't have access to a 64 bit Linux at this moment. It
looks like gc completed a major collection successfully and there is
some failure post collection when it is trying to tune heap sizes
based on performance of last collection. Is this a blocking failure? I
don't remember how have we defined blocking failure. If we were to add
x86-64 to M3, it would be under disclaimer only( it's a late decision,
and it looks relatively good ), we can't claim that that it has the
stability of the 32 bit distributions.



On 9/26/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> 2007/9/26, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> > On 9/26/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> > > Xiao-Feng,
> > >
> > > Idea is really interesting and it's a pity it came too late in M3. I
> > > believe we're not going to prolong M3 closing date after this weekend
> > > but OTOH suspect we have no spare hands to sort out critical x86-64
> > > issues for remained days. I'd love someone rebut my doubts.
> > > BTW, here is one of issues: self-hosting crashed on latest Linux-64 snapshot
[1]
> > >
> > >    [java] SIGSEGV in VM code.
> > >      [java] Stack trace:
> > >      [java]   0: gc_gen_adapt(GC_Gen*, long long) (??:-1)
> > >      [java]   1: pthread_mutex_unlock (??:-1)
> > >      [java]   2: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> > >      [java]   3: apr_atomic_casptr (atomic/unix/apr_atomic.c:376)
> > >      [java]   4: log4cxx::helpers::ObjectImpl::releaseRef() const (??:-1)
> > >      [java]   5: gc_gen_reclaim_heap(GC_Gen*, long long) (??:-1)
> > >      [java]   6: pthread_mutex_unlock (??:-1)
> > >      [java]   7: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> > >      [java]   8: ?? (??:-1)
> > >      [java]   9: gc_reclaim_heap(GC*, unsigned int) (??:-1)
> > >      [java]  10: pthread_mutex_lock (??:-1)
> > >      [java]  11: hymutex_lock (??:-1)
> > >      [java]  12: fspace_alloc(unsigned int, Allocator*) (??:-1)
> > >      [java]  13: nos_alloc(unsigned int, Allocator*) (??:-1)
> > >      [java]  14: gc_alloc (??:-1)
> > >      [java]  15: vm_new_vector(Class*, int) (??:-1)
> > >      [java]  16: vm_multianewarray_recursive(Class*, int*, unsigned int) (??:-1)
> > >      [java]  17: vm_rt_multianewarray_recursive(Class*, int*, unsigned
> > > int) (??:-1)
> > >
> > > [1] http://people.apache.org/~smishura/r579330/Linux_x86_64/hdk_by_hdk/
> >
> > Alexey, I don't understand what you mean. Do you mean we should fix
> > the failure immediately before we can consider a Linux64 M3 build?
>
> Xiao-Feng,
> Fix is always the best ;), but we need at least understand how
> critical the failure is.
> I assume we base milestone on achieving certain conscious level of
> stability; then we need to evaluate known issues and decide if we
> tolerate them for the moment. E.g. if some intermittent failure
> appears quite often (and on reasonable workloads), do we want to call
> this build stable?
>
> --
> Thanks,
> Alexey
>
> >
> > Thanks,
> > xiaofeng
> >
> > >
> > > 2007/9/25, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> > > > Hi, Stepan and folks,
> > > >
> > > > After looking at the testing results in the page given below, I feel
> > > > the status of the revisionon X86-64 is quite "good". It is not
> > > > perfect, but better than I expected.  I'd suggest we consider to
> > > > include X86-64 into our M3 build this time. It's an acceptable
> > > > starting baseline, and we can improve it and will see better situation
> > > > with M4, M5, etc.
> > > >
> > > > How do you guys think?
> > > >
> > > > Btw, The caveat for the X86-64 build is, they can only support up to
> > > > 4GB heap size currently. Hopefully this will be changed in M4 or M5.
> > > >
> > > > PS, I checked the results in Linux64 for those "must pass" tests, such
> > > > as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
> > > > are "failures" rather than "errors", which I guess are actually
> > > > time-out. The failure in Dacapo is with Chart, showing a null pointer
> > > > in AWT. I personally think we can leave it as is for M3.
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > >
> > > > On 9/25/07, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> > > > > On 9/24/07, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> > > > > > On 9/22/07, Stepan Mishura wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > According to the plan - Sept. 22 is code freeze date for
M3 so let's
> > > > > > > follow policy:
> > > > > > > "no more commits please without agreement from two committers
on the dev list."
> > > > > > >
> > > > > > > Let's do more testing and analyze if there any critical/blocker
issues
> > > > > > > for consideration.
> > > > > > > Please raise here issues that you think MUST be fixed for
M3.
> > > > > >
> > > > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > > > last classlib updates. Unfortunately, not everything is green
there.
> > > > > > I'm going to inspect all results to make sure that there are
no
> > > > > > failures caused by CC configuration issues.
> > > > > >
> > > > >
> > > > > I've compared testing status for the last snapshot r578410 [1] with
M2 [2][3].
> > > > >
> > > > > We have the following short status for failed suites:
> > > > >
> > > > > Windows_x86:
> > > > >   * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > > > on debug build)
> > > > >   * Eclipse unit tests 3.2: there is no tests report like for M3.
The
> > > > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > > >   * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > > > think is acceptable
> > > > >   * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > > >   * Functional: need more analysis, currently I see that 2 tests
were
> > > > > enabled and new 15 regressions.
> > > > >   * Geronimo: 2 regressions
> > > > >   * JDK tools: 1 test failed. It might be intermediate failure -
the
> > > > > test failed due to timeout
> > > > >   * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > > > is required.
> > > > >   * Stress: 190 tests passed for M2 and 189 for M3. Investigation
is required.
> > > > >
> > > > > Linux_x86:
> > > > >   * classlib: 2 tests from pack200 (as for Windows),  1 luni tests
> > > > > failed and 1 crash of security test
> > > > >   * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%.
I
> > > > > assume this may be CC host configuration issue. Going to investigate.
> > > > >   * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > > > think is acceptable
> > > > >   * EGA x48 hours scenario: the same as for Windows (scenario fails
on M3)
> > > > >   * Functional: need more analysis, similar to Windows - some test
are
> > > > > passing now but there are new failures.
> > > > >   * Geronimo: 2 regressions (the same as for Windows)
> > > > >   * Reliability: need more analysis
> > > > >   * Stress: need more analysis
> > > > >
> > > > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > > > security test crash.
> > > > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > > > Linux. And to look info failed jdktools test.
> > > > >
> > > > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > > > reliability and stress suites.
> > > > >
> > > > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > > > https://issues.apache.org/jira/browse/HARMONY-4810
> > > > >
> > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > > > >
> > > > > Thanks,
> > > > > Stepan.
> > > > >
> > > > >
> > > > > > Please feel free to pick up any issue for investigation. For
example,
> > > > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > > > on Linux x86
> > > > > >
> > > > > > BTW, should we consider BTI's workspace (that we use for M3
testing)
> > > > > > frozen too?
> > > > > >
> > > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > > >
> > > > > > Thanks,
> > > > > > Stepan.
> > > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>

Mime
View raw message