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

Robbin Ehn robbin.ehn at oracle.com
Thu Jan 18 12:11:05 UTC 2018

Hi Martin,

On 2018-01-18 12:29, Doerr, Martin wrote:
> 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.

If Andrew don't find a solution that require reasonable effort for Linux, I'm fine with this also.


> Performance impact on Windows 32 bit seems to be very low. Is anybody concerned about Windows 32 bit performance?
> Best regards,
> Martin
> -----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
> look.

More information about the hotspot-runtime-dev mailing list