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

[Patricio Chilano]

Hi Coleen,

On 4/2/20 9:58 AM, coleen.phillimore at oracle.com wrote:
>
> This looks good to me.  Thank you for the comment why here, which will 
> prevent us from trying to figure that out again someday:
Right, that was the idea.  : )

> + } 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();
> + }
Thanks for looking at this Coleen!


Patricio
> 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
>