Infinispan server issue - putting it all together

[Dan Heidinga]

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 https://github.com/openjdk/leyden/compare/premain...DanHeidinga:leyden:rework-constantdesc-init?expand=1 for how to detangle the ConstantDesc / PrimitiveClassDescImpl / ReerenceClassDescImpl design.

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.

--Dan

<snip>

Problem #3:

With these two changes in place, Infinispan server test-case works fine,
but the changes cause another test case [2] to fail.
The failure happens in the assembly phase due to NPE thrown during
initialization of class PrimitiveClassDescImpl. Its initialization is
triggered "forcefully" in MetaspaceShared::link_shared_classes().
Stacktrace for the NPE is:

[0] jdk/internal/constant/MethodTypeDescImpl::validateArgument(Ljava/lang/constant/ClassDesc;)Ljava/lang/constant/ClassDesc; @ bci 1
[1] jdk/internal/constant/MethodTypeDescImpl::ofTrusted(Ljava/lang/constant/ClassDesc;[Ljava/lang/constant/ClassDesc;)Ljdk/internal/constant/MethodTypeDescImpl; @ bci 27
[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
[3] java/lang/constant/ConstantDescs::<clinit> @ bci 664
[4] jdk/internal/constant/PrimitiveClassDescImpl::<init>(Ljava/lang/String;)V @ bci 1
[5] jdk/internal/constant/PrimitiveClassDescImpl::<clinit>(Ljava/lang/String;)V @ bci 6

Invocation of PrimitiveClassDescImpl::<clinit> results in initialization
of ConstantDescs class (see frame 3 in above stacktrace).
ConstantDescs::<clinit> @ 664 corresponds to following java code:

    public static final DirectMethodHandleDesc BSM_CLASS_DATA_AT
            = ofConstantBootstrap(CD_MethodHandles, "classDataAt",
            CD_Object, CD_int);

The last parameter CD_int is defined as:

    public static final ClassDesc CD_int = PrimitiveClassDescImpl.CD_int;

So, its value is obtained from PrimitiveClassDescImpl.CD_int which
hasn't been initialized properly yet. As a result ConstantDescs::CD_int
gets default value null, which causes MethodTypeDescImpl::validateArgument
to throw NPE later. If the initialization of ConstantDescs is triggered
before PrimitiveClassDescImpl then we won't run into NPE.
So, there is a class initialization circularity involving
PrimitiveClassDescImpl and ConstantDescs, and the result depends on which
class gets initialized first.

This behavior can be recreated by explicitly loading these classes:

public class ClassOrderTest {
  public static void main(String args[]) throws Exception {
    Class.forName("java.lang.constant.ConstantDescs");
    Class.forName("jdk.internal.constant.PrimitiveClassDescImpl");
  }
}

Above program works fine but if the order of classes is reversed as:

public class ClassOrderTest {
  public static void main(String args[]) throws Exception {
    Class.forName("jdk.internal.constant.PrimitiveClassDescImpl");
    Class.forName("java.lang.constant.ConstantDescs");
  }
}

then it throws NPE which is the same as mentioned above:

Exception in thread "main" java.lang.ExceptionInInitializerError
at java.base/jdk.internal.constant.PrimitiveClassDescImpl.<init>(PrimitiveClassDescImpl.java:85)
at java.base/jdk.internal.constant.PrimitiveClassDescImpl.<clinit>(PrimitiveClassDescImpl.java:45)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:475)
at java.base/java.lang.Class.forName(Class.java:455)
at ClassOrderTest.main(ClassOrderTest.java:4)
Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.constant.ClassDesc.descriptorString()" because "arg" is null
at java.base/jdk.internal.constant.MethodTypeDescImpl.validateArgument(MethodTypeDescImpl.java:89)
at java.base/jdk.internal.constant.MethodTypeDescImpl.ofTrusted(MethodTypeDescImpl.java:83)
at java.base/java.lang.constant.ConstantDescs.ofConstantBootstrap(ConstantDescs.java:381)
at java.base/java.lang.constant.ConstantDescs.<clinit>(ConstantDescs.java:282)
... 6 more

The workaround for this issue is to remove the "forceful" initialization of classes in the assembly phase.



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".

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.

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.

Thanks

- Ioi



[0] https://mail.openjdk.org/pipermail/leyden-dev/2024-September/000987.html
[1] https://github.com/openjdk/leyden/commit/7a6fadcae03d86c91713ffae452817bce7a4674d
[2] https://github.com/ashu-mehra/leyden-testcase

Thanks,
- Ashutosh Mehra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20241004/abbf25da/attachment.htm>