RFR 8240918: [REDO] Allow direct handshakes without VMThread intervention

[coleen.phillimore at oracle.com]

This looks good to me.  Thank you for the comment why here, which will 
prevent us from trying to figure that out again someday:

+ } else {
+ // Clear value for _thread_key in TLS to prevent, depending
+ // on pthreads implementation, possible execution of
+ // thread-specific destructor in infinite loop at thread
+ // exit.
+ Thread::clear_thread_current();
+ }

Coleen

On 4/1/20 1:45 PM, Patricio Chilano wrote:
> Hi all,
>
> Please review this redo for 8230594. Since the reason behind the 
> Windows timeouts turned out to be 8240902, this patch is almost 
> identical to the reverse of the backout modulo the rebase.
>
> There is only one small fix for an issue not identified in the 
> original patch which I explained in the comments. To avoid this 
> possible issue of deleting a JavaThread that called 
> Thread::destroy_vm() while there are handshakers blocked in the 
> handshake_turn_sem semaphore, I added a check to verify the JavaThread 
> in question is not protected by some ThreadsList reference before 
> attempting the delete it. In case it is protected, we need to at least 
> clear the value for _thread_key to avoid possible infinite loops at 
> thread exit (this can happen in Solaris).
>
> The only other change is that I removed the check for local polls in 
> Handshake::execute_direct() since after the backout, thread-local 
> handshakes was implemented for arm32 which was the only remaining 
> platform.
>
> I tested it several times in mach5 tiers 1-6 and once in t7 and saw no 
> failures.
>
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8240918
>
> Webrev:
>    http://cr.openjdk.java.net/~pchilanomate/8240918/v1/webrev/
>
>
> Thanks,
> Patricio