-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
25
java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm.
Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time".
However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes, because for example (to the courtesy of) [~swen] could not figure out anything with them.
I recommend comment enhancements that convey these to source code readers:
1. The exact generated methods can be found by running `javap java.lang.invoke.DirectMethodHandle\$Holder` etc. on the built image JDK.
2. The general properties of these methods, such as the methods would have otherwise been in LambdaForm$ classes; may refer to VarHandleGuards as an example of how they would appear.
3. GenerateJLIClassesHelper generate these classes; (in GenerateJLIClassesHelper) they are generated in image JDK via jlink and HelloClasslist; they don't exist in exploded JDK
Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time".
However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes, because for example (to the courtesy of) [~swen] could not figure out anything with them.
I recommend comment enhancements that convey these to source code readers:
1. The exact generated methods can be found by running `javap java.lang.invoke.DirectMethodHandle\$Holder` etc. on the built image JDK.
2. The general properties of these methods, such as the methods would have otherwise been in LambdaForm$ classes; may refer to VarHandleGuards as an example of how they would appear.
3. GenerateJLIClassesHelper generate these classes; (in GenerateJLIClassesHelper) they are generated in image JDK via jlink and HelloClasslist; they don't exist in exploded JDK