RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes

[Calvin Cheung]

On Thu, 19 Nov 2020 00:50:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.
>> 
>> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:
>> 
>> - remove the above workaround;
>> 
>> - capture the setting of the property in the archive header during CDS dump time;
>> 
>> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
>> If the values don't match, the archived lambda proxy class won't be used.
>> 
>> Tests:
>> 
>> - [x] ran all cds tests locally on linux-x64
>> 
>> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64
>> 
>> - [x] mach5 tiers 1,2,3 (in progress)
>
> I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources.

Hi Claes,

Thanks for taking a look.

So should I keep the following `!initialize` check in LambdaProxyClassArchive?
109         if (!loadedByBuiltinLoader(caller) || !initialize ||
110             !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0)
111             return null;
If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`.

Let me know if the above is what you have in mind?

thanks,
Calvin

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

PR: https://git.openjdk.java.net/jdk/pull/1301