RFR (M): 8201491: G1 support for java.lang.ref.Reference precleaning
kirk at kodewerk.com
Mon May 7 11:18:20 UTC 2018
> On May 7, 2018, at 12:50 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> ping for a reviewer... :)
> I am aware that the option name is not the shortest
> ("G1UseReferencePrecleaning") but something like "G1Precleaning" seems
> too obtuse. Maybe "G1UseRefPrecleaning"? (We abbreviate "Reference" to
> "Ref" in other switches already).
> On Thu, 2018-04-26 at 11:36 +0200, Thomas Schatzl wrote:
>> Hi all,
>> can I have reviews for this change that implements reference
>> precleaning like CMS for G1?
>> In absence of fully concurrent reference processing this seems to be
>> a very good tradeoff between effort and improvement in some cases.
>> Since it is planned to be obsoleted in the future, and I do not
>> expect other new collectors to implement it (Shenandoah will likely
>> go to fully concurrent as well, Z afaik already has concurrent
>> Reference processing, and CMS is on its way out), I added a G1
>> specific experimental option called "G1UseReferencePrecleaning"
>> defaulting to true (enabled).
>> It is also single-threaded, although it could be extended to MT
>> processing fairly easily. Again, a compromise between effort and
>> expected gain.
I have demonstrated reasonable reductions in GC pause time when reference processing rates exceed ~50/sec by turning on the MT option in production envrionments. Since most of the applications I get data from exceed the reference processing rates that seem to be present in the current test suite leads me to believe that having any amount of reference processing removed from the overall GC pause time would be beneficial.
More information about the hotspot-gc-dev