-
Notifications
You must be signed in to change notification settings - Fork 733
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
j9mm.479 ASSERTION FAILED openj9/runtime/gc_glue_java/ScavengerRootScanner.hpp:109: ((MM_StackSlotValidator(MM_StackSlotValidator::NOT_ON_HEAP, *slotPtr, stackLocation, walkState).validate(_env))) #18098
Comments
@JasonFengJ9 @pshipton This failure looks like similar to #13504 too. This one might be a duplicate. |
There were 5 failures in the grinder.
The grinder did have a same failure as |
@hzongaro FYI |
https://openj9-jenkins.osuosl.org/job/Test_openjdk17_j9_extended.system_s390x_linux_Nightly_testList_1/562
|
JDK8 x86-32_windows 0.41 milestone 2(
50x grinder - passed |
JDK8 x86-64_mac milestone 2(
50x grinder - passed |
JDK8 s390x_linux(
50x internal grinder - passed |
JDK21 x86-64_windows(
50x grinder x86-64_windows SharedClasses.SCM01.MultiThread_1 - 11/50 failed |
grinder with -Xint - passed @dmitripivkine @hzongaro pls take a look |
The grinder with -Xint passed. |
Reproduced with internal grinder run 37044, using
From that run:
From the JIT trace log
The stack atlas for those two sections of code shows a collected reference in
|
Looking at Instruction Selection, we see this for code in block_39. Notice
A little later in instruction selection, GPR_0160 becomes a collected reference during evaluation of the following
|
Ran a grinder on jdk17 head stream and the failure occurs there as well, it's not specific to jdk21. |
@hzongaro any update Henry? |
Although the problem could not be reproduced with JDK 17 0.41, I don't believe this is a regression. I believe this problem has existed for a very long time in the JIT compiler, and could occur with compressed references enabled with a shift amount of zero. I suspect that a recent change to I am still working on a fix. |
Following up on Vijay's comment, I came across past discussion of the semantics of I'll quote in passing a relevant comment from @jdmpapin from that OMR issue:
The same is true here. In the interim I will try to work around the problem by preventing commoning of the |
I have opened OMR pull request eclipse-omr/omr#7217, which should work around the problem that is causing |
@hzongaro pls create PRs for 0.42 and 043. |
No concerns in the jdk21 nightly build https://openj9-jenkins.osuosl.org/job/Pipeline-Build-Test-JDK21/197/ Internal grinder on SharedClasses.SCM01.MultiThread_1 failed 2/50. OpenJ9 grinder https://openj9-jenkins.osuosl.org/view/Test/job/Grinder/3161 passed 50/50. @hzongaro I'll leave it up to you if there is something else that can be resolved in 0.43 or if this should be moved forward. |
The failure symptom appears to be different, so I suspect something else is going on there. I'll move investigation of that and the failures reported earlier in HCRLateAttachWorkload, TestJlmRemoteClassAuth and LangLoadTest_5m to 0.44. |
I somehow confused myself - the failures in the internal grinder still look like the same problem:
I'll move this back to 0.43 and investigate further now. |
The grinder failures reported after applying pull request eclipse-omr/omr#7217 involve a variant that wasn't caught by the earlier workaround. From a subsequent grinder run with tracing enabled for
The earlier pull request worked around the problem if the Following discussion with @vijaysun-omr and @0xdaryl, I attempted test runs (sanity.functional, extended.functional, sanity.system, extended.system and sanity.openjdk) to see how frequently this transformation is applied. Those runs didn't encounter any instances in which the transformation was performed - though we do know that it happens intermittently for Given that the transformation appears to be applied very infrequently, we agreed that the best thing to do for now would be to simply disable this transformation in the main branch and in the 0.43 release to prevent this problematic IL arising. The earlier OMR pull requests already greatly reduce the likelihood of this problem arising, so the initial release build JDK 21 (release 0.42) should be safe without preventing the transformation. I will follow up with those pull requests. |
Opened pull request #18743 to disable transformation in Tree Simplification in the main branch. |
Opened pull request #18747 to disable transformation in Tree Simplification in the 0.43.0-release branch. |
Moved further investigation out to Release 0.44 |
I would like to delay making the changes to distinguish between collected and non-collected addresses in integer to address conversion operations so that they can go through a longer test cycle. Moving this out to the 0.45 release. |
I haven’t been able to spend time on this recently. The original failure has been suppressed, but the change to distinguish between collected and non-collected addresses in integer to address conversion operations is still pending. Moving this out again. |
http://vmfarm.rtp.raleigh.ibm.com/job_output.php?id=100208794
|
Failure link
JDK8 s390x_linux 0.41 milestone 1(
rhel7s390x-svl-rt10-1
)Rerun in Grinder - Change TARGET to run only the failed test targets.
Optional info
Failure output (captured from console output)
50x internal grinder - 5/50 failed
The text was updated successfully, but these errors were encountered: