RFR: 8295102: Always load @lambda-form-invoker lines from default classlist

[David Holmes]

On Mon, 10 Oct 2022 22:18:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
> 
> - `java.lang.invoke.Invokers$Holder`
> - `java.lang.invoke.DirectMethodHandle$Holder`
> - `java.lang.invoke.DelegatingMethodHandle$Holder`
> - `java.lang.invoke.LambdaForm$Holder`
> 
> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
> 
> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
> 
> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.

Seems to me this is edging towards a scheme where the user-defined classlist is to be used to augment the default one, rather than being a complete replacement. Either the classlist should be the one-true-source for the classes to include in the archive, or else you need a way to express that you want to use it in union with the default list (to some extent), but not just (seemingly arbitrarily) decide that a special subset of classes should always be included even if missing from the classlist.

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

PR: https://git.openjdk.org/jdk/pull/10639