RFR: 8220607 Draft JEP: Hidden Classes
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Dec 10 01:28:33 UTC 2019
----- Mail original -----
> De: "mandy chung" <mandy.chung at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mardi 10 Décembre 2019 00:51:15
> Objet: Re: RFR: 8220607 Draft JEP: Hidden Classes
> On 12/9/19 3:19 PM, Remi Forax wrote:
>>> My memory is hazy on this: I thought the same trigger (package of the lookup
>>> class) for whether those compiler-based annotations were allowed was the same
>>> trigger for whether final fields were trusted. So I had some slight concern
>>> that replacements with the public methods in the JDK for code within j.l.lnvoke
>>> (bootstrap methods etc) might affect final field behavior.
>> For anonymous classes created using unsafe.defineAnonymousClass, final fields of
>> all of them are considered as trusted, independent of if the host class is in
>> java.lang or not.
>> This is a very important property for adapter codes (generated dynamically) in a
>> dynamic language because it means that if the adapter is constant (bound in a
>> method handle tree in my case) then all the field access will be replaced by
>> constants so the whole code will be constant folded. I rely on this property
>> heavily.
>>
>> If hidden classes have not that property, it means that hidden classes are
>> useless for me and that people will see perf regressions if they are using
>> lambdas stored in static final fields if lambdas starts to use hidden classes
>> instead of anonymous classes.
>>
>
> FYI. In the current prototype, it does trusted the final fields of
> hidden class but we have to re-examine it from the specification
> perspective and also serialization.
yes, and so currently, i can replace all my use case of unafe.defineAnonymousClass that doesn't use the constant pool patching.
>
> http://hg.openjdk.java.net/valhalla/valhalla/file/eee025d47c8a/src/hotspot/share/ci/ciField.cpp#l215
I vote for not allowing setAccessible/JNI to work on final fields of hidden classes. I don't want to have to think about a framework/library that will change my adapter fields at runtime.
>
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8235602
Rémi
More information about the valhalla-dev
mailing list