Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b12
Description
Lambda-class names in the JDK are unstable, i.e., their names across different VM runs are not the same. The format of the lambda-class name is `<declaring_class>$$Lambda$<counter>/#<hidden_class_reference>`. The instability comes from: the `<counter>` that is assigned a value from a concurrently incremented `java.lang.invoke.InnerClassLambdaMetafactory#counter`, and the `<hidden_class_reference>` that represents the reference value used for the hidden class.
GraalVM Native Image requires the `<counter>` part of the lambda name to be stable:
- *To register lambda classes for serialization*. Native Image uses configuration files to collect class names for the classes that should be registered for serialization. Unstable lambda-class names prevent Native Image from running any code that uses lambda-class serialization.
- *For reproducible builds* (https://github.com/oracle/graal/issues/291). Generated class files for the same lambda are different because of the class names. Therefore, executables generated by the Native Image from the same bytecode can not be the same if they contain lambda classes.
- *For incremental reachability analysis*. The goal is to use analysis incrementally by storing the summaries and reusing them in subsequent builds. Therefore, we need stable identifiers for all types, methods, and fields.
- *To collect profiles of lambda methods for profile-guided optimizations*. In the instrumented profiling image the lambda classes will not be the same as the ones in the optimized image. Therefore, it is hard to correlate the collected profiles between the two runs.
- *To reflectively access lambdas*. At build time, Native Image registers all the methods that should be called reflectively; the configuration files used for registration use fully qualified class names. Currently, using reflection on lambda classes on Native Image is not possible.
To support the abovementioned cases, GraalVM needs a flag that will generate lambda classes with stable names. With the flag enabled, the `<counter>` part of the lambda-class name needs to be replaced with a stable hash. The hash needs to be calculated using a superset of the parameters used for lambda-class data sharing (see `java.lang.invoke.LambdaProxyClassArchive#register`).
The proposed solution for this issue is:
https://github.com/openjdk/jdk/pull/10024
GraalVM Native Image requires the `<counter>` part of the lambda name to be stable:
- *To register lambda classes for serialization*. Native Image uses configuration files to collect class names for the classes that should be registered for serialization. Unstable lambda-class names prevent Native Image from running any code that uses lambda-class serialization.
- *For reproducible builds* (https://github.com/oracle/graal/issues/291). Generated class files for the same lambda are different because of the class names. Therefore, executables generated by the Native Image from the same bytecode can not be the same if they contain lambda classes.
- *For incremental reachability analysis*. The goal is to use analysis incrementally by storing the summaries and reusing them in subsequent builds. Therefore, we need stable identifiers for all types, methods, and fields.
- *To collect profiles of lambda methods for profile-guided optimizations*. In the instrumented profiling image the lambda classes will not be the same as the ones in the optimized image. Therefore, it is hard to correlate the collected profiles between the two runs.
- *To reflectively access lambdas*. At build time, Native Image registers all the methods that should be called reflectively; the configuration files used for registration use fully qualified class names. Currently, using reflection on lambda classes on Native Image is not possible.
To support the abovementioned cases, GraalVM needs a flag that will generate lambda classes with stable names. With the flag enabled, the `<counter>` part of the lambda-class name needs to be replaced with a stable hash. The hash needs to be calculated using a superset of the parameters used for lambda-class data sharing (see `java.lang.invoke.LambdaProxyClassArchive#register`).
The proposed solution for this issue is:
https://github.com/openjdk/jdk/pull/10024
