Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xiaofeng.li@gmail.com
 designates 64.233.162.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=oQEttaSDYr7eAkDXUZ2lnTEWnH2uePJhfO/meFhgbF41OviFeijJa6U/xbVaLfpL35oxL8MNG3F7DU0uCdVvfZQHJ4H9dz/e5s1WsIKo0RJI0b7GvdlWltqmTdhG8FZ4tFtp0Rcb/oEUwBtQZQqhGs87A4YrPWB9XSabvCB/WgM=
Message-ID: <9623c9a50712120326k588a0d27vf40de2606ad094d3@mail.gmail.com>
Date: Wed, 12 Dec 2007 19:26:05 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [jira] Updated: (HARMONY-5283) [drlvm][gc] OOME causes error in
 VM code
In-Reply-To: <6e47b64f0712120255kb2a5794n54c470d2ad6b67a7@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <16695721.1197290443156.JavaMail.jira@brutus>
	 <12297760.1197429223073.JavaMail.jira@brutus>
	 <9623c9a50712112012m6ddde2caja7ff4035bc169fe9@mail.gmail.com>
	 <6e47b64f0712120255kb2a5794n54c470d2ad6b67a7@mail.gmail.com>

On Dec 12, 2007 6:55 PM, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> On 12/12/07, Xiao-Feng Li <xiaofeng.li@gmail.com> 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) <jira@apache.org> 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  &lt;Generated stub&gt;
> > > >   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)
> > > > &lt;end of stack trace&gt;
> > >
> > > --
> > > 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