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
8269032: Stringdedup tests are failing if the ergonomically select GC does not support it #4603
Closed
kimbarrett
wants to merge
3
commits into
openjdk:master
from
kimbarrett:simpler_fix_test_requirements
+90
−12
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
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.
... and same here, this should be
@requires vm.gc.Shenandoah
and it should pass-XX:+UseShenandoahGC
to the test, which it appends to the list of arguments for the JVM that will be spawned.Of course, same comments apply to all tests.
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.
I think the eventual goal should probably be that these are all driver
tests, and just have
@requires vm.gc != "Epsilon"
with a "driver" test,but we're not there yet.
Until then, what I'm attempting to do is get good test coverage without
wasting a lot of testing resources. Driver tests are preferred to othervm
tests where that's possible, for better resource utilization. Driver tests
can't use VM options.
Most of the string deduplication implementation is entirely GC-agnostic. So
ideally we would run these tests with a given GC as part of focused testing
of that GC, and not when testing some other GC. Hence the use of
@requires
for specific GC options (vm.gc == "XXX").
But that doesn't provide any testing for the case where the GC is being
selected ergonomically. The new
@test
clauses to test with G1 are notentirely ideal, since they won't run if someone builds a VM that excludes G1
but does include some other GC that supports string deduplication. But I
couldn't come up with a way to address that without having to deal with
WhiteBox.
I'm not sure exactly what you are proposing and how it might relate to the
above considerations. I'm not enamored of what I've proposed, but haven't
come up with something I like better. Maybe if you could be more explicit
about the diffs you think should be made for one of the tests?
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.
Sorry, let me be more specific. I was proposing you do this (in all these tests):
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.
That's an approach that I had looked at but decided not to take.
It involves having a near duplicated
@test
block for each GC that supportsdeduplication, at least until they all do (other than Epsilon).
I think it wastes testing resources. Each testing configuration that allows
ergonomic GC selection will run these tests for every supporting and
included GC. Individually it's not terrible, but this sort of thing adds up.
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.
I don't think that's a problem you should attempt solve in this PR. It's a much wider problem, affects many more tests and I don't think there's necessarily consensus on what should happen if you run a test and don't explicitly set a GC. At the moment, tests in this category typically run with all GCs, and that's so far been what to expect. I suggest we continue to follow our current model for stringdedup tests until there's consensus on what a new model should look like, and only then start to move tests in a new direction. Even if the current model is sub-optimal and messy, introducing a new type of behavior for these tests seems to just add to the mess, and there's at least some value in having tests behave the same way.
If we want to move in the direction where running a test without specifying a GC will run it once with the ergonomically selected GC, then it might be that simply altering the meaning of
vm.gc.XXX
to "XXX is supported and selected (explicitly or ergonomically)" is enough. Of course, it's tricky to clearly see that all use cases are covered, so something like this will need more careful investigation.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.
After thinking about it for a while, I've decided to go with Per's suggestion. I don't really like the duplication of
@test
blocks, but I don't like any of the other options either.Tested by locally (linux-x64) configuring with Shenandoah included and running the gc/stringdedup tests with
(1) no additional options,
(2) -XX:+NeverActAsServerClassMachine,
(3) -XX:+UseG1GC,
(4) -XX:+UseShenandoahGC
and verifying the expected tests were run.