Work-in-progress: 8236485: Epoch synchronization protocol for G1 concurrent refinement
manc at google.com
Thu Jan 16 00:08:46 UTC 2020
We had an offline discussion on this. To keep the community in the loop,
here is what we discussed.
a. Using Linux membarrier syscall or equivalent on other OSes seems a
cleaner solution than thread-local handshake (TLH). But we need to have a
backup mechanism for OSes and older Linuxes that do not have such a syscall.
b. For the blocking property of TLH,
https://bugs.openjdk.java.net/browse/JDK-8230594 may help solve the problem
once it is implemented.
c. TLH could be issued to a subset of all threads, e.g. only to thread that
have not yet reached the global epoch. This could save a lot of time for
d. Compiler threads are Java threads but they are mostly not in Java state.
They could be a source of problem for the epoch synchronization protocol.
e. The filter in G1EpochSynchronizer::check_and_update_frontier() may be
incorrect, because it racily reads a remote thread's state, which may not
observe all threads in Java state.
f. Implementing asynchronous processing of the dirty card buffers could
avoid a lot of TLH requests, so the speed of TLH may not be hugely
g. It may be OK to slow down the native post-write barrier a bit with more
frequent execution of the StoreLoad fence. We could do some benchmarking to
test this. A more debatable issue is if we would make the native post-write
barrier different from the post-write barrier in Java code, that only the
native barrier has the StoreLoad fence.
I will further work on these issues.
On Sun, Dec 22, 2019 at 8:50 AM Man Cao <manc at google.com> wrote:
> Hi all,
> I have written up a description and challenges for implementing an epoch
> synchronization protocol. This protocol is necessary for removing the
> StoreLoad fence in G1's post-write barrier (JDK-8226731)
> Description: https://bugs.openjdk.java.net/browse/JDK-8236485
> Work-in-progress webrev:
> There are two main challenges that I'm not sure how to resolve:
> - Triggering a thread-local handshake is a blocking operation that can
> pass a safepoint.
> - There are native post-write barriers executed by threads in native/VM
> Discussions and suggestions are highly appreciated!
More information about the hotspot-gc-dev