RFR(XS): VM times out in VM_HandshakeAllThreads::doit() with RunThese30M

David Holmes david.holmes at oracle.com
Wed Aug 15 22:35:41 UTC 2018


Hi Robbin,

On 15/08/2018 9:12 PM, Robbin Ehn wrote:
> Hi David, truncated:
> 
> On 2018-08-15 12:40, David Holmes wrote:
>> The context in which this is executed is not at all clear so assessing 
>> the suitability of the fix is also not clear. IIRC a thread can only 
>> be resumed at a safepoint so if the above code executes in the 
>> VMThread then it can't be racing with a resume and the Threads_lock 
>> holding seems unnecessary wrt. this action. ??
> 
> The context is, VM thread calls this method to figure out if he can 
> executed the handshake on behalf of the thread in question.

Right and that happens while not at a safepoint, nor initiating one, so 
this is in general a racy call to check the safepoint-state anyway. I 
had to refresh myself on the details of handshakes to understand how 
that race is handled in general. Suspended threads don't get caught up 
by the normal thread-state transition mechanics so aren't handled the 
same way. Hence the explicit need to ensure the target is not suspended, 
and that the Threads_lock is held to ensure it can't resume if it is. Ok.

> JavaThread::java_resume which does the notify on SR lock, says:
> 
> // We need to guarantee the Threads_lock here, since resumes are not
> // allowed during safepoint synchronization
> // Can only resume from an external suspension
> void JavaThread::java_resume() {

I did say "IIRC a thread can only be resumed at a safepoint" and 
obviously I was not recalling correctly. :)

Thanks,
David

> And if you look at java_suspend_self() after getting the notification I 
> see nothing that would keep it from continue executing e.g. java code. 
> It can be here with state _thread_in_Java since we skip the proper 
> transitions, thus not even needing todo a transition to continue execute 
> java code.
> 
> Is there something I'm missing?
> 
> Thanks, Robbin
> 
>>
>> Thanks,
>> David
>>


More information about the hotspot-runtime-dev mailing list