<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-CA" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<div id="mail-editor-reference-message-container">
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Problem #3 is an interesting case (and many thanks for the simple reproduction test!) in that it shows an example of a class initialization order cycle – thankfully one that can be worked around. It requires careful separation to break
the cycle while still preserving the identity invariants expressed in the original code. As an example, look at
<a href="https://github.com/openjdk/leyden/compare/premain...DanHeidinga:leyden:rework-constantdesc-init?expand=1">
https://github.com/openjdk/leyden/compare/premain...DanHeidinga:leyden:rework-constantdesc-init?expand=1</a> for how to detangle the ConstantDesc / PrimitiveClassDescImpl / ReerenceClassDescImpl design.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don’t know that we actually want to propose this to mainline but it shows the pattern that can be used to rework the <clinit>’s of similar cycles.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">--Dan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><snip><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Problem #3:<br>
<br>
With these two changes in place, Infinispan server test-case works fine,<br>
but the changes cause another test case [2] to fail.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">The failure happens in the assembly phase due to NPE thrown during<br>
initialization of class PrimitiveClassDescImpl. Its initialization is<br>
triggered "forcefully" in MetaspaceShared::link_shared_classes().<br>
Stacktrace for the NPE is:<br>
<br>
[0] jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @ bci 1<br>
[1] jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @ bci 27<br>
[2] java/lang/constant/ConstantDescs::ofConstantBootstrap(Ljava/lang/constant/ClassDesc;Ljava/lang/String;Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/DirectMethodHandleDesc; @ bci 47<br>
[3] java/lang/constant/ConstantDescs::<clinit> @ bci 664<br>
[4] jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @ bci 1<br>
[5] jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @ bci 6<br>
<br>
Invocation of PrimitiveClassDescImpl::<clinit> results in initialization<br>
of ConstantDescs class (see frame 3 in above stacktrace).<br>
ConstantDescs::<clinit> @ 664 corresponds to following java code:<br>
<br>
public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT<br>
= ofConstantBootstrap(CD_MethodHandles, "classDataAt",<br>
CD_Object, CD_int);<br>
<br>
The last parameter CD_int is defined as:<br>
<br>
public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;<br>
<br>
So, its value is obtained from PrimitiveClassDescImpl.CD_int which<br>
hasn't been initialized properly yet. As a result ConstantDescs::CD_int<br>
gets default value null, which causes MethodTypeDescImpl::validateArgument<br>
to throw NPE later. If the initialization of ConstantDescs is triggered<br>
before PrimitiveClassDescImpl then we won't run into NPE.<br>
So, there is a class initialization circularity involving<br>
PrimitiveClassDescImpl and ConstantDescs, and the result depends on which<br>
class gets initialized first.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">This behavior can be recreated by explicitly loading these classes:<br>
<br>
public class ClassOrderTest {<br>
public static void main(String args[]) throws Exception {<br>
Class.forName("java.lang.constant.ConstantDescs");<br>
Class.forName("jdk.internal.constant.PrimitiveClassDescImpl");<br>
}<br>
}<br>
<br>
Above program works fine but if the order of classes is reversed as:<br>
<br>
public class ClassOrderTest {<br>
public static void main(String args[]) throws Exception {<br>
Class.forName("jdk.internal.constant.PrimitiveClassDescImpl");<br>
Class.forName("java.lang.constant.ConstantDescs");<br>
}<br>
}<br>
<br>
then it throws NPE which is the same as mentioned above:<br>
<br>
Exception in thread "main" java.lang.ExceptionInInitializerError<br>
at java.base/jdk.internal.constant.PrimitiveClassDescImpl.<init>(PrimitiveClassDescImpl.java:85)<br>
at java.base/jdk.internal.constant.PrimitiveClassDescImpl.<clinit>(PrimitiveClassDescImpl.java:45)<br>
at java.base/java.lang.Class.forName0(Native Method)<br>
at java.base/java.lang.Class.forName(Class.java:475)<br>
at java.base/java.lang.Class.forName(Class.java:455)<br>
at ClassOrderTest.main(ClassOrderTest.java:4)<br>
Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.constant.ClassDesc.descriptorString()" because "arg" is null<br>
at java.base/jdk.internal.constant.MethodTypeDescImpl.validateArgument(MethodTypeDescImpl.java:89)<br>
at java.base/jdk.internal.constant.MethodTypeDescImpl.ofTrusted(MethodTypeDescImpl.java:83)<br>
at java.base/java.lang.constant.ConstantDescs.ofConstantBootstrap(ConstantDescs.java:381)<br>
at java.base/java.lang.constant.ConstantDescs.<clinit>(ConstantDescs.java:282)<br>
... 6 more<br>
<br>
The workaround for this issue is to remove the "forceful" initialization of classes in the assembly phase.<o:p></o:p></p>
</div>
</div>
</blockquote>
<p style="margin-left:36.0pt"><o:p> </o:p></p>
<p style="margin-left:36.0pt">I believe the issue is that some JDK classes have circular <clinit> dependencies, and must be initialized in a certain order. When we execute "normal" Java programs, we somehow come into an initialization order that "works".<o:p></o:p></p>
<p style="margin-left:36.0pt">However, the "forceful" initialization CDS code (which has been removed in [2]) initializes these classes in an order that hasn't been tested, and runs into the above NullPointerException. It's not clear if such an order can be
achieved by "normal" Java programs, so we potentially have a bug in the core library with ConstantDescs and related classes. If I have time, I will try to write a Java program that replays the same <clinit> order as with the above NullPointerException.
<o:p></o:p></p>
<p style="margin-left:36.0pt">In any case, CDS now avoids explicitly initializing classes. So hopefully it will not deviate from the well tested execution paths and avoid any surpises.<o:p></o:p></p>
<p style="margin-left:36.0pt">Thanks<o:p></o:p></p>
<p style="margin-left:36.0pt">- Ioi<o:p></o:p></p>
<p style="margin-left:36.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><br>
[0] <a href="https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000987.html">
https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000987.html</a><br>
[1] <a href="https://github.com/openjdk/leyden/commit/7a6fadcae03d86c91713ffae452817bce7a4674d">
https://github.com/openjdk/leyden/commit/7a6fadcae03d86c91713ffae452817bce7a4674d</a><br>
[2] <a href="https://github.com/ashu-mehra/leyden-testcase">https://github.com/ashu-mehra/leyden-testcase</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Thanks,<br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">- Ashutosh Mehra<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>