testJITServer - There are no deserialized methods at the client

[pshipton]

https://openj9-jenkins.osuosl.org/job/Test_openjdk8_j9_sanity.functional_s390x_linux_Nightly_testList_1/701/
testJITServer_2 -Xcompressedrefs -Xjit -Xgcpolicy:gencon -Xshareclasses:name=test_jitscc -XX:+JITServerUseAOTCache

java.lang.AssertionError: There are no deserialized methods at the client.
	at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
	at jit.test.jitserver.JITServerTest.testServerAOTCache(JITServerTest.java:666)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[pshipton]

@mpirvu

[pshipton]

https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.functional_s390x_linux_Nightly_testList_1/147/
testJITServer_2
-Xcompressedrefs -Xjit -Xgcpolicy:gencon -Xshareclasses:name=test_jitscc -XX:+JITServerUseAOTCache

FAILED: testServerAOTCache
java.lang.AssertionError: There are no deserialized methods at the client.
	at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
	at jit.test.jitserver.JITServerTest.testServerAOTCache(JITServerTest.java:666)

[mpirvu]

It's very likely that this problem is caused by #18656 and will be fixed by #18792
#18656 may cause a server using the AOTCache feature to crash while sitting idle without any client connected to it. If the server dies, it's expected that there will be no deserialized method at the client.

[cjjdespres]

In the testServerAOTCache test we first check the client log for deserialized methods and only if that succeeds do we destroy and check the server process. Maybe we could switch the order in which that happens to confirm that it's the server crashing that is the problem?

[mpirvu]

The order may not matter, but we should definitely check that the server hasn't crashed yet.

[pshipton]

testJITServer_2 failed 100% in an OMR acceptance build specific to alinux, zlinux.
https://openj9-jenkins.osuosl.org/job/Pipeline-OMR-Acceptance/639/

This wasn't the case in the Friday night builds.

It seems something in 14ba228...00a123d is causing 100% failure.

[pshipton]

Since the failure was seen in the PR build for #18821 (comment), the failure must be caused by the only other change.

#18827

[mpirvu]

@cjjdespres determined that #18821 causes the deserialization at the client to fail consistently.
#18843 will revert that change.