eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.

Other

3.28k stars 721 forks source link

testJITServer - There are no deserialized methods at the client #18691

Open pshipton opened 9 months ago

pshipton commented 9 months ago

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 commented 9 months ago

@mpirvu

pshipton commented 8 months ago

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 commented 8 months ago

It's very likely that this problem is caused by https://github.com/eclipse-openj9/openj9/pull/18656 and will be fixed by https://github.com/eclipse-openj9/openj9/pull/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 commented 8 months ago

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 commented 8 months ago

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

pshipton commented 8 months ago

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 https://github.com/eclipse-openj9/openj9/compare/14ba228c39...00a123d316a is causing 100% failure.

pshipton commented 8 months ago

Since the failure was seen in the PR build for https://github.com/eclipse-openj9/openj9/pull/18821#issuecomment-1912882791, the failure must be caused by the only other change.

https://github.com/eclipse-openj9/openj9/pull/18827

mpirvu commented 8 months ago

@cjjdespres determined that https://github.com/eclipse-openj9/openj9/pull/18821 causes the deserialization at the client to fail consistently. https://github.com/eclipse-openj9/openj9/pull/18843 will revert that change.