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

[Y.S.Ramakrishna at Sun.COM]

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
>>