Assertion failure with JITServer in MathLoadTest_autosimd_CS_5m_0: vTableSlot called for unresolved method

[cjjdespres]

While testing #14755 with a debug build, I got the following assert:

Assertion failed at /home/despresc/dev/testing/openj9-openjdk-jdk21/openj9/runtime/compiler/env/j9method.cpp:6494: _vTableSlot
VMState: 0x0005ffff
	vTableSlot called for unresolved method

The exact context in the core file is:

#15 0x00007f2769963f6c in TR::va_fatal_assertion(const char *, int, const char *, const char *, typedef __va_list_tag __va_list_tag *) (
    file=file@entry=0x7f2769d2e000 "/home/despresc/dev/testing/openj9-openjdk-jdk21/openj9/runtime/compiler/env/j9method.cpp", line=line@entry=6494, 
    condition=condition@entry=0x7f2769d29bb1 "_vTableSlot", format=format@entry=0x7f2769d2e060 "vTableSlot called for unresolved method", ap=ap@entry=0x7f2754c8a378)
    at /home/despresc/dev/testing/openj9-openjdk-jdk21/omr/compiler/infra/Assert.cpp:139
#16 0x00007f276996417b in TR::assertion (file=file@entry=0x7f2769d2e000 "/home/despresc/dev/testing/openj9-openjdk-jdk21/openj9/runtime/compiler/env/j9method.cpp", line=line@entry=6494, 
    condition=condition@entry=0x7f2769d29bb1 "_vTableSlot", format=format@entry=0x7f2769d2e060 "vTableSlot called for unresolved method")
    at /home/despresc/dev/testing/openj9-openjdk-jdk21/omr/compiler/infra/Assert.cpp:156
#17 0x00007f2769605150 in TR_ResolvedJ9Method::vTableSlot (this=0x7f273700afb0, cpIndex=<optimized out>) at /home/despresc/dev/testing/openj9-openjdk-jdk21/openj9/runtime/compiler/env/j9method.cpp:6495
#18 0x00007f276953cbcb in handleServerMessage (client=client@entry=0x7f2754cb7550, fe=0x7f2750007f80, response=@0x7f2754c8ac90: JITServer::ResolvedMethod_getMultipleResolvedMethods)
    at /home/despresc/dev/testing/openj9-openjdk-jdk21/openj9/runtime/compiler/control/JITClientCompilationThread.cpp:1790

In short, when we handle the MessageType::ResolvedMethod_getMultipleResolvedMethods message, we get to an entry that's a TR_ResolvedMethodType::ImproperInterface. The client successfully gets its hands on a resolved method for the given cpIndex, but that resolved method has a _vTableSlot of zero.

The actual resolved method is:

(gdb) print *resolvedMethod
$31 = {<TR_J9Method> = {<TR_J9MethodBase> = {<TR::Method> = {<J9::Method> = {<OMR::Method> = {_vptr.Method = 0x7f276a31e3a8 <vtable for TR_ResolvedJ9Method+16>, 
            _recognizedMethod = TR::java_lang_Object_getClass, _mandatoryRecognizedMethod = TR::java_lang_Object_getClass, _typeOfMethod = OMR::Method::J9}, <No data fields>}, <No data fields>}, 
      _paramElements = 0, _paramSlots = 0, _signature = 0x7f271d459534, _name = 0x7f271d45952a, _className = 0x7f271d459518, _argTypes = 0x7f273700b070 "\t>\005", _fullSignature = 0x0, _flags = {
        _flags = 0}}, <No data fields>}, <TR_ResolvedJ9MethodBase> = {<TR_ResolvedMethod> = {_vptr.TR_ResolvedMethod = 0x7f276a31e8b0 <vtable for TR_ResolvedJ9Method+1304>}, _fe = 0x7f2750007f80, 
    _owningMethod = 0x7f273700a378, _romLiterals = 0x7f271d4590b0, _methodHandleLocation = 0x7f271d45b426}, _ramMethod = 0x41b50, _romMethod = 0x7f271d4592a4, _vTableSlot = 0, 
  _j9classForNewInstance = 0x0, _jniProperties = 0, _jniTargetAddress = 0x0, _pendingPushSlots = -1}

The _methodHandleLocation is set, so I'm assuming the resolved method was created with createMethodHandleArchetypeSpecimen or in the handling of the VM_createMethodHandleArchetypeSpecimen message (probably the latter). In any case, the resolved method is created with createResolvedMethodWithSignature with a default argument of 0 for the vTableSlot, which gets passed to the resolved method constructor. That's the only place that _vTableSlot is set (other than at the server when it unpacks the resolved method info received from the client).

Since the non-JITServer code also has the _vTableSlot be zero for these method handle archetype specimens, it seems to me that this is an expected state for these kinds of resolved methods. Unless it's forbidden for a method handle archetype specimen to have TR_ResolvedMethodType::ImproperInterface, the vTableSlot() call or the assert itself should probably be adjusted to take into account these cases where _vTableSlot may properly be set to 0.

[cjjdespres]

Attn @mpirvu.

[cjjdespres]

Based on certain code comments (see #20001) I think it might be true that some non-archetype-specimen resolved methods can legitimately have a vtable slot of zero. In particular, a comment in J9::TransformUtil::refineMethodHandleLinkTo seems to say that the methods of java/lang/Object are one such case, and judging from the core, the resolved method that caused the assert corresponds to java/lang/Object.getClass.