<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Thanks, Chris!<br>
What do you think about this suggestion from Mandy:<br>
<br>
<tt>Â Is ClassUnloadEvent only sent for non-array reference type?Â
If so, is it worth adding an assert<br>
 like <br>
    assert classSignature.startsWith('L') &&
classSignature.endsWith(';');<br>
</tt><br>
Both JDI and JDWP ClassUnload event spec say nothing about array
reference types.<br>
The signature to name conversions in JDI and JDWP also do not
expect array signatures.<br>
So, it is probably worth to add this assert.<br>
I can submit a testing job to make ensure the correctness.<br>
<br>
Thanks,<br>
Serguei<br>
<br>
<br>
On 4/6/20 10:50, Chris Plummer wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b85c551a-f76c-f520-129a-984409678098@oracle.com">
<div class="moz-cite-prefix">Hi Serguei,<br>
<br>
This fix looks good.<br>
<br>
thanks,<br>
<br>
Chris<br>
<br>
On 4/6/20 10:05 AM, <a class="moz-txt-link-abbreviated"
href="mailto:serguei.spitsyn@oracle.com"
moz-do-not-send="true">serguei.spitsyn@oracle.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d84c046a-6425-8d58-aea7-9d5c5d28a493@oracle.com">
<div class="moz-cite-prefix">Sorry for sending mach5 links to
the open mailing lists, I've removed them below.<br>
<br>
Thanks,<br>
serguei<br>
<br>
On 4/6/20 09:56, <a class="moz-txt-link-abbreviated"
href="mailto:serguei.spitsyn@oracle.com"
moz-do-not-send="true">serguei.spitsyn@oracle.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bd511487-c84f-2973-98ff-03b1bedbd92d@oracle.com">
<div class="moz-cite-prefix">Hi Mandy,<br>
<br>
Two JDI tests started failing with the <code></code> update
of
src/jdk.jdi/share/classes/com/sun/tools/jdi/EventSetImpl.java:<br>
Â
vmTestbase/nsk/jdi/ClassUnloadRequest/addClassFilter/filter001/TestDescription.java  Â
<br>
Â
vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java  Â
<br>
 <br>
<br>
I've filed the bug:<br>
 <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8242166"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8242166</a><br>
   [nestmates] regression in JDI ClassUnload events<br>
<br>
The suggested fix is:<br>
  <a
href="http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/"
moz-do-not-send="true">http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/</a><br>
<br>
Thanks,<br>
Serguei<br>
<br>
<br>
<br>
On 3/26/20 16:57, Mandy Chung wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0d824617-3eaf-727c-6eb8-be2414111510@oracle.com">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). <br>
<br>
Webrev: <br>
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03"
moz-do-not-send="true">http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03</a>
<br>
<br>
Hidden class is created via `Lookup::defineHiddenClass`.
From JVM's point <br>
of view, a hidden class is a normal class except the
following: <br>
<br>
- A hidden class has no initiating class loader and is not
registered in any dictionary. <br>
- A hidden class has a name containing an illegal character
`Class::getName` returns `p.Foo/0x1234` whereas
`GetClassSignature` returns "Lp/Foo.0x1234;". <br>
- A hidden class is not modifiable, i.e. cannot be redefined
or retransformed. JVM TI IsModifableClass returns false on a
hidden. <br>
- 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). <br>
<br>
Brief summary of this patch: <br>
<br>
1. A new Lookup::defineHiddenClass method is the API to
create a hidden class. <br>
2. A new Lookup.ClassOption enum class defines NESTMATE and
STRONG option that <br>
  can be specified when creating a hidden class. <br>
3. A new Class::isHiddenClass method tests if a class is a
hidden class. <br>
4. Field::setXXX method will throw IAE on a final field of a
hidden class <br>
  regardless of the value of the accessible flag. <br>
5. JVM_LookupDefineClass is the new JVM entry point for
Lookup::defineClass <br>
  and defineHiddenClass to create a class from the given
bytes. <br>
6. ClassLoaderData implementation is not changed. There is
one primary CLD <br>
  that holds the classes strongly referenced by its
defining loader. There <br>
  can be zero or more additional CLDs - one per weak class.
<br>
7. Nest host determination is updated per revised JVMS
5.4.4. Access control <br>
  check no longer throws LinkageError but instead it will
throw IAE with <br>
  a clear message if a class fails to resolve/validate the
nest host declared <br>
  in NestHost/NestMembers attribute. <br>
8. JFR, jcmd, JDI are updated to support hidden classes. <br>
9. update javac LambdaToMethod as lambda proxy starts using
nestmates <br>
  and generate a bridge method to desuger a method
reference to a protected <br>
  method in its supertype in a different package <br>
<br>
This patch also updates StringConcatFactory,
LambdaMetaFactory, and LambdaForms <br>
to use hidden classes. The webrev includes changes in
nashorn to hidden class <br>
and I will update the webrev if JEP 372 removes it any time
soon. <br>
<br>
We uncovered a bug in Lookup::defineClass spec throws
LinkageError and intends <br>
to have the newly created class linked. However, the
implementation in 14 <br>
does not link the class. A separate CSR [2] proposes to
update the <br>
implementation to match the spec. This patch fixes the
implementation. <br>
<br>
The spec update on JVM TI, JDI and Instrumentation will be
done as <br>
a separate RFE [3]. This patch includes new tests for JVM
TI and <br>
java.instrument that validates how the existing APIs work
for hidden classes. <br>
<br>
javadoc/specdiff <br>
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/"
moz-do-not-send="true">http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/</a>
<br>
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/"
moz-do-not-send="true">http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/</a>
<br>
<br>
JVMS 5.4.4 change: <br>
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf"
moz-do-not-send="true">http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf</a>
<br>
<br>
CSR: <br>
<a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8238359"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8238359</a>
<br>
<br>
Thanks <br>
Mandy <br>
[1] <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8238359"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8238359</a>
<br>
[2] <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8240338"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8240338</a>
<br>
[3] <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8230502"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8230502</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>