RFR: 8196083: Avoid locking in OopStorage::release

[Kim Barrett]

> On Feb 4, 2018, at 7:38 AM, Erik Osterlund <erik.osterlund at oracle.com> wrote:
> 
> Hi Kim,
> 
> Looks complicated but good.

Thanks for looking at it.

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

While I agree that the global lock ranking mechanism has usage
problems, so does every other mechanism I've seen tried for this
issue.

It's possible we would have eventually made this change anyway.
Release was already "mostly" lock-free, to avoid contention when doing
parallel cleanup of data structures containing storage
entries. Whether that would have been good enough is unknown, since we
haven't implemented and measured any such parallel cleanups yet.

> 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}