RFR (M): 8034842: Parallelize the Free CSet phase in G1

Thomas Schatzl thomas.schatzl at oracle.com
Mon May 2 14:04:02 UTC 2016


Hi all,

  can I have reviews for the free cset phase for G1?

We observed that the part of the free cset phase that takes the most
time is counting the number of occupied cards.

While earlier changes focused on decreasing the time to do that, this
change parallelizes this work, which is unfortunately a bit
complicated, but gives the expected results.

The change splits out the parallelizable part from the serial (pre-,
mid- and post-) part:

During the first serial part the change creates work lists for the
parallel part
(G1FreeCollectionSetTask::setup_for_parallel_processing()), which is in
itself split into operations that need to be applied to young and old
gen remsets (doing the slow freeing of the remsets essentially;
G1FreeCollectionSetTask::do_parallel_work()), and some additional
serial "mid-" part (G1FreeCollectionSetTask::do_serial_work()) that is
performed in parallel to the rem set freeing.

After that, the change updates the global data structures in another
post-serial phase (G1FreeCollectionSetTask::complete_work()).

Probably it's easiest to review this by comparing the main loop of the
old G1CollectedHeap::free_collection_set() method beginning in line
4736 of g1CollectedHeap.cpp with the code
in G1FreeCollectionSetTask::do_serial_work().

CR:
https://bugs.openjdk.java.net/browse/JDK-8034842
Webrev:
http://cr.openjdk.java.net/~tschatzl/8034842/webrev/
Testing:
vm.gc, many many benchmarks

(This is a rather old patch, having been used locally and many some
internal benchmark runs quite a bit)

Thanks,
  Thomas




More information about the hotspot-gc-dev mailing list