Review Request: 8238358: Implementation of JEP 371: Hidden Classes
forax at univ-mlv.fr
Fri Mar 27 12:00:06 UTC 2020
in ReflectionFactory, why in the case of a constructor the check to the anonymous class is removed ?
in BytecodeGenerator, the comment "// bootstrapping issue if using condy"
can be promoted on top of clinit, because i ask myself the same question seeing a static block was generated
in AbstractValidatingLambdaMetafactory.java, the field caller is not used after all ?
----- Mail original -----
> De: "mandy chung" <mandy.chung at oracle.com>
> À: "valhalla-dev" <valhalla-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>,
> "serviceability-dev" <serviceability-dev at openjdk.java.net>, "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Envoyé: Vendredi 27 Mars 2020 00:57:39
> Objet: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
> Please review the implementation of JEP 371: Hidden Classes. The main
> changes are in core-libs and hotspot runtime area. Small changes are
> made in javac, VM compiler (intrinsification of Class::isHiddenClass),
> JFR, JDI, and jcmd. CSR has been reviewed and is in the finalized
> state (see specdiff and javadoc below for reference).
> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point
> of view, a hidden class is a normal class except the following:
> - A hidden class has no initiating class loader and is not registered in
> any dictionary.
> - A hidden class has a name containing an illegal character
> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature`
> returns "Lp/Foo.0x1234;".
> - A hidden class is not modifiable, i.e. cannot be redefined or
> retransformed. JVM TI IsModifableClass returns false on a hidden.
> - Final fields in a hidden class is "final". The value of final fields
> cannot be overriden via reflection. setAccessible(true) can still be
> called on reflected objects representing final fields in a hidden class
> and its access check will be suppressed but only have read-access (i.e.
> can do Field::getXXX but not setXXX).
> Brief summary of this patch:
> 1. A new Lookup::defineHiddenClass method is the API to create a hidden
> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG
> option that
> can be specified when creating a hidden class.
> 3. A new Class::isHiddenClass method tests if a class is a hidden class.
> 4. Field::setXXX method will throw IAE on a final field of a hidden class
> regardless of the value of the accessible flag.
> 5. JVM_LookupDefineClass is the new JVM entry point for Lookup::defineClass
> and defineHiddenClass to create a class from the given bytes.
> 6. ClassLoaderData implementation is not changed. There is one primary CLD
> that holds the classes strongly referenced by its defining loader.
> can be zero or more additional CLDs - one per weak class.
> 7. Nest host determination is updated per revised JVMS 5.4.4. Access control
> check no longer throws LinkageError but instead it will throw IAE with
> a clear message if a class fails to resolve/validate the nest host
> in NestHost/NestMembers attribute.
> 8. JFR, jcmd, JDI are updated to support hidden classes.
> 9. update javac LambdaToMethod as lambda proxy starts using nestmates
> and generate a bridge method to desuger a method reference to a
> method in its supertype in a different package
> This patch also updates StringConcatFactory, LambdaMetaFactory, and
> to use hidden classes. The webrev includes changes in nashorn to hidden
> and I will update the webrev if JEP 372 removes it any time soon.
> We uncovered a bug in Lookup::defineClass spec throws LinkageError and
> to have the newly created class linked. However, the implementation in 14
> does not link the class. A separate CSR  proposes to update the
> implementation to match the spec. This patch fixes the implementation.
> The spec update on JVM TI, JDI and Instrumentation will be done as
> a separate RFE . This patch includes new tests for JVM TI and
> java.instrument that validates how the existing APIs work for hidden
> JVMS 5.4.4 change:
>  https://bugs.openjdk.java.net/browse/JDK-8238359
>  https://bugs.openjdk.java.net/browse/JDK-8240338
>  https://bugs.openjdk.java.net/browse/JDK-8230502
More information about the valhalla-dev