On Thu, 19 Nov 2020 00:50:52 GMT, Claes Redestad <redes...@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
