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 chunronglai@gmail.com
 designates 209.85.198.232 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:references;
        b=WIx81Zn3QYxWTQEI1Bmb9GjwJT8vsFGk6Tcf/TW1e+c45lZMaekTnqY5WoB8UBklIg
         DxoUOzGiw8jopMssAQUadHgqTm/i4HmL3GsMGws1d2OGBMzosubKJKaFxh0ZuZg7e3tE
         s51BLxq//r7NrxOxb6x39ucdadpxRX4Zx0tik=
Message-ID: <f9761b910811120031x2d3949a2o8caa8e2c94fbb826@mail.gmail.com>
Date: Wed, 12 Nov 2008 16:31:52 +0800
From: "chunrong lai" <chunronglai@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [vote] Declare r711744 as M8
In-Reply-To: <4919AC0A.8050304@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2619_30789078.1226478712530"
References: <fc2fc95c0811100817p3be493cj161b9c5337a9f019@mail.gmail.com>
	 <4918891F.3040003@gmail.com>
	 <fc2fc95c0811110053h3dac0b58la1d55a0492333b27@mail.gmail.com>
	 <f9761b910811110056l36c4b26ekcb60544c30c5b434@mail.gmail.com>
	 <49198D58.9090107@gmail.com>
	 <f9761b910811110658q5a69d65ahe91b70b05db5d18a@mail.gmail.com>
	 <4919AC0A.8050304@gmail.com>

------=_Part_2619_30789078.1226478712530
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

hi, Tim:
    The severe uncaught NullPointerException comes with the stub of
vm_rt_monitor_enter. Originally we have two null checkings with that. The
first one is just before the stub and is controled by JIT. The second is
inside the stub. So we had not met the reported exception.
    A commit in May (r659128) removeed the null checking (and exception
throwing) inside the stub when doing some optimizations (for HARMONY-5714).
Now we find that the null checking before the stub will also be removed
after some aggressive optimizations. I talked with buqi and he thought that
JIT should never remove such null checking and he is also trying to prepare
a patch to fix this issue.
    I think we can have a fast and safe fix for this uncaught exception by
simply adding the null checking code bak to the stub. In this way M8 will
run just like M6, M5 etc. Are there other committers supporting this? We can
also wait for Buqi's (real) fix in JIT to remove the uncaught exception in
M8.

On Wed, Nov 12, 2008 at 12:00 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:

> chunrong lai wrote:
> > I can reproduce the error.
> > Zhiguo mentioned that we need to reproduce the error with -Xem:opt or
> > -Xem:server.
>
> Do we know what the fix is for this?
>
> Just wondering if this is a candidate for inclusion in M8, since it was
> a regression since M6.  If the patch would not invalidate the results of
> our long running tests then I would like us to consider it since the
> crash is severe.
>
> Regards,
> Tim
>
> > On Tue, Nov 11, 2008 at 9:49 PM, Tim Ellison <t.p.ellison@gmail.com>
> wrote:
> >
> >> Got it -- thanks.
> >>
> >> Can anyone else reproduce HARMONY-6013 [1] ?  It works for me with a
> >> simple test, but if others see a failure that would be a pretty bad
> >> regression...
> >>
> >> [1] https://issues.apache.org/jira/browse/HARMONY-6013
> >>
> >> Regards,
> >> Tim
> >>
> >> chunrong lai wrote:
> >>>  Thanks. I am uploading the snapshots.
> >>>
> >>> On Tue, Nov 11, 2008 at 4:53 PM, Sian January <
> >> sianjanuary@googlemail.com>wrote:
> >>>> Chunrong, are you able to make these available?
> >>>>
> >>>> 2008/11/10 Tim Ellison <t.p.ellison@gmail.com>:
> >>>>  > Sian January wrote:
> >>>>>> The testing cycle for r710036 [1] has been completed and the test
> >>>>>> results have been discussed [2].
> >>>>>>
> >>>>>> Two bug fixes [3,4] have been committed since r710036 that we want
> to
> >>>>>> include in M8. r711744 has not been through the extended testing
> >>>>>> cycle, but has been through the standard integrity testing cycle
> with
> >>>>>> the same results as r710036.[5]
> >>>>> Where are the r711744 builds?  I don't see them on the snapshots
> >>>>> download page.
> >>>>>
> >>>>> We have to vote on the actual archive bundle, not just a SVN tag.
> >>>>> I'd like to take a look and do a final sanity check.
> >>>>>
> >>>>> Regards,
> >>>>> Tim
> >>>>>
> >>>>>> As usual there are some long-standing issues and a few new ones, but
> >>>>>> nothing that has been considederd critical so far.  Overall the pass
> >>>>>> rate is better than M7.
> >>>>>>
> >>>>>> If anyone thinks that a particular issue is a blocker for M8 please
> >> say
> >>>> so here.
> >>>>>> Otherwise, shall we declare r711744 as M8 and unfreeze the code
> base?
> >>>>>>
> >>>>>> [1]
> http://people.apache.org/~chunrong/snapshots/r710036/index.html
> >>>>>>
> >>>>>> [2] http://markmail.org/message/l72lba7xehacqyku
> >>>>>>
> >>>>>> [3] http://markmail.org/message/6fxgpa2azv27zsol
> >>>>>>
> >>>>>> [4] http://markmail.org/message/ljqwytbegtsfou2g
> >>>>>>
> >>>>>> [5] http://people.apache.org/~chunrong/harmony-integrity/
> >>>>>>
> >>>>
> >>>>  --
> >>>> Unless stated otherwise above:
> >>>> IBM United Kingdom Limited - Registered in England and Wales with
> number
> >>>> 741598.
> >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> >> 3AU
> >
>

------=_Part_2619_30789078.1226478712530--