RFR(S) 8187040: ThreadCritical crashes on Solaris if used between os::init and os::init_2

[David Holmes]

Hi Mikael,

This cleanup looks good. Obviously things got out of sync on solaris 
when we've split os::init into pieces in the past. And this solaris-only 
requirement should never have leaked through to the other ports. So good 
to see the cleanup.

As Thomas notes there may be something that can be implicitly checked 
instead of adding the new field, but that is a minor concern.

Thanks,
David

On 2/09/2017 1:23 AM, Mikael Gerdin wrote:
> Hi,
> 
> Please review this small fix to ThreadCritical.
> When working on a piece of code which allocates memory early on I 
> noticed that it crashed if I enabled NMT.
> The reason is that NMT uses ThreadCritical and os::Solaris sets the 
> ThreadCritical::_initialized flag before it actually sets up the 
> function pointers the flag is supposed to guard.
> os::Solaris::_mutex_lock is not initialized until the init_2 phase 
> (after command line flag parsing).
> 
> My suggested fix is to replace the current short-circuit of 
> ThreadCritical with a flag set when the Solaris mutex code is 
> initialized and thereby getting rid of the initialize function on all 
> platforms.
> Additionally, ThreadCritical::release is unreachable code and from my 
> research has never actually been called, we might as well get rid of it.
> 
> Webrev: http://cr.openjdk.java.net/~mgerdin/8187040/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187040
> Testing: JPRT
> 
> Thanks
> /Mikael