harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [general] M3 - code frozen
Date Wed, 26 Sep 2007 11:34:31 GMT
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