-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8325482: Test that distinct seeds produce distinct traces for compiler stress flags #26554
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
Conversation
👋 Welcome back snatarajan! A progress list of the required criteria for merging this PR into |
@sarannat This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 76 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@chhagedorn, @dafedafe) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding such a test. A few comments, otherwise, it looks good!
* @requires vm.debug == true & vm.compiler2.enabled | ||
* @requires vm.flagless |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can be merged:
* @requires vm.debug == true & vm.compiler2.enabled | |
* @requires vm.flagless | |
* @requires vm.debug == true & vm.compiler2.enabled & vm.flagless |
* @key stress randomness | ||
* @requires vm.debug == true & vm.compiler2.enabled | ||
* @requires vm.flagless | ||
* @summary Tests that stress compilations with the N different seed yield different |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @summary Tests that stress compilations with the N different seed yield different | |
* @summary Tests that stress compilations with the N different seeds yield different |
igvnTraceSet.add(igvnTrace(s)); | ||
ccpTraceSet.add(ccpTrace(s)); | ||
macroExpansionTraceSet.add(macroExpansionTrace(s)); | ||
macroEliminationTraceSet.add(macroEliminationTrace(s)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A suggestion, do you also want to check here that two runs with the same seed produce the same result to show that different seeds really produce different results due to the seed and not just some indeterminism with the test itself? How long does your test need now and afterwards with a fastdebug build? Maybe we can also lower the number of seeds if it takes too long or only do the equality-test for a single seed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review.
This is a very good point. I implemented and tested what you suggested. Below are some numbers that I obtained from running the test compiler/debug/TestStressDistinctSeed.java
with jtreg -vt
-
commit 513ab6d [with no check for same seed -> same trace ]
slowdebug
build: 7.205 seconds
driver: 32.111 seconds
fastdebug
build: 0.002 seconds
driver: 9.102 seconds -
commit 7eff4d5 [with check for same seed -> same trace and N = 10 ]
slowdebug**
build: 7.55 seconds
driver: 63.108 seconds
fastdebug
build: 0.0 seconds
driver: 16.259 seconds -
commit 14617e0 [with check for same seed -> same trace and N = 5 ]
slowdebug
build: 0.001 seconds
driver: 31.946 seconds
fastdebug
build: 0.0 seconds
driver: 8.596 seconds
I think N=5 for the updated test looks reasonable. Do you think this is okay ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update and the numbers! I agree that N=5
seems reasonable. Looks good!
igvntrace = igvnTrace(s); | ||
ccptrace = ccpTrace(s); | ||
macroexpansiontrace = macroExpansionTrace(s); | ||
macroeliminationtrace = macroEliminationTrace(s); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: You should probably use camelCase for readability of the variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this @sarannat! I just left a couple of inline comments.
String igvntrace, ccptrace, macroexpansiontrace, macroeliminationtrace; | ||
if (args.length == 0) { | ||
for (int s = 0; s < 5; s++) { | ||
igvntrace = igvnTrace(s); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you choose the 0-4 seeds to be sure that there are at least a couple of different traces? I guess it wouldn't be so easy to exclude that with random values, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review.
This comes from compiler/debug/TestStress.java
and my reasoning is same as what you mentioned above.
|
||
/* | ||
* @test | ||
* @key stress randomness |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the test actually "randomised"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My argument for this comes from JDK-8270156 where stress
and random
keywords were added to all JTreg tests which use StressGCM, StressLCM and/or StressIGVN. This was extended to StressCCP, StressMacroExpansion, and StressMacroElimination.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update!
static void sum(int n) { | ||
int[] arr1 = new int[n]; | ||
for (int i = 0; i < n; i++) { | ||
synchronized (TestStressDistinctSeed.class) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was the synchronisation added to create a more "interesting" trace (the tests seem to be running sequentially anyway)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing the stress options for macro expansion and macro elimination requires at least two macro nodes; otherwise, an empty trace is produced. Synchronisation was added solely to increase the number of macro nodes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking at this and for the clarifications @sarannat.
LGTM
Thank you for the reviews. Please sponsor. |
/integrate |
/sponsor |
Going to push as commit d25b9be.
Your commit was automatically rebased without conflicts. |
Issue
The existing test (
compiler/debug/TestStress.java
) verifies that compiler stress options produce consistent traces when using the same seed. However, there is currently no test to ensure that different seeds result in different traces.Solution
Added a test case to assess the distinctness of traces generated from different seeds. This fix addresses the fragility concern highlighted in JDK-8325482 by verifying that traces produced using N (in this case 10) distinct seeds are all not identical.
Changes to
compiler/debug/TestStress.java
While investigating this issue, I observed that in
compiler/debug/TestStress.java
, the stress options for macro expansion and macro elimination were not being triggered because there were fewer than 2 macro nodes. Note that theshuffle_macro_nodes()
incompile.cpp
is only meaningful when there are more than two macro nodes. The generated traces for macro expansion and macro elimination inTestStress.java
were empty. I have proposed changes to address this problem.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26554/head:pull/26554
$ git checkout pull/26554
Update a local copy of the PR:
$ git checkout pull/26554
$ git pull https://git.openjdk.org/jdk.git pull/26554/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 26554
View PR using the GUI difftool:
$ git pr show -t 26554
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26554.diff
Using Webrev
Link to Webrev Comment