RFR: 8220607 Draft JEP: Hidden Classes

[Remi Forax]

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> À: "mandy chung" <mandy.chung at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Vendredi 6 Décembre 2019 17:39:14
> Objet: Re: RFR: 8220607 Draft JEP: Hidden Classes

Hi Paul,
...

>>> 
>>> What about final fields being implicitly stable fields for classes in
>>> java.lang.invoke?
>>> 
>> 
>> AFAICS, hidden class doesn't affect this at all as it's determined by
>> java.lang.invoke package, right?
>> 
>>> I would presume a hidden class might inherit such policies from its lookup
>>> class.
>>> 
>> 
>> I will double check.
>> 
> 
> 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. 

> 
> Paul.

Rémi