On Fri, 10 Feb 2023 17:29:37 GMT, Ioi Lam <ik...@openjdk.org> wrote:
>> 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
@iklam, I think your understanding is correct. While the bootstrap methods for
Java Lambdas do call `LambdaMetafactory.metafactory()`, they store the
resulting call site (for Lambdas a `BoundMethodHandle`) in the appendix slot of
the constant pool cache entry of the invokedynamic bytecode. The
`BoundMethodHandle` contains a reference to an instance of the generated lambda
form (i.e. in your example `LambdaGC$$Lambda$1`). This is enough in order to
keep `LambdaGC$$Lambda$1` alive and prevent its unloading.
Until now, `LambdaGC$$Lambda$1` was also strongly linked to its defining class
loader, but I don't think that's necessary to keep it alive (because it is
referenced from the call site which is referenced from the constant pool cache).
Running your example with `-Xlog:indy+methodhandles=debug` confirms this:
set_method_handle bc=186 appendix=0x000000062b821838 method=0x00000008000c7698
(local signature)
{method}
- this oop: 0x00000008000c7698
- method holder: 'java/lang/invoke/Invokers$Holder'
...
appendix: java.lang.invoke.BoundMethodHandle$Species_L
{0x000000062b821838} - klass: 'java/lang/invoke/BoundMethodHandle$Species_L'
- ---- fields (total size 5 words):
...
- final 'argL0' 'Ljava/lang/Object;' @32 a
'LambdaGC$$Lambda$1+0x0000000801000400'{0x000000062b81e080} (0xc5703c10)
-------------
PR: https://git.openjdk.org/jdk/pull/12493
