[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jdk6-dev
Subject:    Review Request: Regression Zero fails to handle fast_aldc and fast_aldc_w in hs20
From:       xerxes () zafena ! se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date:       2011-04-21 0:40:09
Message-ID: 4DAF7CE9.50209 () zafena ! se
[Download RAW message or body]

On 2011-04-21 02:15, Dr Andrew John Hughes wrote:
> On 02:07 Thu 21 Apr     , Xerxes R?nby wrote:
>> On 2011-04-21 00:39, Dr Andrew John Hughes wrote:
>>> On 16:00 Wed 20 Apr     , Xerxes R?nby wrote:
>>>> Hi
>>>>
>>>> hs20 uses two new internal instructions fast_aldc and fast_aldc_w.
>>>> see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp
>>>>
>>>> This webrev fix by backporting Zero fixes from OpenJDK bug 7032458 and 7030207.
>>>> http://labb.zafena.se/openjdk/pr696-zero-fast_aldc-and-fast_aldc_w-regression-hs20/
>>>>
>>>> The webrev are made against hsx20
>>>> http://hg.openjdk.java.net/hsx/hsx20/master/
>>>>
>>>> I don't have a bug id for this.
>>>
>>> Why are you merging together two different changesets?
>>
>> Because they both contain parts that are needed to properly fix this
>> Zero regression on hs20 and prevent it from happening again.
>>
>> One part that fixes the regression by making the instruction table in
>> sync again from 7032458, and another part from 7030207 that reveals the
>> error if the table gets out of sync again.
>>
>> If I quote Gary:
>> "It two new internal instructions, _fast_aldc and _fast_aldc_w, but
>> it added them *before* _return_register_finalizer, which broke the
>> instructions table in bytecodeInterpreter.cpp.  It meant that when
>> the C++ interpreter saw _return_register_finalizer it would execute
>> opc_default, which should have thrown an error but for the piece of
>> the ARM interpreter which hid the error by rewriting the instruction
>> to a plain _return.  I didn't see it before because I was doing
>> debug builds, and the C++ interpreter only uses the instructions
>> table for product builds."
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/005074.html
>>
>
> Are there bits of each changeset being left out?  It's just it's easier
> to track if there is a 1-to-1 correspondence.

Large parts of 7032458 are left out that are unrelated to this Zero 
regression in hs20 (some Shark fixes and non hs20 fixes).
The changeset from 7030207 are intact and can be backported by 1-to-1 
correspondence if preferable.

Personally I would prefer to see this Zero hs20 regression to be tracked 
as a unit in a Bug ID of its own.

>
>> Cheers
>> Xerxes
>


[prev in list] [next in list] [prev in thread] [next in thread]