RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects
bengt.rutisson at oracle.com
Wed Dec 10 15:59:56 UTC 2014
On 2014-12-10 15:44, Thomas Schatzl wrote:
> Hi all,
> can I have reviews for this small change that improves eager reclaim
> efficiency at no (measureable) cost?
> Until that change we only ever considered humongous objects with
> absolutely no references for eager reclaim. This change widens that
> restriction by allowing humongous objects with a few references as
> This works simply by pushing remembered set cards of such humongous
> objects into the DCQS at the beginning of evacuation. The update rs
> phase will automatically (and in parallel!) determine whether there is
> still a reference to an object or not.
> Humongous objects that do not contain any remembered set entries after
> gc (and the other conditions that prevent reclamation do not hold like
> reference from young gen) that object is reclaimed.
> I arbitrarily defined "having a few references" as a region having only
> sparse remembered set entries.
> There is a new global G1ReclaimDeadHumongousObjectsWithRefsAtYoungGC to
> turn off this particular feature of early reclamation in case it takes
> too long. The default value is true, i.e. it is turned on by default.
> All benchmarks we have looked at showed that there is no particular
> pause time impact by this change if it has been ineffective, however
> there is a new phase "Humongous Register" in the log that can be used to
> determine the impact.
> Some benchmarks show some improvement in overall performance due to the
> feature reclaiming temporary objects much faster.
> There is also some cleanup in the debug messages enabled by
Overall this looks good to me. Some minor comments:
- Could we name the tests a bit more creative than
TestEagerReclaimHumongousRegions, TestEagerReclaimHumongousRegions2 and
- I think it would be good to communicate that we are not reclaiming
humongous objects that actually have references. We reclaim those that
only have stale references. Maybe we can name the flag
G1ReclaimDeadHumongousObjectsWithStaleRefs and have the description be:
277 "Try to reclaim dead large objects that have a few stale
278 "references at every young
If is_small_for_eager_reclaim() would return true also if
OtherRegionsTable::is_empty() is true then the farily complex check in
G1CollectedHeap::humongous_region_is_candidate() could be made simpler:
3490 return !oop(region->bottom())->is_objArray() &&
3491 (G1ReclaimDeadHumongousObjectsWithRefsAtYoungGC &&
Also, why is humongous_region_is_candidate() a public method on
G1CollectedHeap instead of a private method in
I am also a little bit concerned with is_small_for_eager_reclaim(). It
kind of pushes implementation details about early reclamation down into
the remembered sets. I don't really have a good idea of how to design
it. But one question is if you have had a chance to measure the overhead
of just not filter at all and flush the remsets for all humongous objects?
> jprt, a few benchmarks
More information about the hotspot-gc-dev