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

[Vladimir Ivanov]

> 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 
reentrant!)

> 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

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020417.html

"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 
logic."



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