Potential optimization to the GC termination protocol in JDK8
rkennke at redhat.com
Thu Apr 26 06:53:01 UTC 2018
>> The work stealing during the GC takes lots of time to terminate. The
>> Parallel Scavenge in JDK 8 uses a distributed termination protocol to
>> synchronize GC threads. After 2 ∗ N consecutive unsuccessful steal
>> (steal_best_of_2 function), a GC thread enters the termination procedure,
>> where N is the number of GC threads.
>> Suppose there are N GC threads, it takes 2 * N * N failed attempts
>> before a
>> GC stops. It is inefficient and takes too much time, especially when
>> are very few GC threads alive. If there are hundreds or thousands of GC
>> happen during the app execution, that is a big waste of time.
>> Is that possible to reduce the number of steal attempt during the end of
>> GC? My idea is to record the number of active GC threads (i.e., N_live)
>> that are not yet in the termination protocol. A thread only steals
>> from the
>> pool of active GC threads because the inactive GC threads have no task to
>> be stolen. Accordingly, the criteria for thread termination becomes 2 ∗
>> N_live consecutive failed steal attempts. It can reduce the steal
>> to half.
>> Good forward for others' feedbacks.
in Shenandoah we have implemented an improved termination protocol. See
the comment here:
We intend to upstream this stuff very soon, at which point it can be
used by all other GCs if they wish. It's a drop-in replacement for the
existing task queue code.
It sounds like it's similar to what you have in mind. Right?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev