RFR: Fix inconsistency between global and local evac-in-progress flag

Roman Kennke rkennke at redhat.com
Mon Oct 31 16:28:22 UTC 2016


In rare circumstances, we could get an inconsistency between the global
JavaThread::_evacuation_in_progress_global and
JavaThread::_evacuation_in_progress flags. This could happen when using
jni_AttachCurrentThread. In this situation, the just-attached thread
could line up before the Threads_lock with its evac flag turned off,
while the safepoint that holds the Threads_lock would turn it on. In
this case, the attached thread would not turn evacuation on for that GC
cycle, and we'd miss stores.

I've reused a testcase that Aleksey has written. It uses shutdown
hooks, because that's where we've first observed the bug. And it looks
like the only use of AttachCurrentThread inside the VM too. The test is
relatively long running, otherwise it wouldn't very likely expose the
bug.

The fix is to sync the local and global flags in
JavaThread::initialize_queues(), this is where the other local/global
flags for SATB and dirty card queue are synced too. (In the future we
might want to rename this method?)

I've also protected the code that initially sets all threads to
evacuation on/off by the Threads_lock to avoid races. This is only
necessary when turning the flag off, because we turn it on only at
safepoints, and we're already holding the Threads_lock there.

http://cr.openjdk.java.net/~rkennke/synclocalglobalevac/webrev.00/

Ok to go?
Roman


More information about the shenandoah-dev mailing list