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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -27,7 +27,7 @@ | ||
* @test TestStringDeduplicationAgeThreshold | ||
* @summary Test string deduplication age threshold | ||
* @bug 8029075 | ||
* @requires vm.gc == "null" | vm.gc == "G1" | vm.gc == "Shenandoah" | ||
* @requires vm.gc == "G1" | vm.gc == "Shenandoah" | ||
* @library /test/lib | ||
* @library / | ||
* @modules java.base/jdk.internal.misc:open | ||
@@ -36,8 +36,22 @@ | ||
* @run driver gc.stringdedup.TestStringDeduplicationAgeThreshold | ||
*/ | ||
|
||
/* | ||
* @test TestStringDeduplicationAgeThreshold | ||
* @summary Test string deduplication age threshold | ||
* @bug 8029075 | ||
* @requires vm.gc == "null" & vm.gc.G1 | ||
* @library /test/lib | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ... and same here, this should be Of course, same comments apply to all tests. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 Until then, what I'm attempting to do is get good test coverage without Most of the string deduplication implementation is entirely GC-agnostic. So But that doesn't provide any testing for the case where the GC is being I'm not sure exactly what you are proposing and how it might relate to the There was a problem hiding this comment. Choose a reason for hiding this commentThe 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): index 66d58a6e580..6a358ae54f3 100644
--- a/test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
+++ b/test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
@@ -27,26 +27,26 @@ package gc.stringdedup;
* @test TestStringDeduplicationFullGC
* @summary Test string deduplication during full GC
* @bug 8029075
- * @requires vm.gc == "G1" | vm.gc == "Shenandoah"
+ * @requires vm.gc.G1
* @library /test/lib
* @library /
* @modules java.base/jdk.internal.misc:open
* @modules java.base/java.lang:open
* java.management
- * @run driver gc.stringdedup.TestStringDeduplicationFullGC
+ * @run driver gc.stringdedup.TestStringDeduplicationFullGC G1
*/
/*
* @test TestStringDeduplicationFullGC
* @summary Test string deduplication during full GC
* @bug 8029075
- * @requires vm.gc == "null" & vm.gc.G1
+ * @requires vm.gc.Shenandoah
* @library /test/lib
* @library /
* @modules java.base/jdk.internal.misc:open
* @modules java.base/java.lang:open
* java.management
- * @run driver gc.stringdedup.TestStringDeduplicationFullGC G1
+ * @run driver gc.stringdedup.TestStringDeduplicationFullGC Shenandoah
*/
public class TestStringDeduplicationFullGC { There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 I think it wastes testing resources. Each testing configuration that allows There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 Tested by locally (linux-x64) configuring with Shenandoah included and running the gc/stringdedup tests with |
||
* @library / | ||
* @modules java.base/jdk.internal.misc:open | ||
* @modules java.base/java.lang:open | ||
* java.management | ||
* @run driver gc.stringdedup.TestStringDeduplicationAgeThreshold G1 | ||
*/ | ||
|
||
public class TestStringDeduplicationAgeThreshold { | ||
public static void main(String[] args) throws Exception { | ||
TestStringDeduplicationTools.maybeOverrideGC(args); | ||
TestStringDeduplicationTools.testAgeThreshold(); | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -50,6 +50,8 @@ class TestStringDeduplicationTools { | ||
private static Unsafe unsafe; | ||
private static byte[] dummy; | ||
|
||
private static String overridingGC = null; | ||
|
||
static { | ||
try { | ||
Field field = Unsafe.class.getDeclaredField("theUnsafe"); | ||
@@ -63,6 +65,12 @@ class TestStringDeduplicationTools { | ||
} | ||
} | ||
|
||
public static void maybeOverrideGC(String[] args) { | ||
if (args.length > 0) { | ||
overridingGC = args[0]; | ||
} | ||
} | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be good to parse the gc string. Otherwise it might be easy to make a spelling mistake or add another argument (before) to the driver without realizing the error. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should just blindly pass this option (or options) to the spawned JVMs, without looking at them. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think there's any point to doing any parsing here, and good reason not to. If the value isn't sensible as a GC name the test will very likely fail because of an invalid CLA to the subprocess. And validating that it's a valid GC name involves using vm.gc.GC, which brings in WhiteBox and all its attendant cruft. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, but is it not better then to skip the string concatenation part and give the complete flag directly as an argument to the driver directive? |
||
private static Object getValue(String string) { | ||
try { | ||
return valueField.get(string); | ||
@@ -226,6 +234,9 @@ private static OutputAnalyzer runTest(String... extraArgs) throws Exception { | ||
}; | ||
|
||
ArrayList<String> args = new ArrayList<String>(); | ||
if (overridingGC != null) { | ||
args.add("-XX:+Use" + overridingGC + "GC"); | ||
} | ||
args.addAll(Arrays.asList(defaultArgs)); | ||
args.addAll(Arrays.asList(extraArgs)); | ||
|
||
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 this should be
@requires vm.gc.G1
and it should pass-XX:+UseG1GC
to the test, which it appends to the list of arguments for the JVM that will be spawned.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 you missed the point. I'm pretty sure the original report arose
because of running these tests on a non-server machine. I don't have ready
access to such a machine, but by using that option I was able to fake things
enough to feel confident these tests would now run on such.
I think the main problem with -XX:+NeverActAsServerClassMachine (and the
associated -XX:+AlwaysActAsServerClassMachine) is that they are product
options rather than diagnostic options. That may be because they've been
around "forever" and nobody has taken the time to change them.
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 missed that github attached the above reply about
-XX:+NeverActAsServerClassMachine
to this unrelated conversation thread. Sorry about that.)