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

Doerr, Martin martin.doerr at sap.com
Thu Feb 8 13:04:30 UTC 2018


Hi Andrew,

thanks for looking at the get_thread issue.

Are you planning to fix it soon?
If so, we can delay my change until it was pushed.

Otherwise, we can keep ThreadLocalHandshakes off by default on linux x86 32 bit.
That would be ok for us, too. We'd just like the feature to be available.

What do you prefer?

Best regards,
Martin


-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
Sent: Donnerstag, 18. Januar 2018 16:12
To: David Holmes <david.holmes at oracle.com>; Robbin Ehn <robbin.ehn at oracle.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(M): 8195112: x86 (32 bit): implementation for Thread-local handshakes

On 18/01/18 12:37, David Holmes wrote:
> Thread::current() already uses compiler-based TLS. get_thread (on 
> non-Windows x86) make a VM call to Thread::current(). If we want to get 
> faster here we have to introduce compiler specific hooks directly into 
> the TLS implementation (not nice to do initially or maintain).

We already have that because we have os_cpu, so there's nothing to
stop us putting a Linux/glibc special in there.  As you say, we already
have a fast path for windows.

-- 
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