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

[David Holmes]

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