Potential optimization to the GC termination protocol in JDK8

Roman Kennke rkennke at redhat.com
Thu Apr 26 06:53:01 UTC 2018

>> [Problem]
>> 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
>> attempts
>> (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
>> there
>> 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.
>> [Solution]
>> 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
>> attempts
>> to half.
>> Good forward for others' feedbacks.
>> Thanks.
>> Tony

Hi Tony,
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?

Thanks, Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20180426/31dcccae/signature.asc>

More information about the hotspot-gc-dev mailing list