(L) Prelim RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables
david.holmes at oracle.com
Thu Nov 5 22:54:47 UTC 2015
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 ?
> 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.
More information about the hotspot-dev