RFR: 8220607 Draft JEP: Hidden Classes

Paul Sandoz paul.sandoz at oracle.com
Fri Dec 6 16:39:14 UTC 2019



> On Dec 5, 2019, at 6:05 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 12/5/19 3:29 PM, Paul Sandoz wrote:
>> Very nicely written and extremely informative.
>> 
> 
> Thanks.  Kudos to Alex B. for his feedback and improved writing.
>> 
>> Since Nashorn was deprecated in 11 (https://openjdk.java.net/jeps/335) is it worth updating it?
>> 
>> 
> 
> It was a good exercise to identify any migration challenge.  It turns out it's straight-forward.
> 
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java.sdiff.html
> 
> Like the dynamic proxy, nashorn generates classes in a dynamic module for strong encapsulation.   Allowing a hidden class to be injected in an empty package is something we should look into in the future.

Ok.


> 
>> 
>>>> At run time, any attempt to resolve a hidden class by name, it may result in a LinkageError which is no difference from resolving a symbolic reference to an ordinary class that cannot be found.
>>>> ->
>>>> At run time, any attempt to resolve a hidden class by name may result in a LinkageError, which is no differer from resolving a symbolic reference to an ordinary class that cannot be found.
>> "
>> 
>> “May” or “will” ?
>> 
> 
> Should be "will".  I have to remind myself why I wrote "may" at that time (it has been quite some time ago).
> 
> :
> 
>> 
>>>> Accordingly, hidden classes will not have the ability to control their optimization, even when defined by JDK code. (This is not thought to present any risk to the migration of JDK code from defining VM-anonymous classes to defining hidden classes.)
>>>> 
>> (You probably know this…) FWIW it's not the case for classes defined for lambda forms which do make use of @DontInline and @ForceInline.  Although such classes are generated with patching, so when public support for patching is added this assumption may need to be revised if we want to replace the Unsafe usages.
> 
> Lambda forms are trusted classes defined by the bootstrap class loader and so they get access to these VM internal annotations.
> 
> It's replaced with a package-private Lookup::defineHiddenClassWithClassData for now.
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java.udiff.html
> 

Ok.


>> 
>> 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.  

Paul.


More information about the valhalla-dev mailing list