(L) Prelim RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables

David Holmes david.holmes at oracle.com
Thu Nov 5 22:54:47 UTC 2015


Hi Andrew,

On 6/11/2015 2:01 AM, Andrew Haley wrote:
> On 11/05/2015 10:20 AM, Andrew Haley wrote:
>> On 05/11/15 04:36, David Holmes wrote:
>>> I still need some assistance from Aarch64 folk to write their get_thread
>>> function please!
>
> Here you are.
>
> I found a bug in the existing AArch64 get_thread.
>
> The specification of MacroAssembler::get_thread() is that it clobbers
> no registers.  Most of the vector state is callee-clobbered, so if you
> want to call a get_thread() method which is written in C you have to
> save the entire vector state as well as all call-clobbered general
> registers.  You have to do this because it is possible that GCC will
> use a vector register for temporary storage.  (This is not just a
> theoretical possibility: I have seen AArch64 bugs caused by this
> actually happening.)  So, I wrote code to save all the general and
> vector registers.  It was horrible.
>
> I scrapped it and instead wrote a little assembly-language routine
> which returns the contents of Thread::_thr_current.  This clobbers
> only a couple of registers, and everything is much nicer.

Not sure why you had to inject the helper rather than just "call" 
Thread::current() ?? But it's your code :)

However all of the threadLS_<os>_<arch> files have been deleted but you 
have added a .s file using that now-defunct naming scheme. Would it be 
better named something else - that relates it back to the 
thread_linux_aarch64.hpp usage ie thread_linux_aarch64.s ?

Many thanks,
David

> I suppose it might have been possible to change the specification of
> MacroAssembler::get_thread() so that it clobbered the vector state,
> but never mind: it's done now.
>
> Andrew.
>


More information about the hotspot-dev mailing list