Review Request: 8238358: Implementation of JEP 371: Hidden Classes

[Mandy Chung]

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

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