RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used

[Kim Barrett]

> On Jan 24, 2018, at 4:25 PM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> 
> Hi Kim,
> 
> I guess the ranks you use now are really equivalent to the 'access' ranks, that I introduced earlier, and are currently used by G1 barrier locks.
> I don't mind though if you call them that or not, and understand you just want a quick fix for this.

I intentionally didn’t name them relative to the “access" ranks.

The desired ranks need to be more special than “special”, and are semantically unrelated to the “access" ranks.
That they are numerically equivalent to the “access” ranks is coincidental.

> Looks good.

Thanks.

> Thanks,
> /Erik
> 
> 
> On 2018-01-24 20:52, Kim Barrett wrote:
>> Please review this workaround for a lock rank ordering issue. When
>> using Graal, JNI references are released while holding the
>> Patching_lock (a rank=special lock).
>> 
>> Before the reimplementation of JNI global and weak global handles
>> using OopStorage (JDK-8194312), releasing such references was
>> accomplished without any locking. However, OopStorage::release
>> sometimes locks its allocation mutex. This change led to the reported
>> lock rank order problem for Graal.
>> 
>> As a temporary workaround we're reducing the ranks of the JNI
>> oopstorage mutexes, making them more special than "special", so they
>> can be locked while holding the Patching_lock. A better solution
>> (JDK-8196083) is being developed, but may take a little time. In the
>> interest of unblocking Graal testing, the simple rank reduction is
>> being proposed, even though it's ugly.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8195979
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8195979/open.00/
>> 
>> Testing:
>> Mach5 hs-tier{1-5}, jdk-tier{1-3}
>> Local testing of Ekaterina's reproducer in CR.