Differences between openjdk6 hotspot and hs14+

[Andrew John Hughes]

2009/11/24 Joseph D. Darcy <Joe.Darcy at sun.com>:
> Martin Buchholz wrote:
>>
>> Looks good.
>>
>> Martin
>>
>> On Mon, Nov 23, 2009 at 12:16, Andrew John Hughes
>> <gnu_andrew at member.fsf.org> wrote:
>>
>>>
>>> 2009/11/11 Martin Buchholz <martinrb at google.com>:
>>>
>>>>
>>>> Hi Andrew,
>>>>
>>>> I'm checking the current state of hotspot 14 in openjdk6,
>>>> and noticed some discrepancies I can't explain.
>>>>
>>>> This hunk:
>>>>
>>>> --- /home/martinrb/ws/hsx14-master/src/share/vm/runtime/globals.hpp
>>>> 2009-05-13 14:49:39.000000000 -0700
>>>> +++ /home/martinrb/ws/openjdk6/hotspot/src/share/vm/runtime/globals.hpp
>>>> 2009-11-04 15:34:13.000000000 -0800
>>>> @@ -1494,7 +1497,7 @@
>>>>           "CMSPrecleanNumerator:CMSPrecleanDenominator yields
>>>> convergence"
>>>> \
>>>>           " ratio")
>>>> \
>>>>
>>>> \
>>>> -  product(bool, CMSPrecleanRefLists1, true,
>>>> \
>>>> +  product(bool, CMSPrecleanRefLists1, false,
>>>> \
>>>>           "Preclean ref lists during (initial) preclean phase")
>>>> \
>>>>
>>>> \
>>>>   product(bool, CMSPrecleanRefLists2, false,
>>>> \
>>>>
>>>>
>>>> is from
>>>>
>>>> # HG changeset patch
>>>> # User ysr
>>>> # Date 1227212861 28800
>>>> # Node ID 00b023ae2d78987955a9647b6d6d457bd39dec7e
>>>> # Parent  b5e603f2e02480180ace404141897cf8f6266e93
>>>> 6722113: CMS: Incorrect overflow handling during precleaning of
>>>> Reference
>>>> lists
>>>> Summary: When we encounter marking stack overflow during precleaning of
>>>> Reference lists, we were using the overflow list mechanism, which can
>>>> cause
>>>> problems on account of mutating the mark word of the header because of
>>>> conflicts with mutator accesses and updates of that field. Instead we
>>>> should
>>>> use the usual mechanism for overflow handling in concurrent phases,
>>>> namely
>>>> dirtying of the card on which the overflowed object lies. Since
>>>> precleaning
>>>> effectively does a form of discovered list processing, albeit with
>>>> discovery
>>>> enabled, we needed to adjust some code to be correct in the face of
>>>> interleaved processing and discovery.
>>>> Reviewed-by: apetrusenko, jcoomes
>>>>
>>>>
>>>> Probably inadvertently reverted during a merge?
>>>>
>>>>
>>>> I found this by reviewing changes thusly
>>>>
>>>> diff -Bw -x .hg -u -r  ~/ws/hsx14-master/ ~/ws/openjdk6/hotspot/
>>>>
>>>> Martin
>>>>
>>>>
>>>
>>> Yes, looks like it was reverted in:
>>>
>>> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/1ba7ca27e707
>>>
>>> (the big merge)
>>>
>>> Here's a webrev for the change:
>>>
>>> http://cr.openjdk.java.net/~andrew/jdk6-hs14-merge/webrev.05/
>>>
>>> Joe, can you please approve this and allocate it a bug ID?
>>>
>>> Thanks,
>>> --
>>> Andrew :-)
>>>
>>> Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>>
>>> Support Free Java!
>>> Contribute to GNU Classpath and the OpenJDK
>>> http://www.gnu.org/software/classpath
>>> http://openjdk.java.net
>>>
>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>>
>>>
>
> Martin, good catch finding this problem!  Andrew, I approve your fix; please
> you bug 6904255 "Fix HS14 merge issue in OpenJDK 6."
>
> Thanks,
>
> -Joe
>
>

Done; http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/6d205e656aa5

Thanks.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8