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.

Your analysis in the JBS issue seems reasonable, but I'll wait for Mandy to 
respond here.

I looked at the original PR and don't see a discussion of `STRONG` there, but I 
very vaguely remember it being talked about as being needed to fix a latent 
issue (I don't remember the details though).

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java 
line 383:

> 381:             if (useImplMethodHandle) {
> 382:                 lookup = 
> caller.defineHiddenClassWithClassData(classBytes, implementation, 
> !disableEagerInitialization,
> 383:                                                                NESTMATE, 
> STRONG);

Please remove the import for this constant as well. It seems to be unused now.

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

PR: https://git.openjdk.org/jdk/pull/12493

Reply via email to