RFR(S) 8153843: G1CardLiveDataHelper incorrectly sets next_live_bytes on dead humongous regions
mikael.gerdin at oracle.com
Tue Apr 12 12:57:02 UTC 2016
Hi Derek, Tom
Are you planning to re-review webrev.1 or can I push this?
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?
> 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 :-)
> 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
More information about the hotspot-gc-dev