On Thu, 9 Feb 2023 15:20:23 GMT, Volker Simonis <simo...@openjdk.org> wrote:
> Prior to > [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) > LambdaMetaFactory has created VM-anonymous classes which could easily be > unloaded once they were not referenced any more. Starting with JDK 15 and the > new "hidden class" based implementation, this is not the case any more, > because the hidden classes will be strongly tied to their defining class > loader. If this is the default application class loader, these hidden classes > can never be unloaded which can easily lead to Metaspace exhaustion (see the > [test case in the JBS > issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). > This is a regression compared to previous JDK versions which some of our > applications have been affected from when migrating to JDK 17. > > The reason why the newly created hidden classes are strongly linked to their > defining class loader is not clear to me. JDK-8239384 mentions it as an > "implementation detail": > >> *4. the lambda proxy class has the strong relationship with the class loader >> (that will share the VM metaspace for its defining loader - implementation >> details)* > > From my current understanding the strong link between a hidden class created > by `LambdaMetaFactory` and its defining class loader is not strictly > required. In order to prevent potential OOMs and fix the regression compared > the JDK 14 and earlier I propose to create these hidden classes without the > `STRONG` option. > > I'll be happy to add the test case as JTreg test to this PR if you think that > would be useful. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12493
