RFR(S) 8187040: ThreadCritical crashes on Solaris if used between os::init and os::init_2
david.holmes at oracle.com
Mon Sep 4 00:57:26 UTC 2017
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.
On 2/09/2017 1:23 AM, Mikael Gerdin wrote:
> 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
> 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
More information about the hotspot-runtime-dev