[External] : Re: Lambda Classes reachability from GC roots in JDK11 and JDK17

[Chen Liang]

Hi Prasad,
1. The lambdas generated from Class::method, () -> {}, and instance::method are all from LambdaMetafactory (if you look at the BootstrapMethods attribute from javap -c -v output), so they always have the same behavior.
2. For JDK 11, according to https://github.com/openjdk/jdk/pull/12493 they were not strongly tied, but I personally don't know about the details back then.

Chen
________________________________
From: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Sent: Wednesday, June 12, 2024 10:35 AM
To: Chen Liang <chen.l.liang at oracle.com>
Subject: [External] : Re: Lambda Classes reachability from GC roots in JDK11 and JDK17


Thanks Chen for the reply..



Just to clarify, my first question was on the lambda classes loaded from Lambda expressions(Lexical Lambdas), not the classes created from LambdaMetafactory.



Suppose in this example the line StringFunction ask = LambdaExpressionsUtil::printLambdaTest; generates a Lambda class. So, I am curious to know, does this lambda class is STRONGLY tied to defining class loader in JDK11?





Example1 ::



interface StringFunction {

         String print(String str);

}



public class LambdaExpressionsUtil {



public static String printLambdaTest(String str) {

              System.out.println(str);

              return str;



  }



public static void main(String[] args) throws IllegalAccessException, LambdaConversionException, Throwable {

       StringFunction ask = LambdaExpressionsUtil::printLambdaTest;

       ask.print("Lambda Expression ask");

}

}







Regards,

Prasad





From: Chen Liang <chen.l.liang at oracle.com>
Date: Wednesday, 12 June 2024 at 8:52 PM
To: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Subject: Re: Lambda Classes reachability from GC roots in JDK11 and JDK17

[External Email]



________________________________

Hello Prasad,

I can confirm the first one is accurate for JDK 15 and later (see JEP 371: Hidden Classes). Lambda classes from LambdaMetafactory are strongly linked to the defining class (the lookupClass of the input Lookup) and its class loader, and is intended to stay this way. Unfortunately I am not sure about the VM, hope someone can pick up the metaspace part of your question. But I've heard that since lambda classes are bounded to the lookup class loader, they use less memory as they don't need to be tracked separately for garbage collection,



-Chen

________________________________

From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Sent: Wednesday, June 12, 2024 9:37 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Lambda Classes reachability from GC roots in JDK11 and JDK17



A gentle reminder on these questions… Could you please respond?



Regards,

Prasad.



From: Prasad Velagapudi <prasad.velagapudi at servicenow.com>
Date: Thursday, 6 June 2024 at 8:10 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Lambda Classes reachability from GC roots in JDK11 and JDK17

Hello Lambda Experts,



I am looking for clarifications on the following questions.



  1.  I observed in my tests that lambda classes generated for inline lambda expressions (ex: LambdaUtil::print), are STRONGLY linked to defining class loader and never gets collected on GC. This behaviour is same in both JDK11 and JDK17. Can you please confirm is this accurate?
  2.  Also, I observed that the lambda classes generated for inline lambda expressions (ex: LambdaUtil::print) not adding additional overhead to Metaspace in JDK17 compared to that of JDK11 . Can you please confirm is this accurate?





Regards,

Prasad






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240612/092e7d40/attachment-0001.htm>