RFR: 8259068: Streamline class loader locking
Coleen Phillimore
coleenp at openjdk.java.net
Fri Jan 15 02:41:08 UTC 2021
On Fri, 15 Jan 2021 02:04:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>> The system_loader_lock_object is never actually acquired when loading a class with a parallelCapable class loader, which includes the bootloader (class_loader == NULL), except in one place before restore_unshareable_info is called. In this case, the per-class lock (BuiltinLoader.getClassLoadingLock) is held or the placeholder for LOAD_INSTANCE is present which implements mutual exclusion. Ioi and I separately verified this while chasing down another bug.
>> This change removes the system_loader_lock_obj and extraneous code around compute_loader_lock_object to make it consistent. This also removes the bool argument to ObjectLocker. If the oop passed into ObjectLocker is null, we don't lock the object, which is consistent with the Mutex class. This change also passes the class_loader to define_class to save an OopStorage.resolve() call.
>> Tested with tier1-8.
>
> Nice!
>
> `ClassLoader::sync_systemLoaderLockContentionRate()` becomes unused with this change, so could trivially be removed. The underlying perf counter lives in the unstable, unsupported SUN_CLS namespace and can probably be nuked without a CSR or anything, but that might be good for a follow-up.
Thanks Claes, I'll remove them as a follow up. Do you know what tools use these?
-------------
PR: https://git.openjdk.java.net/jdk/pull/2071
More information about the hotspot-dev
mailing list