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