-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8317228: GC: Make TestXXXHeapSizeFlags use createTestJvm #15986
Conversation
👋 Welcome back lkorinth! A progress list of the required criteria for merging this PR into |
Webrevs
|
I have tested this with tier1-5 on x86. |
Added the |
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.
Some small comments but I'm ok with the change as is.
I'm not sure how we should handle additional flags we know fail, but aren't part of the CI testing. For example: G1HeapRegionSize=8m
or larger is not good for TestG1HeapSizeFlags.java
. So feel free to add this if you think that is the correct way to go.
@@ -26,8 +26,9 @@ | |||
/* | |||
* @test TestG1HeapSizeFlags | |||
* @bug 8006088 | |||
* @requires vm.gc.G1 | |||
* @requires vm.gc.G1 & vm.opt.x.Xmx == null & vm.opt.x.Xms == null & vm.opt.MinHeapSize == null & vm.opt.MaxHeapSize == null & vm.opt.InitialHeapSize == null |
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.
Please move the requires below the @key to be consistent with the other 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.
will do.
@@ -135,6 +140,7 @@ public Map<String, String> call() { | |||
map.put("jdk.containerized", this::jdkContainerized); | |||
map.put("vm.flagless", this::isFlagless); | |||
map.put("jdk.foreign.linker", this::jdkForeignLinker); | |||
map.putAll(xOptFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" ) |
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.
Does it have to be vm.opt.x.*
or could we just add those to vm.opt
and use for example: vm.opt.Xmx == null
? Or do we have -X and -XX: options that collide?
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 know of no colliding options ATM. They could be colliding in the future (especially if we chose to parse extra options not starting with a -X
). Also, I think it is incredibly confusing to reuse the vm.opt
namespace that is used by vanilla JTREG by our extension code in VMProps. I would object to put both in the vm.opt
namespace.
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 agree it is a bit ugly and the point of this being an extension is good. An alternative would be to use vm.xopt.Xmx
to even less clobber the vm.opt
namespace, but I guess we already do by adding the vm.opt.final
details.
I'm ok with the current way, just wanted to raise possible alternatives.
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.
vm.xopt
was my first choice, but it works badly because of other reasons, so lets keep it as it is now.
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.
The reason is that we need to use a namespace that starts with vm.opt
, because that string is special in JTREG. If the property starts with that prefix, there is no need to register all possible values manually --- something that would be hard to maintain. However, reusing parts of namespaces have prior art in for example vm.gc.*
so although maybe not optimal, it should not be problematic. It follows standard practice.
test/jtreg-ext/requires/VMProps.java
Outdated
private Map<String, String> xOptFlags() { | ||
return allFlags() | ||
.filter(s -> s.startsWith("-X") && !s.startsWith("-XX:") && !s.equals("-X")) | ||
.map(s -> s.replaceFirst("-*", "")) |
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 there a need to replace "-*", should you be able to just do:
.map(s -> s.replaceFirst("-*", "")) | |
.map(s -> s.replaceFirst("-", "")) |
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 will remove it, it is needed if I want to parse extra options starting with two dashes, but I chose to keep it simple and just parse extra options starting with -X
.
@lkorinth 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 281 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. ➡️ To integrate this PR with the above commit message to the |
@@ -32,7 +32,7 @@ | |||
# intermittent: flaky test, known to fail intermittently | |||
# randomness: test uses randomness, test cases differ from run to run | |||
# cgroups: test uses cgroups | |||
keys=stress headful intermittent randomness cgroups | |||
keys=stress headful intermittent randomness cgroups flag-sensitive |
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.
Maybe add a comment above about the key, similar to the others. Something like:
# flag-sensitive: test is sensitive to certain flags and might fail when flags are passed in
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, I reworded it just slightly
…en flags are passed using -vmoptions and -javaoptions
Thanks Stefan and Albert!!! /integrate |
Going to push as commit 7ca0ae9.
Your commit was automatically rebased without conflicts. |
Minor testing done, I will test more later with other fixes.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15986/head:pull/15986
$ git checkout pull/15986
Update a local copy of the PR:
$ git checkout pull/15986
$ git pull https://git.openjdk.org/jdk.git pull/15986/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 15986
View PR using the GUI difftool:
$ git pr show -t 15986
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15986.diff
Webrev
Link to Webrev Comment