RFR: 8196083: Avoid locking in OopStorage::release

[David Holmes]

On 4/02/2018 10:38 PM, Erik Osterlund wrote:
> Hi Kim,
> 
> Looks complicated but good.
> 
> It would be great in the future if the deadlock detection system could be improved to not trigger such false positives that make us implement tricky lock-free code to dodge the obviously false positive deadlock assert. But I suppose that is out of scope for this.

It isn't a deadlock-detection system it is a deadlock prevention system. 
If you honour the lock rankings then you can't get deadlocks. If you 
don't honour the lock rankings then you may get deadlocks. There isn't 
sufficient information in the ranking alone to know for sure whether you 
will or not.

If the deadlock possibility is so obviously not actually possible then 
that could be captured somehow for the specific locks involved. But I'm 
not aware of any tools we have that actually help us track what locks 
may concurrently be acquired - if we did then we would not need 
rank-based deadlock prevention checks.

David
-----

> Thanks,
> /Erik
> 
>> On 3 Feb 2018, at 01:35, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>> Please review this change to the OopStorage::release operations to
>> eliminate their use of locks.  Rather than directly performing the
>> _allocate_list updates when the block containing the entries being
>> released undergoes a state transition (full to not-full, not-full to
>> empty), we instead record the occurrence of the transition.  This
>> recording is performed via a lock-free push of the block onto a list
>> of such deferred updates, if the block is not already present in the
>> list.  Update requests are processed by later allocate and
>> delete_empty_block operations.
>>
>> Also backed out the JDK-8195979 lock rank changes for the JNI mutexes.
>> Those are no longer required to nested lock rank ordering errors.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8196083
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8196083/open.00/
>>
>> Testing:
>> Reproducer from JDK-8195979.
>> Mach5 {hs,jdk}-tier{1,2,3}
>>
>