RFR 8242484: Rework thread deletion during VM termination

David Holmes david.holmes at oracle.com
Tue Apr 21 01:46:30 UTC 2020


LGTM!

Thanks,
David

On 21/04/2020 11:22 am, Patricio Chilano wrote:
> 
> On 4/20/20 8:30 PM, David Holmes wrote:
>> On 20/04/2020 11:51 pm, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> On 4/20/20 9:32 AM, coleen.phillimore at oracle.com wrote:
>>>>
>>>>
>>>> On 4/18/20 9:53 AM, David Holmes wrote:
>>>>> Hi Coleen,
>>>>>
>>>>> On 18/04/2020 4:24 am, coleen.phillimore at oracle.com wrote:
>>>>>> On 4/17/20 1:27 PM, Patricio Chilano wrote:
>>>>>>> Hi Coleen,
>>>>>>>
>>>>>>> Thanks for looking at this.
>>>>>>>
>>>>>>> On 4/17/20 12:57 PM, coleen.phillimore at oracle.com wrote:
>>>>>>>>
>>>>>>>> This looks good to me also, although I'd like a reprisal of the 
>>>>>>>> comment before the delete thread line that says something ilke:
>>>>>>>>
>>>>>>>> // We are here after VM_Exit::set_vm_exited() so we can't call
>>>>>>>> // thread->smr_delete() or we will block on the Threads_lock.
>>>>>>> Ok, I added back the original comment:
>>>>>>>
>>>>>>> diff --git a/src/hotspot/share/runtime/thread.cpp 
>>>>>>> b/src/hotspot/share/runtime/thread.cpp
>>>>>>> --- a/src/hotspot/share/runtime/thread.cpp
>>>>>>> +++ b/src/hotspot/share/runtime/thread.cpp
>>>>>>> @@ -4472,6 +4472,11 @@
>>>>>>>    // exit_globals() will delete tty
>>>>>>>    exit_globals();
>>>>>>>
>>>>>>> +  // We are here after VM_Exit::set_vm_exited() so we can't call
>>>>>>> +  // thread->smr_delete() or we will block on the Threads_lock.
>>>>>>> +  // Deleting the shutdown thread here is safe because another
>>>>>>> +  // JavaThread cannot have an active ThreadsListHandle for
>>>>>>> +  // this JavaThread.
>>>>>>>    delete thread;
>>>>>
>>>>> Putting the comment back exactly as-was doesn't fit in well given 
>>>>> the new code we have introduced. If we want to explain this in 
>>>>> detail then it should be IMO when we first hit the code that 
>>>>> interacts with ThreadSMR:
>>>>>
>>>>>    // We are no longer on the main thread list but could still be in a
>>>>>    // secondary list where another thread may try to interact with us.
>>>>>    // So wait until all such interactions are complete before we bring
>>>>> !  // the VM to the termination safepoint. Normally this would be done
>>>>> +  // using thread->smr_delete() below where we delete the thread, but
>>>>> +  // we can't call that after the termination safepoint is active 
>>>>> as we
>>>>> +  // will deadlock on the Threads_lock. Once all interactions are
>>>>> +  // complete it is safe to directly delete the thread at any time.
>>>>>    ThreadsSMRSupport::wait_until_not_protected(thread);
>>>>
>>>> I disagree.  I think someone will find the 'delete thread' and not 
>>>> know why it's there alone without smr_delete(), and might not see 
>>>> this big comment or realize how it applies to delete. I think the 
>>>> 'delete thread' shouldn't be alone.
>>>
>>> Or even like:
>>>     // Thread must call wait_until_not_protected() before termination 
>>> safepoint first.  See above.
>>>     delete thread;
>>>
>>> If you want to move the comment above.
>>
>> That works for me.
> That sounds good. Are you okay with this diff from v1?
> 
> http://cr.openjdk.java.net/~pchilanomate/8242484/v2/inc/webrev/ 
> <http://cr.openjdk.java.net/~pchilanomate/8242484/v2/inc/webrev/src/hotspot/share/runtime/thread.cpp.udiff.html>
> 
> Thanks!
> 
> Patricio
>> Thanks,
>> David
>>
>>> Coleen
>>>>
>>>> Coleen
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>>>
>>>>>>>> But why would it block? ... I don't see what thread has the 
>>>>>>>> Threads_lock. Is this comment (that I want put back) accurate?
>>>>>>> It will block because the VMThread owns the Threads_lock. The 
>>>>>>> VMThread will start the terminating safepoint and exit but will 
>>>>>>> never release the lock.
>>>>>>
>>>>>> Thanks for the explanation.  In this code, when we call 
>>>>>> VMThread::wait_for_vm_thread_exit, that sets the _should_terminate 
>>>>>> flag, wakes up the VMThread and the VMThread will grab the 
>>>>>> Threads_lock for the final safepoint.  Therefore below at "delete 
>>>>>> thread" we can't grab the Threads_lock.
>>>>>>
>>>>>> Comment looks good.
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>>
>>>>>>> Patricio
>>>>>>>> thanks,
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>> On 4/17/20 11:09 AM, Robbin Ehn wrote:
>>>>>>>>> Hi Patricio, looks good, thanks.
>>>>>>>>>
>>>>>>>>> /Robbin
>>>>>>>>>
>>>>>>>>> On 2020-04-14 22:07, Patricio Chilano wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review this small follow up for 8240918 to always 
>>>>>>>>>> delete the JavaThread that calls Threads::destroy_vm().
>>>>>>>>>> In 8240918 I added a conditional check in 
>>>>>>>>>> Threads::destroy_vm() to prevent deleting a JavaThread when 
>>>>>>>>>> there are handshakers blocked in its handshake_turn_sem 
>>>>>>>>>> semaphore.  We can actually avoid this issue altogether if 
>>>>>>>>>> after removing the JavaThread from the active list and before 
>>>>>>>>>> triggering the terminating safepoint, we wait until the 
>>>>>>>>>> JavaThread is no longer protected by a ThreadsList reference.
>>>>>>>>>>
>>>>>>>>>> Tested in mach5 tiers 1-6.
>>>>>>>>>>
>>>>>>>>>> Bug:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8242484
>>>>>>>>>>
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8242484/v1/webrev/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Patricio
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
> 


More information about the hotspot-runtime-dev mailing list