Hi Mandy,
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.)
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
