-
Notifications
You must be signed in to change notification settings - Fork 722
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/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned timeout #18908
Comments
https://openj9-jenkins.osuosl.org/job/Test_openjdk22_j9_sanity.openjdk_s390x_linux_Nightly_testList_1/1
|
eclipse-openj9/openj9#18908 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Excluding the test on zlinux via adoptium/aqa-tests#5042 |
…5042) eclipse-openj9/openj9#18908 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
@fengxue-IS Please take a look at this |
Fix adoptium#5042 which added the excludes to the wrong files. Issue eclipse-openj9/openj9#18908 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Corrected the excludes in adoptium/aqa-tests#5051 |
…5051) Fix #5042 which added the excludes to the wrong files. Issue eclipse-openj9/openj9#18908 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
@fengxue-IS any update on this? |
I wasn't able to reproduce this failure individually on a zlinux machine, running grinder to see if this is can only be reproduced in the suite. |
[Grinder 20x run on 20 machines 19/20 passed] (https://hyc-runtimes-jenkins.swg-devops.com/view/Test_grinder/job/Grinder/38416/) All machines are spec to 4CPU and ~8G RAM. so perf delta isn't related to insufficient core count. Looking at the failed test's output, its very similar to the original where timeout occurred while the test is still slowly making process. So this doesn't seem to be a functional issue, just performance. I'll see if modifying the test set up parameters could speed this up. |
I've tried to modify the test to get a bit more detail of where the perf issue is coming from. Noticed that the This is a perf issue that we should consider to investigate and address by looking into how the getstacktrace call is done for virtual threads. |
https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.openjdk_s390x_linux_Nightly_testList_0/217 - rh7-390-2 timeout Changes from previous build |
https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.openjdk_s390x_linux_Nightly_testList_0/218 - rh8-390-1 https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.openjdk_s390x_linux_Nightly_testList_1/218 - ub20-390-5 timeout https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.openjdk_s390x_linux_OMR_testList_0/107/ |
There was an update 21.0.3 -> 21.0.4+1 and this has been regularly failing on zlinux ever since. I've set it as a blocker for the next release to figure out what's going on. |
I ll take a look at the update between 21.0.3 and 21.0.4+1 |
This test looks to be a back port to 21 from 22 in 21.0.4 with modification of a new class I will create a custom build to get some profiling data to see what is causing this bottleneck in performance in |
It just fails once or more in every build, I'm not going to keep reporting them. |
We should probably exclude it. |
I created the PR to exclude test for zLinux until the perf issue is resolved. The xmac failure looks to be different from zLinux as it triggered an assertion failure during stackwalk, will have to look more into the corefile generated to find the cause. |
I launched a 50x grinder on zlinux with the latest JDK 21 nightly build, all passed, longest is ~4mins / iteration, which is much less than the timeout. Currently looks like performance isn't preventing test from completing, given that getStackTrace is a slowpath and test targets a very edge scenario, can we remove the blocker tag for this (possibly move this to backlog as well)? @pshipton Note: this have only be verified on internal machine, I don't have access to verify this on the openj9 jenkins farm, so we should also test this on openj9 jenkins. |
I will remove the blocker. Any update on the xmac failures? |
I've been running grinders on xmac, have not been able to reproduce the failure yet |
Testing using default options on zlinux and xmac |
The grinders passed, we could re-enable the testing and see how it goes. Perhaps some change has improved the behavior, or it's possible the tests only fail when they are run as part of the larger group of tests, and not when run standalone. |
https://openj9-jenkins.osuosl.org/job/Test_openjdk21_j9_sanity.openjdk_s390x_linux_OMR_testList_0/128 - rh7-390-1 |
Output show same timeout issue, 20% of workload completed in the 960s interval for jdk_lang_0, 80% complete for jdk_lang_j9_0 Running a 5 x 10x grinder on the |
Pls exclude the test again on zlinux, it's failing in pretty much every build. |
PR open to disable test on zlinux The 50x grinder from yesterday passed, so this seem to be specific to the openj9 jenkins environment. |
Removing from the 0.46 milestone. |
JDK23 x86-64_windows(
|
https://openj9-jenkins.osuosl.org/job/Test_openjdk22_j9_sanity.openjdk_s390x_linux_Nightly_testList_0/1/
jdk_lang_0
java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id0
https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Test/Test_openjdk22_j9_sanity.openjdk_s390x_linux_Nightly_testList_0/1/openjdk_test_output.tar.gz
The text was updated successfully, but these errors were encountered: