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