RFR 8240918: [REDO] Allow direct handshakes without VMThread intervention
Robbin Ehn
robbin.ehn at oracle.com
Thu Apr 2 11:35:44 UTC 2020
Hi Patricio,
Thanks for fixing, looks good.
/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