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

[David Holmes]

On 2/11/2015 5:41 PM, Per Liden wrote:
> Hi David,
>
> On 2015-11-02 07:40, David Holmes wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>> A simple (in principle) but wide-ranging change which should appeal to
>> our Code Deletion Engineer's. We implement Thread::current() using a
>> compiler/language-based thread-local variable eg:
>>
>>
>>   static __thread Thread *_thr_current;
>>
>>   inline Thread* Thread::current() {
>>     return _thr_current;
>>   }
>
> Do we expect the cost of calling Thread::current() to go down with this
> change or will it remain about the same?

Depends on the platform and the exact circumstances, given the varied 
caching and other "fast lookup" schemes previously employed (even though 
this is slow-path code). I do not expect it to be slower in general but 
we will be somewhat at the mercy of the particular platform 
implementation. The earlier Solaris change showed mildly positive 
results. I'll be starting some performance runs tomorrow.

> Btw, this looks like a really nice cleanup/simplification!

Thanks,
David

> cheers,
> /Per
>
>>
>> with an appropriate setter of course. By doing this we can completely
>> remove the platform-specific ThreadLocalStorage implementations, and the
>> associated os::thread_local_storage* calls, plus all the uses of
>> ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow().
>> This extends the previous work done on Solaris to implement
>> ThreadLocalStorage::thread() using compiler-based thread-locals.
>>
>> We can also consolidate nearly all the os_cpu versions of
>> MacroAssembler::get_thread on x86 into one cpu specific one ( a special
>> variant is still needed for 32-bit Windows).
>>
>> As a result of this change we have further potential cleanups:
>> - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely
>> empty and could also be removed
>> - the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map
>> "cache" on 32-bit) now has no affect and so could be completely removed
>> from the build system
>>
>> I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could
>> add the removal of the "inline" files to this CR if people think it
>> worth removing them.
>>
>> I have one missing piece on Aarch64 - I need to change
>> MacroAssembler::get_thread to simply call Thread::current() as on other
>> platforms, but I don't know how to write that. I would appreciate it if
>> someone could give me the right code for that.
>>
>> I would also appreciate comments/testing by the AIX and PPC64 folk as
>> well.
>>
>> A concern about memory-leaks had previously been raised, but experiments
>> using simple C code on linux 86 and Solaris showed no issues. Also note
>> that Aarch64 already uses this kind of thread-local.
>>
>> Thanks,
>> David