Track method dependencies during AOT store compilations

[cjjdespres]

The dependencies of AOT-compiled method bodies (class chain offsets of classes and whether or not they are initialized) are recorded during an AOT compilation and stored in the local SCC.

Related: #20529

[cjjdespres]

Attn @mpirvu. This is the last of the main work, gathering dependencies during AOT stores.

[mpirvu]

Overall it looks good, but I defer to @dsouzai for relocation record changes.

[mpirvu]

jenkins compile all jdk8,jdk23

[mpirvu]

Build error:

/Users/jenkins/workspace/Build_JDK23_aarch64_mac_Personal/openj9/runtime/compiler/runtime/RelocationRecord.cpp:2700:14: error: member access into incomplete type 'TR::AheadOfTimeCompile'
22:19:42     aotCompile->comp()->addAOTMethodDependency(ramClass);

[mpirvu]

Same compile error on aix:

/home/jenkins/workspace/Build_JDK8_ppc64_aix_Personal/openj9/runtime/compiler/runtime/RelocationRecord.cpp:2700:14: error: member access into incomplete type 'TR::AheadOfTimeCompile'
00:36:07     aotCompile->comp()->addAOTMethodDependency(ramClass);

[mpirvu]

jenkins compile aix jdk8

[dsouzai]

I have a quetion. why couldn't the dependencies be added early on in

• TR::SymbolValidationManager::addClassRecord
• TR::SymbolValidationManager::addClassRecordWithChain
• TR::SymbolValidationManager::addMethodRecord
• TR_ResolvedRelocatableJ9Method::storeValidationRecordIfNecessary
  ?

[cjjdespres]

They probably could be. I don't know of any other places where the relevant records would be generated. I recorded the dependencies where I did because those are all the places where the SCC offset records are created for the JITServer AOT cache, so every offset that's immediately relevant to relocation (and only those offsets) will definitely go through one of those places. I think the only exception is the offsets in the well-known classes chain - I added those dependencies as they were being generated by the SVM instead of next to the addWellKnownClassesSerializationRecord() call so I could exclude the irrelevant well-known classes.

[cjjdespres]

Build failed on ppc64_aix because #include "codegen/AheadOfTimeCompile.hpp" was guarded by defined(J9VM_OPT_JITSERVER):

10:19:24  /home/jenkins/workspace/Build_JDK8_ppc64_aix_Personal/openj9/runtime/compiler/runtime/RelocationRecord.cpp:2700:14: error: member access into incomplete type 'TR::AheadOfTimeCompile'
10:19:24     aotCompile->comp()->addAOTMethodDependency(ramClass);

[mpirvu]

jenkins compile aix jdk8

[dsouzai]

They probably could be. I don't know of any other places where the relevant records would be generated. I recorded the dependencies where I did because those are all the places where the SCC offset records are created for the JITServer AOT cache, so every offset that's immediately relevant to relocation (and only those offsets) will definitely go through one of those places. I think the only exception is the offsets in the well-known classes chain - I added those dependencies as they were being generated by the SVM instead of next to the addWellKnownClassesSerializationRecord() call so I could exclude the irrelevant well-known classes.

Hm for SVM I think it's just those places, but for non-SVM, the inlined method validations happen in the relocation records, which is unfortunate; means you would need to go to the place where we create those relocations, which already in the codegen, so it's not particularly cleaner...

[cjjdespres]

I might be able to tie it to the creation of TR::AOTClassInfo. Most non-SVM records use that to pass class info to the external relocation records in initializeCommonAOTRelocationHeader, and the few that don't could probably be modified to use it. I could do the same thing with SVM and ClassValidationRecordWithChain, ProfiledClassRecord, etc.

[mpirvu]

jenkins test sanity all jdk23

[mpirvu]

Two failures on zlinux:
cmdLineTester_criu_jitPostRestore_3 has a timeout

17:20:37  Running command: bash /home/jenkins/workspace/Test_openjdk23_j9_sanity.functional_s390x_linux_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu/criuScript.sh /home/jenkins/workspace/Test_openjdk23_j9_sanity.functional_s390x_linux_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu /home/jenkins/workspace/Test_openjdk23_j9_sanity.functional_s390x_linux_Personal_testList_0/jdkbinary/j2sdk-image/bin/java " -XX:+DebugOnRestore -Xjit " org.openj9.criu.OptionsFileTest "JitOptionsTest -Xnojit -Xnoaot" 1 false false
17:20:37  Time spent starting: 4 milliseconds
17:25:40  ***[TEST INFO 2024/11/21 17:25:36] ProcessKiller detected a timeout after 300000 milliseconds!***
17:25:40  ***[TEST INFO 2024/11/21 17:25:36] executing /usr/bin/gdb -batch -x /tmp/debugger14441959268811347470.txt bash 313686***

cmdLineTester_GCRegressionTests_1
This one fails because some coredumps were detected, even though all tests indicate that they are successful.

Since the feature in this PR is disabled, it's very unlikely that it is the source of these problems.