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

[Robbin Ehn]

Hi David,

On 2018-01-18 13:37, David Holmes wrote:
> 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.

Yes, but we(I) would like to able to terminate the pthread earlier than the JavaThread.

The destructor of JavaThread can now only be run by the osthread that belong to the JavaThread.
If a JavaThread exits but is still on a SMR-ThreadsList it would be nice to beable to exit the pthread
and let the destructor be run by e.g. the last thread destroying a ThreadsList that have the exiting thread on it.
This also would allow osthread reuse and doubling as two types of thread, etc... (no concrete use-case for this now)
Basically a nice to have feature.

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

A call to Thread::current() will be considerable slower than getting os::get_polling_page().

/Robbin

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