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

Thomas Schatzl thomas.schatzl at oracle.com
Wed Apr 13 08:33:22 UTC 2016


Hi,

On Tue, 2016-04-12 at 13:27 -0400, Derek White wrote:
> On 4/12/16 12:40 PM, Derek White wrote:
> > 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)?
> OK, answering my own question :-)
>  - Derek, please read the big block comment. If the object is dead we
> can't prove all of the constraints listed are satisfied.
> 
> But it might be a good idea to tag humongous regions that don't
> contain references at humongous object allocation time. Then we
> should be able to do eager reclaim without looking at the Klass.

  I do not think we need tagging, G1 only needs to avoid accessing the
klass. It does not anymore except for the log messages mentioned
elsewhere.

One would need to think through whether you could unconditionally make
the humongous regions reclaimable if the object is dead. I think so,
because obviously it can't be on the mark stack at this point (no
marking is running if it has already been determined dead), and there
can't be a (valid) remembered set entry to it.

However for the purpose of fixing this issue I would tend to be
conservative here. Concurrent cleanup will reclaim the region anyway
just a little bit later.

Thanks,
  Thomas



More information about the hotspot-gc-dev mailing list