RFR 8232733: Remove need to grab Threads_lock while processing handshakes

[Patricio Chilano]

Hi Coleen,

On 12/9/19 4:03 PM, coleen.phillimore at oracle.com wrote:
>
> Hi Patricio,  This looks good.  Nice job resolving the questions 
> around this code.  Hopefully, this gets us closer to Threads_lock only 
> protecting thread addition, creation and iteration.
Thanks!

> I was going to complain about the 
> assert_locked_or_safepoint_or_handshake() but I don't see a nicer way 
> to do that.
And that is a method that we will probably need more often if we expand 
the use and functionality of handshakes.

Thanks for looking into this Coleen!

Patricio
> LGTM.
> Coleen
>
> On 12/6/19 2:40 PM, Patricio Chilano wrote:
>> Hi all,
>>
>> Please review the following patch that removes the requirement of 
>> having to acquire the Threads_lock while processing handshakes. The 
>> guarantee that the JavaThread being handshaked will not exit and its 
>> memory be freed is already provided by using SMR ThreadsLists. With 
>> respect to the comments that the Threads_lock is needed to avoid a 
>> suspended JavaThread from being resumed, that will not be a problem 
>> since the JavaThread will still make the proper transition after 
>> being resumed and will block if needed for the handshake.
>>
>> Tested with mach5, tiers1-7.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232733
>> Webrev: http://cr.openjdk.java.net/~pchilanomate/8232733/v01/webrev/
>>
>> Thanks,
>>
>> Patricio
>