RFR(M): 8195112: x86 (32 bit): implementation for Thread-local handshakes

Doerr, Martin martin.doerr at sap.com
Thu Jan 18 11:29:25 UTC 2018

Hi Robbin and Andrew,

thanks for looking at it. I'm also concerned about get_thread on linux 32 bit.
Windows has a fast implementation of it. So would the change be acceptable if we switch off ThreadLocalHandshakes by default for linux 32 bit only?
This would still be perfectly ok for us.

Performance impact on Windows 32 bit seems to be very low. Is anybody concerned about Windows 32 bit performance?

Best regards,

-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Donnerstag, 18. Januar 2018 12:05
To: Robbin Ehn <robbin.ehn at oracle.com>; Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(M): 8195112: x86 (32 bit): implementation for Thread-local handshakes

On 17/01/18 21:04, Robbin Ehn wrote:
> This guy will hurt:
> 712       masm.get_thread(pollReg);
> Since we are not shipping 32-bit but RedHat is (at least in Fedora)
> and they don't object (or anyone else) I'm fine with this.

Don't mistake silence for consent.  The most likely explanation is
that we haven't noticed yet.  You're right, it will hurt.  Perhaps
Thread-local handshakes aren't right for x86-32, or perhaps we can
come up with a better way to do get_thread(pollReg).  I'll have a

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-runtime-dev mailing list