On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman <al...@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
