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.
/Robbin
>
> 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