-
Notifications
You must be signed in to change notification settings - Fork 710
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
OpenJDK java/util/WeakHashMap/GCDuringIteration.java failed to do a "full" gc #10256
Comments
@dmitripivkine fyi |
30x grinder using latest Adopt build https://ci.eclipse.org/openj9/job/Grinder/992 |
@0xdaryl @andrewcraik |
I don't know anything about the test so I am not sure |
I wrote up a description of the problem on AArch64 here -> #8897 (comment) I don't recall the exact name of the method, but the problem occurred when that method was compiled with optLevel cold which does not run an aggressive liveness optimization (the reason why this is a problem is described in that link above). To see if this is the same issue you can try grinding by adding Any test that expects precise behaviour from the GC to occur at certain (un-speced) points is not really a valid test in my opinion. |
@0xdaryl Thank you very much! There is a misleading message from assertion. The real problem is: |
In the AArch64 case, the failure rate was about 1/25. The test didn't take too long to run as I recall so I was able to let it run hundreds of times in a script with |
@cedrichansen Would you please run grinders "as is" to determine failure rate and with provided option? |
Yes, setting up grinders now 👍🏻 |
Ran GCDuringIteration 200x through grinder (with no jvm options provided) and no failures were recorded. After speaking with @dmitripivkine , this may be a slight difference in test environment (grinder tests running only GCDuringIteration vs nightly eclipse builds which run a larger set of tests) which might cause a different level of jit optimization to be used as the tests are run, and this resulted in different fail rate for the test in question. |
Another occurrence at https://ci.eclipse.org/openj9/job/Test_openjdk15_j9_sanity.openjdk_s390x_linux_Nightly/51/console
|
Failed again jdk-15.0.1+9_openj9-0.23.0 GA |
If the ultimate issue here is that the test is relying on un-spec'ed behaviour to succeed and that success only happens when the test is run at a "high enough" optimization level then is there any value in continuing to run this arguably invalid test as part of our standard suite of tests? I haven't been following this issue, but what is the next course of action expected here? It certainly can't be to run the aggressive liveness optimization at lower optimization levels. Perhaps the next action should be to exclude the test so that it doesn't continue to consume triaging resources. |
I am reclassifying this failure as a test issue because based on our investigation the JIT is working as designed. As mentioned above, it would seem we should either fix the test case or stop running it. |
Issue eclipse-openj9/openj9#10256 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Created adoptium/aqa-tests#2083 to exclude the test for jdk11, 15, 16. |
Issue eclipse-openj9/openj9#10256 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#10256 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
https://ci.eclipse.org/openj9/job/Test_openjdk11_j9_sanity.openjdk_ppc64le_linux_Nightly/121
java/util/WeakHashMap/GCDuringIteration.java
ub16-ppcle-3
The text was updated successfully, but these errors were encountered: