RFR: 8338530: CDS warning Skipping java/lang/invoke/BoundMethodHandle$Species_LLLL

[Claes Redestad]

On Sat, 31 Aug 2024 10:40:40 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Is it possible for us at java.lang.invoke to enhance the `GenerateJliClassesHelper` to generate this class? I can look into it.
>
>> Is it possible for us at java.lang.invoke to enhance the `GenerateJliClassesHelper` to generate this class? I can look into it.
> 
> `GenerateJLIClassesPlugin`/`Helper` is fine, all that needs to be updated is the [`HelloClasslist`] script to hit the code path which generates `BoundMethodHandle$Species_LLLL`.
> 
> [`HelloClasslist`]: https://github.com/openjdk/jdk/blob/master/make/jdk/src/classes/build/tools/classlist/HelloClasslist.java

Yes, `Species_*` classes can be statically generated by jlink - using a build-time "training run" of the `HelloClasslist` program @ExE-Boss refers to to generate a list of classes to generate statically into the JDK image. 

What happened in [JDK-8336856](https://bugs.openjdk.org/browse/JDK-8336856) is likely that the `String` concat expressions touched by `HelloClasslist` no longer needs `Species_LLLL`, but something touched when running `java -Xshare:dump` does, so we get a warning. A dynamically generated `Species_LLLL` wouldn't exist in the JDK image, so it makes sense to exclude it from a CDS dump. 

Random thoughts:
1. It would probably work to actually make these dumpable into the CDS archive - though we might need to also dump the full bytecode and patch that up when we load them.
2. Looking at what `-Xshare:dump` does there's some `linkMethodHandleConstant` upcall which ends up creating the `Species_LLLL` class seen here - via `MethodHandleImpl.bindCaller`. Anyone who can point me to what's making such upcalls during dump? The provided `Lookup` might need to have other privileges to avoid generating forms with caller sensitive bindings. @iklam ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20799#issuecomment-2327633728