RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects
dmitry.fazunenko at oracle.com
Wed Dec 10 17:09:37 UTC 2014
May I suggest refactoring to the regression test?
Now we have @requires that allows us to avoid vm flag conflicts. So,
it's not necessary anymore to fork a VM.
After refactoring the test header would look like:
* @requires vm.gc == null | vm.gc == "G1"
* @run main/othervm -XX:+UseG1GC -Xms128M -Xmx128M -Xmn16M
-XX:+PrintGC -Xloggc:gc.log ReclaimRegionFast
* @run TestEagerReclaimHumongousRegions3
The code of ReclaimRegionFast will be unchanged. You need only modify
TestEagerReclaimHumongousRegions3 to read from gc.log instead of the
On 10.12.2014 17: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
> jprt, a few benchmarks
More information about the hotspot-gc-dev