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