-
Notifications
You must be signed in to change notification settings - Fork 729
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
Test-extended.system-JDK8-win_x86-64_cmprssptrs ConcurrentLoadTest_0 ForkJoinPoolTest getActiveThreadCount() expected:<0> but was:<1> #4277
Comments
Will look at this. |
@0dvictor is aware of the issue and is willing to help if this is JIT related. |
A few observations:
Attempting to reproduce the failure and determine the failure rate. |
Update: Next step is to try the Eclipse machines where this PR was reported, hence requesting machine access to Reviewer: @DanHeidinga @pshipton |
+1 |
1 similar comment
+1 |
Discussed with @JasonFengJ9 and we decided launching a grinder on win2012r2-x86-2 would be a good first step. I have launched a 50x with his instruction since he doesn't have that access. https://ci.eclipse.org/openj9/job/Test-Grinder/199/console Please advise when the grinder is complete, or further grinder testing is required. win2012r2-x86-2 labels have been removed so no other jobs will land on this machine. |
Thanks @jdekonin help launching grinders. Could JIT team continue the investigation? |
https://ci.eclipse.org/openj9/job/Test-Grinder/202/console |
As mentioned earlier, #4277 (comment):
How does the test guarantee that the number of active threads is not overestimated in the assertion? |
The spec is kind of confusing. On the other hand, do we understand why excluding the method |
@0dvictor What's the current status of this item? Its one of the few remaining 0.12.0 items |
I believe @hzongaro is working on this issue. It is still under investigation. |
I am able to reproduce this failure reliably on a Windows VM running with this option:
If I remove Interestingly enough,
From the
Looking at the first few call nodes referenced, only the first seems to be an actual call node. Perhaps the others are new nodes created by this optimization that are being endlessly retransformed - that's just a guess. I'm wondering whether there might be memory corruption happening here or elsewhere. Continuing to investigate. |
There is no fix yet, but this is not a blocker for the 0.12 release. Moving to the next milestone. |
Here's where I am in investigating this problem. When I run locally with the option The compilation of The So this is a permissible result for Now, the problem with compiling I am investigating further to verify that the failure still occurs because a thread ends up being parked for too long. |
I've rerun in Grinder in AdoptOpenJDK with a recent nightly build with some extra debugging output captured in methods in This happens even without the compilation problem in So I believe this can be classified as a test case problem. FYI: @smlambert @llxia |
@pshipton Peter, may I ask you to remove the |
Moved to comp:test. |
Closing as we haven't seen this occur again. |
Another one Not sure this will ever be resolved, I'll keep it closed unless the frequency of failure increases. |
Observed in an internal build
To rebuild the failed tests in =https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder, use the following links: https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/parambuild/?JDK_VERSION=8&JDK_IMPL=openj9&BUILD_LIST=system&PLATFORM=x86-64_windows&TARGET=ConcurrentLoadTest_0 |
https://ci.eclipse.org/openj9/job/Test-extended.system-JDK8-win_x86-64_cmprssptrs/133
The text was updated successfully, but these errors were encountered: