RFR: 8196083: Avoid locking in OopStorage::release

[coleen.phillimore at oracle.com]

Hi, I've reviewed this and I don't see anything wrong.   It looks like 
the necessary OrderAccess and CAS instructions are used on the 
deferred_updates list.

I think this logging should be debug mode because I don't know if you 
want this with -Xlog (default is log everything with info mode, I 
think), except this one:

           log_info(oopstorage, ref)("%s: failed allocation", name());

And here, why do you need to unlink the blocks?  Aren't you deleting 
them below from traversing the main list?

OopStorage::~OopStorage() {
   Block* block;
   while ((block = _deferred_updates) != NULL) {
     _deferred_updates = block->deferred_updates_next();
     block->set_deferred_updates_next(NULL);
   }
   while ((block = _allocate_list.head()) != NULL) {
     _allocate_list.unlink(*block);
   }

Can delete_block just clear all the fields in the block?

thanks,
Coleen

On 2/2/18 7:35 PM, Kim Barrett 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}
>