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

[Dmitry Fazunenko]

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.

Thanks,
Dima

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
>