----- Mail original ----- > De: "David Holmes" <david.hol...@oracle.com> > À: "mandy chung" <mandy.ch...@oracle.com>, "Vicente Romero" > <vicente.rom...@oracle.com>, "jan lahoda" > <jan.lah...@oracle.com> > Cc: "serviceability-dev" <serviceability-dev@openjdk.java.net>, "hotspot-dev" > <hotspot-...@openjdk.java.net>, > "core-libs-dev" <core-libs-...@openjdk.java.net>, "valhalla-dev" > <valhalla-...@openjdk.java.net> > Envoyé: Samedi 28 Mars 2020 00:01:58 > Objet: Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
> Hi Mandy, Hi David, > > On 28/03/2020 8:29 am, Mandy Chung wrote: >> Hi Vicente, >> >> hasNestmateAccess is about VM supports static nestmates on JDK release >> >= 11. >> >> However this is about javac --release 14 and the compiled classes may >> run on JDK 14 that lambda and string concat spin classes that are not >> nestmates. I have a patch with Jan's help: >> >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html > > + /** > + * The VM does not support access across nested classes > (8010319). > + * Were that ever to change, this should be removed. > + */ > + boolean isPrivateInOtherClass() { > > I'm not at all sure what this means - access across different nests? > (I'm not even sure what that means.) Access inside the same nest. As you know, until now, a lambda proxy is a VM anonymous class that can only see the private fields of the class declaring the lambda (the host class) and not the private fields of a class of the nest (the enclosing classes in term of Java the language). Rémi > > Thanks, > David > ----- > >> >> (you can apply the above patch on valhalla repo "nestmates" branch) >> >> About testing, I wanted to run BridgeMethodsForLambdaTest and >> TestLambdaBytecode test with --release 14 but it turns out not >> straight-forward. Any help would be appreciated. >> >> thanks >> Mandy >> >> On 3/27/20 2:15 PM, Vicente Romero wrote: >>> Hi Mandy, >>> >>> The patch for nestmates [1] could be used as a reference. There a new >>> method was added to class `com.sun.tools.javac.jvm.Target`, named: >>> `hasNestmateAccess` which checks if a target is ready for nestmates or >>> not. I think that you can follow a similar approach here. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 >>> >>> On 3/27/20 12:29 PM, Mandy Chung wrote: >>>> Hi Jan, >>>> >>>> Good point. The javac change only applies to JDK 15 and later and >>>> the lambda proxy class is not a nestmate when running on JDK 14 or >>>> earlier. >>>> >>>> I probably need the help from langtools team to fix this. I'll give >>>> it a try. >>>> >>>> Mandy >>>> >>>> On 3/27/20 4:31 AM, Jan Lahoda wrote: >>>>> Hi Mandy, >>>>> >>>>> Regarding the javac changes - should those be switched on/off >>>>> depending the Target? Or, if one compiles with e.g. --release 14, >>>>> will the newly generated output still work on JDK 14? >>>>> >>>>> Jan >>>>> >>>>> On 27. 03. 20 0:57, Mandy Chung wrote: >>>>>> 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 [1]has been >>>>>> reviewed and is in the finalized state (see specdiff and javadoc >>>>>> below for reference). >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>>>>> >>>>>> >>>>>> 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 class. >>>>>> 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. There >>>>>> 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 declared >>>>>> 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 >>>>>> protected >>>>>> method in its supertype in a different package >>>>>> >>>>>> This patch also updates StringConcatFactory, LambdaMetaFactory, and >>>>>> LambdaForms >>>>>> to use hidden classes. The webrev includes changes in nashorn to >>>>>> hidden class >>>>>> 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 intends >>>>>> to have the newly created class linked. However, the >>>>>> implementation in 14 >>>>>> does not link the class. A separate CSR [2] 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 [3]. This patch includes new tests for JVM TI and >>>>>> java.instrument that validates how the existing APIs work for >>>>>> hidden classes. >>>>>> >>>>>> javadoc/specdiff >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>>>>> >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>>>>> >>>>>> >>>>>> JVMS 5.4.4 change: >>>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>>>>> >>>>>> >>>>>> CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>>> >>>>>> Thanks >>>>>> Mandy >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >>>> >>>
