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

[David Holmes]

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

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

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

Performance:
  - 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 
benchmarking.

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

Thanks,
David