RFR(S) 8187040: ThreadCritical crashes on Solaris if used between os::init and os::init_2
Mikael Gerdin
mikael.gerdin at oracle.com
Mon Sep 4 07:26:03 UTC 2017
Hi Thomas,
On 2017-09-01 19:31, Thomas Stüfe wrote:
> Hi Mikael,
>
> (I never understood why we cannot just use pthread mutexes on Solaris.
> Why all this dynamic loading magic, are pthread functions not available
> on all Solaris versions?)
Beats me, but I suspect that David is right. At some point someone
thought one was better and now nobody remembers how and nobody wants to
put in the performance work to determine if it actually makes a difference.
>
> Small nit, instead of adding a new variable
> _synchronization_initialized, how about _mutex_lock != NULL (in
> ThreadCritical()) and _mutex_unlock != NULL (in ~ThreadCritical())?
I didn't want to expose the function pointers through accessors in
os::Solaris and I'm worried that if we check a different thing in the
lock versus unlock paths we can end up with a ThreadCritical which tries
to unlock a lock which was never locked (because the TC was created
before _mutex_lock was set).
Also, I think it's clearer to the reader of
os::Solaris::synchronization_init that the "initialization completed"
state is exposed to an external caller.
>
> I am okay with the removal of ::release(). Even if it were used, it is
> really safer to let the mutex live until process end.
I agree.
>
> I leave it up to you if you take my suggestion above. The patch is fine
> for me in the current form.
Thanks for the review, Thomas.
/Mikael
>
> Kind Regards, Thomas
>
>
> On Fri, Sep 1, 2017 at 5:23 PM, Mikael Gerdin <mikael.gerdin at oracle.com
> <mailto:mikael.gerdin at oracle.com>> 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/
> <http://cr.openjdk.java.net/~mgerdin/8187040/webrev.0/>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187040
> <https://bugs.openjdk.java.net/browse/JDK-8187040>
> Testing: JPRT
>
> Thanks
> /Mikael
>
>
More information about the hotspot-runtime-dev
mailing list