RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables

David Holmes david.holmes at oracle.com
Mon Nov 23 07:03:14 UTC 2015

After all the preliminary discussions here are final proposed changes:

bug: https://bugs.openjdk.java.net/browse/JDK-8132510

Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/

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;

with an appropriate setter of course. By doing this we can completely 
remove the os_cpu-specific ThreadLocalStorage implementations, and the 
associated os::thread_local_storage* calls.

As __thread is not async-signal-safe (either in theory or practice) we 
need a fallback library-based solution as used today. For this we use a 
very simple ThreadLocalStorage class and an implementation thereof for 
POSIX (covers AIX, BSD, Linux, OSX and Solaris) using 
pthread_get/setspecific; and one for Windows using its TLS library. 
While these library routines are not guaranteed async-signal-safe, they 
seem to be in practice and are what we have been using all along.

We also allow for use of only the library-based TLS for platforms where 
compiler-based thread locals are not supported (as will be needed in the 
Mobile project). This is enabled at build time by defining 

Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas 
Stuefe for testing PPC and AIX.

  - JPRT (core platforms)
  - Jtreg tests (linux & solaris)
  - vm.runtime (core platforms)

  - still TBD - this is proving to be extremely difficult. If anyone has 
any simple to run microbenchmarks to suggest I'd give them a try as a 
sanity check. But I lack access to hardware for running serious 

- varies by platform and the VM (server, client, minimal)
- worst-case: ~1% increase for server VM and minimal VM
- best-case:  0.4% decrease for client VM


More information about the hotspot-dev mailing list