RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive

[David Holmes]

On 22/04/2021 1:51 pm, Yumin Qi wrote:
>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
>>
>> Hi Yumin,
>>
>> On 22/04/2021 8:42 am, Yumin Qi wrote:
>>
>>> Hi, Please review
>>> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes,
>>> "java.lang.invoke.Invokers$Holder",
>>> "java.lang.invoke.DirectMethodHandle$Holder",
>>> "java.lang.invoke.DelegatingMethodHandle$Holder",
>>> "java.lang.invoke.LambdaForm$Holder"
>>> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added.
>>> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive)
>>
>> Meta questions:
>> - why are they not already stored?
>> - why do we need them to be stored?
>> - can we avoid hardwiring a set of classes that then tightly couples
>> our code to the JDK code in a way that we may not easily detect breakages?
>>
>> Thanks,
>> David
> Hi, David
> 1) When dump static archive, we stored the holder classes which were logged (bug https://bugs.openjdk.java.net/browse/JDK-8247536) during build time. The pre-generated lambda form classes were collected in jlink stage, then regenerated the holder classes which hold the LF functions, stored in static archive. That is, whatever LF forms generated during build are archive in static archive.

Okay I think I get how these classes are generated and then stored in 
the static archive.

> 2) At runtime, user code Lambda will generate new classes which are not stored into dynamic archive. The holder classes are the four invoke class$holder classes, so we record the lambda format for dynamic dump, regenerate the holder classes which will host both static contents plus the newly loaded contents then stored in dynamic archive. There are two versions of those four holder classes, one is the static version, and the other (bigger) in dynamic, so if dynamic mapped, we use the dynamic versions which host more LF functions.

Not following this part. How can you regenerate an existing class? I'm 
not familiar with the details of LF classes and how all that machinery 
works.

> 3) We only regenerate the four holder classes and regardless of the others (species), those four holders host majority of the invoke functions. The names are hardcoded since there are no mapping from jdk to vm for this. Do we have a way to do this?

Probably not but that is the problem I'm flagging. Is this list of 
classes going to grow? If they rework code on the Java side are we going 
to know what changes to make on the VM side? Is way we can make this 
less fragile?

Thanks,
David

> 
> Thanks
> Yumin
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3611
>