RFR: 8196083: Avoid locking in OopStorage::release

[Erik Osterlund]

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.

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