Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops

Vladimir Kozlov Vladimir.Kozlov at Sun.COM
Wed Jul 22 14:16:36 PDT 2009


Thanks, Ramki

There is oops verification code in OopMapSet::all_do()
before the call closure->do_oop() which the bug fail.
This is why I used filter before oops verification.

I will add a comment into oopMap.hpp.

Thanks,
Vladimir

Y.S.Ramakrishna at Sun.COM wrote:
> Hi Vladimir -- i am fine with the fix. I worry just a little bit
> about the decision to filter/suppress these "null-equivalent" oop locations
> by the oop-map code for some future use case where we want to
> apply a closure to all oop-holding locations irrespective of
> whether the value is null; i do not however have a ready use case
> in mind at the moment. Would it be beneficial, for the future and/or the
> unwary, to add appropriate documentation about this filtering
> in the header file where the all_do() and oops_do() methods
> are declared?
> 
> Rest looks good; thanks!
> -- ramki
> 
> On 07/22/09 12:51, Paul Hohensee wrote:
>> You've got 4 uses of this expression
>>
>> Universe::narrow_oop_base() == (address)(void*)(*foo)
>>
>> You might write a new method in Universe to factor it out, vis
>>
>> bool is_narrow_oop_base(void* addr) {
>>  return narrow_oop_base() == (address)addr);
>> }
>>
>> Paul
>>
>> Vladimir Kozlov wrote:
>>>
>>> http://cr.openjdk.java.net/~kvn/6826736/webrev.01
>>>
>>> Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops
>>>
>>> Problem:
>>> Compiled code may produce decoded oop = narrow_oop_base
>>> when a narrow oop implicit null check is used.
>>> The narrow_oop_base could be NULL or be the address
>>> of the page below heap depending on the used mode of
>>> compressed oops. Such decoded oop could live across
>>> a safepoint and as result referenced in oopMap and debug info.
>>> The implicit NULL exception code checks for such oop value
>>> but deoptimization code and GC does not. And this cause
>>> the problem.
>>>
>>> Solution:
>>> Fix deoptimization code and GC to check for such oops values.
>>> During deoptimization convert them to NULL.
>>> And ignore them for GC (like NULL values are ignored).
>>>
>>> Added the regression test which shows the problem.
>>>
>>> Reviewed by:
>>>
>>> Fix verified (y/n): y, regression test
>>>
>>> Other testing:
>>> JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot
>>>
> 



More information about the hotspot-gc-dev mailing list