using -XX:-UseCompilerSafepoints

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Nov 12 12:08:35 UTC 2014


Hi Tom,

On 11/11/2014 07:34 PM, Deneau, Tom wrote:
> It looks like a thread that calls Thread.sleep (as the timing control
> thread does in the harness) will eventually go thru
> SafepointSynchonize::block (as part of the ThreadBlockInVM
> destructor).  So if there is a looping benchmark thread compiled
> without Compiler Safepoints, the control thread will be blocked and
> will never set the isDone flag.

So, you are saying that without the safepoint in the while(!isDone)
loop in workload, control thread and workload thread will never
rendezvous on safepoint? I believe this is a bug with
-XX:-CompilerSafepoints, because the comment in safepoint.cpp calls this
out specifically for VMThread vs. Mutator threads:

 // In a pathological scenario such as that described in CR6415670
 // the VMthread may sleep just before the mutator(s) become safe.
 // In that case the mutators will be stalled waiting for the safepoint
 // to complete and the the VMthread will be sleeping, waiting for the
 // mutators to rendezvous. The VMthread will eventually wake up and
 // detect that all mutators are safe, at which point we'll again make
 // progress.

If this is a case, you probably need to report this to runtime guys.

> This is probably OK, just need to document that CompilerSafepoints
> cannot be turned off.

I think it is safe to presume something will go hairy if you are using
any special VM flag, therefore I am not inclined to document this.

Thanks,
-Aleksey.



More information about the jmh-dev mailing list