RFR: 8154750: Add missing OrderAccess operations to ClassLoaderData lock-free data structures

[David Holmes]

Bug: https://bugs.openjdk.java.net/browse/JDK-8154750

webrev: http://cr.openjdk.java.net/~dholmes/8154750/webrev/

The initial aim for this bug was to restore a storestore barrier that 
was mistakenly removed (having been put in the wrong place in the first 
place). But looking further at the code the _packages, _modules and 
_metaspace data structures all follow the same basic lazy-initialization 
process using the double-checked-locking idiom, which results in a 
lock-free read when the data structure has already been allocated. The 
correct form of this pattern is:

temp = load_ptr_acquire(&_var);
if (temp == NULL) {
    MutexLocker m(_lock);
    // check if _var was allocated while we got the lock
    if ((temp = _var) == NULL) {
      temp = new Var();
      release_store_ptr(&_var, temp);
    }
}
return temp;

and that has been implemented. The other raw uses of _packages and 
_modules only occur under the Module_lock or at a safepoint. _metaspace 
is not used directly.

The lock-free traversal of the _klass list also needs to use appropriate 
OrderAccess operations. We have storestore() on the write path but 
nothing on the read path - so again a release_store_ptr() and 
load_ptr_acquire() pairing should be used. The problem in this case is 
trying to identify which accesses are actually lock-free as there a 
number of entry points: classes_do, contains_klass, verify etc. So I 
added an assert_locked_or_safepoint(_metaspace_lock) to each of these 
and started running tests. If the assert failed I replace the raw read 
of _klasses with a load_ptr_acquire. The remaining assertions have not 
yet fired so they appear to be locked/safepointed paths. Of course it 
may simply be that that these paths have not been exercised - though I 
did try to track each of their usages, and for example verified that 
verify() was called.

Testing: JPRT, runtime-nightly-tests via RBT

Thanks,
David