Potential optimization to the GC termination protocol in JDK8
T S
suokunstar at gmail.com
Thu Apr 26 02:24:37 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
--
**********************************
> Tony Suo
> Computer Science, University of Texas at Arlington
**********************************
More information about the jdk8u-dev
mailing list