Potential optimization to the GC termination protocol in JDK8

[David Holmes]

Re-directing to the hotspot GC mailing list from jdk8u-dev mailing list

Please do not reply-all with jdk8u-dev included.

David

On 26/04/2018 12:24 PM, T S wrote:
> [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
> 
>