RFR (S) 8235962: os::current_thread_id() is not signal safe on macOS

[gerard ziemski]

hi all,

Before JDK-8022808 we used to call "mach_thread_self()" to obtain a 
thread id, but back then we forgot to release the returned mach port, 
which would make a long running java process (like Kitchensink) 
eventually run out of resources and hang it.

To solve that, in JDK-8022808, we switched to using 
"pthread_mach_thread_np(pthread_self())", which returns a static mach 
port, which does not need to be released.

However, the "pthread_mach_thread_np()" API, which we started using is 
specifically knownn as not async-signal-safe API and that might cause an 
issue, because we use it to generate thread ids in hs_err_pid.log crash 
log files in our signal handler, which requires that only 
async-signal-safe API be used.

Our crash handler is best effort approach, and to this extend I'd like 
to propose a fix, which reverts back to using "mach_thread_self()", 
which I must admit is unknown whether it itself is async-signal-safe, 
though it's not part of pthread API, like "pthread_mach_thread_np()" 
which itself is not part of async-signal-safe APIs (IEEE Std 1003.1, 
2016). Additionally, the reporter of the issue suggest that it solves 
the actual issue with using "pthread_mach_thread_np()" for them in their 
project, so let's benefit from their experience.

In this fix we revert back to using "mach_thread_self()" API, but make 
sure to release the mach port, and use MACH_PORT_VALID() macro to verify 
the validity of mach port.

bug: https://bugs.openjdk.java.net/browse/JDK-8235962
webrev: http://cr.openjdk.java.net/~gziemski/8235962_rev1/index.html
Tested with Mach5 tier1,2,3,4,5 and Kitchensink24 and 
Kitchensink24Stress locally on Mac laptop over 2 days.


cheers