<div dir="ltr">Hi all,<div><br></div><div>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:</div><div><a href="https://bugs.openjdk.java.net/browse/JDK-8226197">https://bugs.openjdk.java.net/browse/JDK-8226197</a><br></div><div><br></div><div>A prototype implementation is here:<br></div><div><a href="https://cr.openjdk.java.net/~manc/8226197/webrev.00/">https://cr.openjdk.java.net/~manc/8226197/webrev.00/</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div>In addition, we will collect more performance results with real production workload in a week or two.<br></div><div></div><div><br></div><div>-Man<br></div></div>