On Tue, 29 Apr 2025 19:02:20 GMT, Chen Liang <li...@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. 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. Hopef ully David will remember more of this when he gets back. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2841672692
