RFR: 8220607 Draft JEP: Hidden Classes

[Paul Sandoz]

Very nicely written and extremely informative.


Since Nashorn was deprecated in 11 (https://openjdk.java.net/jeps/335 <https://openjdk.java.net/jeps/335>) is it worth updating it?



“
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” ?


“
A hidden class' name is disjoint from ordinary class names is accomplished for it to include a /. It is not a binary name (JVMS 4.2.1), ...
“
->
“
The namespace of a hidden class names is disjoint from the namespace of ordinary class names.  A hidden class name is not a binary name (JVMS 4.2.1), and thus such a name is forbidden when passed as the first argument to ...
“


“
If C's static nest membership is invalid, then the hidden class is added as a member of the nest of C as nest host (C becomes the nest host of its own nest) and the error occurs during nest membership validation is not propagated.
“

s/error occurs/error occurring/



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

What about final fields being implicitly stable fields for classes in java.lang.invoke?

I would presume a hidden class might inherit such policies from its lookup class.

Paul.

> On Dec 4, 2019, at 5:13 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Draft JEP:
>   https://bugs.openjdk.java.net/browse/JDK-8220607
> 
> The past discussion was tracked in JDK-8171335 [1] regarding dynamic nestmates and the replacement of Unsafe::defineAnonymousClass which consists of four separable features:
> 1. non-discoverable and cannot participate in symbolic resolution
> 2. lifecycle is independent of its defining class loader
> 3. private member access of the given host class
> 4. constant pool patching
> 
> The JEP proposes to support a new kind of classes: "hidden classes" that can optionally join as a member of a nest and/or can be weakly referenced by its defining class loader. It covers 1-3 above.   4 is separated from this JEP to give time to explore the class data support that may benefit to prototype with template classes.
> 
> javadoc and specdiff:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/
> 
> The current prototype is in the nestmates branch and all JDK use of Unsafe::defineAnonymousClass are replaced with hidden classes [3].
> 
> thanks
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8171335
> [2] https://bugs.openjdk.java.net/browse/JDK-8230501
> [3] http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/
>