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

[Staffan Larsen]

Thanks for doing this!

There are a couple of comments in SA that reference LinuxThreads and can probably be cleaned up. Other than that I didn’t see any direct impact on SA.

Thanks,
/Staffan

> On 5 maj 2015, at 15:16, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> 
> 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