RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be unloaded [v2]
Ioi Lam
iklam at openjdk.org
Fri Feb 10 17:32:10 UTC 2023
On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at 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.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
>
> - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
> - Removed unused import of STRONG und updated copyright year
Even in JDK 11, a lambda proxy classes that's referenced by the cpCache (i.e., from a resolved invokedynamic instruction associated with a lamda expression) is always kept alive. See test below.
So if I understand correctly, this patch will not affect lamda expressions in Java source code. It affects only direct calls to `LambdaMetafactory.metafactory()`. Is this correct?
public class LambdaGC {
public static void main(String[] args) throws Throwable {
System.out.println("Entering LambdaGC");
doit(() -> {
Thread.dumpStack();
});
for (int i = 0; i < 10; i++) {
System.gc();
}
System.out.println("Finish LambdaGC");
}
static void doit(Runnable r) {
r.run();
}
}
$ java11 -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames -Xlog:class+load -Xlog:class+unload LambdaGC | grep LambdaGC
[0.022s][info][class,load] LambdaGC source: file:/jdk3/tmp/
Entering LambdaGC
[0.024s][info][class,load] LambdaGC$$Lambda$1/0x0000000840060840 source: LambdaGC
java.lang.Exception: Stack trace
at java.base/java.lang.Thread.dumpStack(Thread.java:1387)
at LambdaGC.lambda$main$0(LambdaGC.java:5)
at LambdaGC$$Lambda$1/0x0000000840060840.run(<Unknown>:1000000)
at LambdaGC.doit(LambdaGC.java:13)
at LambdaGC.main(LambdaGC.java:4)
Finish LambdaGC
-------------
PR: https://git.openjdk.org/jdk/pull/12493
More information about the core-libs-dev
mailing list