RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects

Dmitry Fazunenko dmitry.fazunenko at oracle.com
Wed Dec 10 17:09:37 UTC 2014

Hi Thomas,

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:

   * @test
   * ...
    * @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 
process output.


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
> candidates.
> 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
> G1TraceReclaimDeadHumongousObjectsAtYoungGC.
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8048179
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8048179/webrev.0/
> Testing:
> jprt, a few benchmarks
> Thanks,
>    Thomas

More information about the hotspot-gc-dev mailing list