RFR(s): 8078513: [linux] Clean up code relevant to LinuxThreads implementation

[Thomas Stüfe]

Hi all,

This fix is a follow-up from my earlier question:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018186.html

webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.00/webrev/
bug:    https://bugs.openjdk.java.net/browse/JDK-8078513


This change removes (I hope all) remnants of code dealing with LinuxThreads
from the hotspot.

Discussion of the changes:

1) on LinuxThreads, each thread had an own pid, so getpid() would return a
unique pid for every thread it was invoked in. On NPTL, this is not an
issue anymore; getpid() works as expected returning a global pid.
For LinuxThreads, there was a workaround where at VM startup the pid was
captured (on the thread invoking CreateJavaVM) and this pid was stored in
static variable _initial_pid and returned in  os::current_process_id().
Later another workaround was added because CreateJavaVM was not invoked on
the primordial thread anymore, so the pid was handed in via a define (see
Arguments::sun_java_launcher_pid()).

Both workaround were removed and os::current_process_id() was changed to
just return getpid().

2) os::Linux::gettid(): Linux uses the kernel thread id for OSThread thread
id - I did not change that. But by now the system call gettid should be
available in every Linux kernel, so I removed the fallback handling.

3) A number of changes dealt with the way LinuxThreads allocated thread
stacks (with mmap and the MAP_GROWSDOWN flag). On LinuxThreads, it was not
possible to change the size of thread stacks (to start a new thread with a
different stack size). NPTL can do this and all the places where we dealt
with fixed stacks I changed.

4) On LinuxThreads, there is the problem that the thread stacks - which
grow down and are allocated with MAP_FIXED - may at some point trash the
java heap. To prevent this, every allocation done with os::reserve_memory()
and friends recorded a "_highest_vm_reserved_address". There was a function
called "_thread_safety_check" which prevented start of new threads if
thread stacks came dangerously close to the highest reserved address + a
gap; latter gap could be set via parameter ThreadSafetyMargin.

All this coding was removed. Note that this coding probably was already
broken since a long time, because there are many allocations which were not
tracked.

5) Recognition of glibc version and pthread library version were very
elaborate to deal with recognition of LinuxThreads implementation. Those
were dumbed down and now just assert in the highly unlikely case that we
encounter a LinuxThreads implementation.

The rest of the stuff is more straight-forward.

---

I built the changes on Linux x64, x86 and ppc64 and ran jtreg tests
(hotspot/test) on these platforms too. I did not see any issues, but I'd
like to get a couple of reviews for this.

Kind Regards,
Thomas