RFR 8232733: Remove need to grab Threads_lock while processing handshakes

[coleen.phillimore at oracle.com]

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.

I was going to complain about the 
assert_locked_or_safepoint_or_handshake() but I don't see a nicer way to 
do that.

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