RFR(S): 8148696: Race loading hsdis may cause SIGSEGV

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Feb 5 16:54:15 UTC 2016

> Summary:
> We have had two crashes on Sparc where two C2 thread simultaneously
> tries to load the hsdis library. Three of four code paths are locked by
> the ttyLocker, but the fourth is open to races.
I'd suggest to either add ttyLocker on the fourth path or try to move it 
down the call chain to some shared code. (Keep in mind that ttyLocker is 

> Solution:
> I chose to add another lock (mutex) for this purpose and adapted the
> code so that library_load code works as intented.
Another mutex will not work - tty_lock has the lowest rank (event):
   def(tty_lock                     , Mutex  , event,       true, 
Monitor::_safepoint_check_never);      // allow to lock in VM

I experimented with that when fixing 8071374, but decided to guard 
everything with tty_lock.

Best regards,
Vladimir Ivanov


"The fix is to serialize access to Disassembler on tty_lock.
Considering most of the calls to Disassembler::decode are performed 
under tty_lock (which has the lowest rank), it's too burdensome to 
introduce a dedicated lock and a new rank to please deadlock detection 

> Bug: https://bugs.openjdk.java.net/browse/JDK-8148696
> Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/
> Regards,
> Nils Eliasson

More information about the hotspot-compiler-dev mailing list