RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class

[Alan Bateman]

On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.
>
>> The bug description seems like it is a fault in the JVM implementation - if that is the case, a core library bypass is unreliable, as such faults might happen to other classes and cause other consequences; and we might need to fix it from the VM runtime or compiler side, as the original report implies.
> 
> It seems to about nested parking that can arise with the first use of LockSupport.park from a class with a defining class loader that is not the boot loader. The first usage, say an invokestatic to call the park method, will call the loadClass on caller's defining class loader.  For the app class loader, and many other custom class loaders, that are parallel capable, then there will be a CHM to support the mapping of class names to locks. Contention on the CHM seems to have lead to the nested park.  CHM and a lot of other code has changed since and not clear that it will duplicate easily now. Martin's ParkLoops test from the 2015 issue is in the test tree but it might be that a variant of this that uses a custom class loader that overrides getClassLoadingLock or parks in loadClass might be able to trigger it. As a custom class loader's loadClass can do anything then it almost feels like creating a class loader needs it have it recorded immediately as an initiating class loader. Hop
 efully David will remember more of this when he gets back.

> I'll second @AlanBateman 's sentiments here. I think a systemic issue needs a wholesale solution, otherwise it'll just lead to endless sprinkling of eager initializations.

Right, and even then, the issue is deeper than this. It's when the reference to LockSupport is from a class with a non-null defining class loader. In that scenario, the non-null class loader is the initiating class loader and any parking in the delegation chain to get to the boot loader could potentially consume the park permit. I don't think we should go down the road of supporting nested parking, instead it may be that we need some eager setup. I think we can close this PR for now as it doesn't really address the issue (LockSupport is already loaded before any user code executes).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2862877836