RFR(S) 8153843: G1CardLiveDataHelper incorrectly sets next_live_bytes on dead humongous regions

[Derek White]

On 4/12/16 8:57 AM, Mikael Gerdin wrote:
> Hi Derek, Tom
>
> Are you planning to re-review webrev.1 or can I push this?
>
> http://cr.openjdk.java.net/~mgerdin/8153843/webrev.1/
>
> /Mikael

Hi Mikael,

My only question is about the issue Thomas pointed out and you fixed:
g1CollectedHeap.cpp, Line 2946.

I am surprised that "Dead objects cannot be eager reclaim candidates" -  
I thought they were the perfect eager reclaim candidates. Should it be 
that we simply declare victory and return true at line 2951 (bypassing 
the unsafe stuff)?

Otherwise everything looks fine to me.

Thanks,

  - Derek

> On 2016-04-08 20:10, Derek White wrote:
>> Hi Mikael, Tom,
>>
>> On 4/8/16 12:09 PM, Tom Benson wrote:
>>> Hi Mikael,
>>> It looks like there is an indentation problem at lines 214/215.
>>> Dumb question:  The code now extends the range down to the object
>>> start, if current region continues_humongous.  Do you want to extend
>>> to the true end region of the object, which might not be the current 
>>> one?
>>> Tom
>>
>> Tom,
>>
>> I don't think this is extending the range to the start of the HR, it's
>> just checking the mark bit at the start of the HR. Not that I'm
>> following why we're marking all of the live bytes instead of just
>> relying on the mark for the start of the object, but it looks like
>> that's what we do :-)
>>
>>
>> Mikael,
>>
>> It looks like the humongous_start_region() of a "starts_humongous"
>> region is itself, so you can remove lines 210 + 212, and merge 209 + 
>> 211.
>>
>> Looks good otherwise.
>>
>>   - Derek
>>> On 4/8/2016 11:47 AM, Mikael Gerdin wrote:
>>>> Hi all,
>>>>
>>>> Please review this small change to solve an integration blocker in
>>>> hs-rt which surfaced with the latest integration from main.
>>>>
>>>> The problem is that humongous regions are kept around for longer
>>>> (possibly indefinitely) because the card live data helper
>>>> unconditionally sets the actual size of humongous objects instead of
>>>> the number of live bytes. Having a non-zero live bytes count prevents
>>>> the cleanup pause from freeing the humongous objects.
>>>> When the next gc pause then tries to register those objects with
>>>> eager reclaim it looks at the class pointer of the object and if the
>>>> class of the humongous object was unloaded then we crash.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153843
>>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8153843/webrev.0/
>>>> Testing: Crashing testcase, JPRT job running
>>>>
>>>> Thanks
>>>> /Mikael
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160412/c881d86b/attachment.htm>