RFR 8240918: [REDO] Allow direct handshakes without VMThread intervention
Patricio Chilano
patricio.chilano.mateo at oracle.com
Thu Apr 2 15:54:33 UTC 2020
On 4/2/20 8:35 AM, Robbin Ehn wrote:
> Hi Patricio,
>
> Thanks for fixing, looks good.
Great, thanks for reviewing it Robbin!
Patricio
> /Robbin
>
> On 2020-04-01 19:45, 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
More information about the hotspot-runtime-dev
mailing list