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 <[EMAIL PROTECTED]> wrote: > 2007/9/26, Xiao-Feng Li <[EMAIL PROTECTED]>: > > On 9/26/07, Alexey Varlamov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > 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 <[EMAIL PROTECTED]> wrote: > > > > > On 9/24/07, Stepan Mishura <[EMAIL PROTECTED]> 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/[EMAIL > > > > > PROTECTED] > > > > > [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 > > >
