On Dec 12, 2007 6:55 PM, Stepan Mishura <[EMAIL PROTECTED]> wrote: > On 12/12/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > I suggest to delay this patch commit after M4. As I said, it's not a > > regression. The commit does fix this issue, while it may have some > > risk for other test case(s). > > > > Hi Xiao-Feng, > > In JIRA comments you wrote that the failure is intermittent. According > to CC reports the test stably fails on last 3 snapshots. If it fail on > r603433 snapshot too I wouldn't say that it is intermittent.
Stepan, in my local run, it's about once failure in ten runs. And it depends on heap size. More importantly, there are actually no essential GC commits since M3 that could impact the behavior. (Most of the commits since M3 are turned off by default.) For this specific test case, I am 100% sure that the GC logic causing its failure has not changed since M3. If it fails more frequently than before, I guess that is because of some changes in other components that make it cross the borderline more easily than before, e.g., threads are more efficient. Actually the GC logic causing the failure is not necessarily a real bug. It's a heuristic mechanism for space size adaptive tuning. The original heuristic is too aggressive, ignoring the block header overhead in space size computation. This logic has been there for a long time. The fix is to make the size estimation more conservative. That's why I am sure it's not a real regression. Although I am sure the fix is a right fix, I don't want to risk committing it. The reason is, I know there are some smoke or regression or stress tests that are not really correct from GC point of view. They have very restrictive requirements on GC's behavior. If there is a new failure, it is not worth to put M4 in danger for those tests. So I'd like to commit the patch after M4. We actually are developing a new algorithm that will abandon this heuristic mechanism in future. Probably M5 will have the new algorithm at all. Stepan, you saw that I once committed the patch. But after careful thinking, I think it's better to defer the commit. Thanks, xiaofeng > Thanks, > Stepan. > > > > > Thanks, > > xiaofeng > > > > On Dec 12, 2007 11:13 AM, Chunrong Lai (JIRA) <[EMAIL PROTECTED]> wrote: > > > > > > [ > > > https://issues.apache.org/jira/browse/HARMONY-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > > ] > > > > > > Chunrong Lai updated HARMONY-5283: > > > ---------------------------------- > > > > > > Attachment: H5283.fixed.new.patch > > > > > > > > > Format problem exists in last patch. Please use this updated one. Thanks. > > > > > > > [drlvm][gc] OOME causes error in VM code > > > > ---------------------------------------- > > > > > > > > Key: HARMONY-5283 > > > > URL: https://issues.apache.org/jira/browse/HARMONY-5283 > > > > Project: Harmony > > > > Issue Type: Bug > > > > Components: DRLVM > > > > Environment: Linux x86, -Xmx128m -Xms128m > > > > Reporter: Andrey Pavlenko > > > > Assignee: Xiao-Feng Li > > > > Priority: Critical > > > > Fix For: 5.0M4 > > > > > > > > Attachments: H5283.fixed.new.patch, H5283.fixed.patch > > > > > > > > > > > > > > > The following test intermittently causes error. I've marked this issue > > > > as critical because it seems to be a regression and causes error of the > > > > regression test > > > > http://people.apache.org/~smishura/r602144/Linux_x86/func/functional/org/apache/harmony/test/func/reg/vm/btest6962/1118_Btest6962.html > > > > import java.util.LinkedList; > > > > import java.util.List; > > > > public class Test { > > > > public static void main(String[] args) throws Exception { > > > > final List<Object> list = new LinkedList<Object>(); > > > > try { > > > > while (true) { > > > > list.add(new Object()); > > > > } > > > > } catch (OutOfMemoryError e) { > > > > } > > > > } > > > > } > > > > Stack: > > > > Out of Memory! > > > > SIGABRT in VM code. > > > > Stack trace: > > > > addr2line: '[vdso]': No such file > > > > 0: ?? (:-1) > > > > 1: abort (??:-1) > > > > 2: gc_gen_reclaim_heap(GC_Gen*, long long) (weak_roots.cpp:-1) > > > > 3: gc_reclaim_heap(GC*, unsigned int) (weak_roots.cpp:-1) > > > > 4: fspace_alloc(unsigned int, Allocator*) (weak_roots.cpp:-1) > > > > 5: nos_alloc(unsigned int, Allocator*) (weak_roots.cpp:-1) > > > > 6: gc_alloc (??:-1) > > > > 7: vm_malloc_with_thread_pointer(unsigned int, unsigned int, void*) > > > > (apr_strtok.c:-1) > > > > 8: 0xB6973505 <Generated stub> > > > > 9: ?? (??:-1) > > > > 10: > > > > org/apache/harmony/test/func/reg/vm/btest6962/LongList.test(Ljava/util/logging/Logger;[Ljava/lang/String;)I > > > > (LongList.java:37) > > > > 11: ?? (??:-1) > > > > 12: .L294 (ini_iA32.cpp:-1) > > > > 13: DrlEMImpl::executeMethod(_jmethodID*, jvalue*, jvalue*) > > > > (inet_pton.c:-1) > > > > 14: ExecuteMethod (em_intf.cpp:-1) > > > > 15: vm_execute_java_method_array (apr_strtok.c:-1) > > > > 16: call_static_method_no_ref_result(JNIEnv_External*, _jobject*, > > > > _jmethodID*, jvalue*, jvalue*) (jni_method.cpp:-1) > > > > 17: CallStaticVoidMethodV(JNIEnv_External*, _jobject*, _jmethodID*, > > > > char*) (apr_strtok.c:-1) > > > > 18: CallStaticVoidMethod(JNIEnv_External*, _jobject*, _jmethodID*, > > > > ...) (apr_strtok.c:-1) > > > > 19: main_runJavaMain (??:-1) > > > > 20: invocation (main.c:-1) > > > > 21: gpProtectedMain (??:-1) > > > > 22: signalProtectedMain (cmain.c:-1) > > > > 23: hysig_protect (utf8decode.c:-1) > > > > 24: main (??:-1) > > > > 25: __libc_start_main (??:-1) > > > > 26: _start (??:-1) > > > > 27: > > > > org/apache/harmony/test/func/reg/vm/btest6962/LongList.main([Ljava/lang/String;)V > > > > (LongList.java:30) > > > > <end of stack trace> > > > > > > -- > > > This message is automatically generated by JIRA. > > > - > > > You can reply to this email to add a comment to the issue online. > > > > > > > > > > > > > > -- > > http://xiao-feng.blogspot.com > > > > > -- > Stepan Mishura > Intel Enterprise Solutions Software Division > -- http://xiao-feng.blogspot.com
