RFR(S): 8148696: Race loading hsdis may cause SIGSEGV
vladimir.x.ivanov at oracle.com
Fri Feb 5 16:54:15 UTC 2016
> 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
> 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.
"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/
> Nils Eliasson
More information about the hotspot-compiler-dev