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

[Doerr, Martin]

Hi David,

> why is using get_thread so bad for TLH?
Interpreter and C1 JIT compiler don't keep the JavaThread* in a register on x86. (Only C2 can decide to do so.)
So get_thread will be used for every safepoint poll (except C2 which can optimized better) which is bad in loops.

Best regards,
Martin


-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Donnerstag, 18. Januar 2018 13:37
To: 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/2018 10:09 PM, Robbin Ehn wrote:
> On 2018-01-18 12:53, Andrew Haley wrote:
>> On 18/01/18 11:38, Robbin Ehn wrote:
>>> Martin address you directly in RFR and I ask for a review from you 
>>> guys, what more could we have done?
>>
>> Have patience.  This patch was proposed three days ago, during a
>> critical patch release period.  I'll look at fast algorithms for
>> Thread::current().
>>
> 
> There was never no rush and I was waiting for you to respond. 
> JavaThread lifecycle don't match pthread lifecycle, so moving to a

Not sure what you mean here. JavaThread lifetime is an interval on the 
pthread lifetime: starts after pthread and finishes before pthread.

> tls algorithm where we can control the lifetime would be great IMHO.

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

I think I missed a key part here: why is using get_thread so bad for TLH?

Thanks,
David
-----


> For normal JavaThread (non-attaching) I guess we can put them under
> stack if we allocate stack our-self. I think attaching threads is the
> nut to crack. >
> /Robbin