Discussion for 8226197: Reducing G1’s CPU cost with simplified write post-barrier and disabling concurrent refinement

Man Cao manc at google.com
Sat Jun 15 01:41:46 UTC 2019


Hi all,

I'd like to discuss the feasibility of supporting a new mode of G1 that
uses a simplified write post-barrier. The idea is basically trading off
some pause time with CPU time, more details are in:
https://bugs.openjdk.java.net/browse/JDK-8226197

A prototype implementation is here:
https://cr.openjdk.java.net/~manc/8226197/webrev.00/

At a high level, other than the maintenance issue of supporting two
different types of write barrier, is there anything inherently wrong about
this approach? I have run fastdebug build with various GC verification
options turned on to stress test the prototype, and so far I have not found
any failures due to the prototype.

For the patch itself, besides the changes to files related to the write
barrier, the majority of the change is in g1RemSet.cpp, where it needs to
scan all dirty cards for regions not in the collection set. This phase
(called process_card_table()) replaces the update_rem_set() phase during
evacuation pause, and is similar
to ClearNoncleanCardWrapper::do_MemRegion() for CMS.
There are certainly many things can be improved for the patch,
e.g., G1Analytics should take into account and adapt to the time spent
in process_card_table(), and process_card_table() could be further
optimized to speed up the scanning. We'd like to discuss about this
approach in general before further improving it.
In addition, we will collect more performance results with real production
workload in a week or two.

-Man
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190614/014a0b6d/attachment.htm>


More information about the hotspot-gc-dev mailing list