RFR: 8220607 Draft JEP: Hidden Classes
Mandy Chung
mandy.chung at oracle.com
Mon Dec 9 23:51:15 UTC 2019
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.
http://hg.openjdk.java.net/valhalla/valhalla/file/eee025d47c8a/src/hotspot/share/ci/ciField.cpp#l215
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8235602
More information about the valhalla-dev
mailing list