RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive
Yumin Qi
minqi at openjdk.java.net
Thu Apr 22 03:51:21 UTC 2021
On Wed, 21 Apr 2021 22:34:48 GMT, Yumin Qi <minqi at openjdk.org> 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)
>
> Tests: tier1,tier2,tier3,tier4
>
> Thanks
> Yumin
> _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.
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.
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?
Thanks
Yumin
-------------
PR: https://git.openjdk.java.net/jdk/pull/3611
More information about the hotspot-dev
mailing list