-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
8320750: Allow a testcase to run with multiple -Xlog #16824
Conversation
👋 Welcome back lkorinth! A progress list of the required criteria for merging this PR into |
@lkorinth To determine the appropriate audience for reviewing this pull request, one or more labels corresponding to different subsystems will normally be applied automatically. However, no automatic labelling rule matches the changes in this pull request. In order to have an "RFR" email sent to the correct mailing list, you will need to add one or more applicable labels manually using the /label pull request command. Applicable Labels
|
Hi Leo, I'm sorry but I don't understand this change. What I do know is that
What exactly happens to a testcase which requires two arguments? I guess that we have none, as these would have crashed? |
correct. This bug is introduce by me in https://bugs.openjdk.org/browse/JDK-8317228 where I added support to |
I'm also having trouble understanding problem and solution here, but mainly because I don't understand what the jtreg code is supposed to be doing anyway. I'm surprised to see jtreg trying to streamline the set of flags that have been passed, I expect it to leave them alone and let the VM process them as it would normally do so. |
I have been starting to change test cases to use |
/label add hotspot |
@lkorinth |
Webrevs
|
What about -Xlog:gc=debug,safepoint=trace and other -XX flags that take a comma-separated list? |
Sure but I am trying to understand that previous change. I don't speak "stream" so can't figure out what exactly you have done. What I expected you to do was combine the various flags coming in from jtreg arguments and env vars, that would affect the VM under test, then see if that set of args contains the |
|
JTREG does the exclusion of test cases when we tag them with |
This seems a rather fragile mechanism. In practice I expect there are only a handful of -X flags tests really care about - and some of them already handled (e.g. -Xint, -Xmixed,-Xcomp are exposed by the vm.mode value). Merging requires you to know how the launcher and VM would process things and it is different for different things. So what you have now acts as "last one wins" with a special case for -Xlog such that only its presence can be detected not its value (not a loss I think). It seems like this fixes the bug your original code had, but I can't review it as I don't understand the actual code involved. |
I think this feature will mostly be used to filter out un-allowed flag combinations, and I guess the user will seldom if ever be interested in the actual values (just the keys). Do you have an idea for something that is less fragile? I find it a bit ugly to special case |
I'm not sure this is the right approach for -X flags. |
It's better to get the value from the VM after it has processed the flags, rather than trying to look at pre-processed flag values. The value given on the command-line isn't always the same as the final value. |
The VM processes -XX flags such that "last value wins" - though in part that is due to convention in that the nature of our flags tend to be absolute rather than relative (e.g. imagine a flag The -X and other flags are a mixed bunch and there are no generally applicable rules. I struggle to see the actual benefit of The -Xlog handling for example, I can't see any case where a test should care about any incoming logging flags - even if the test itself performs logging, it should not care about other logging settings - and we would fix the test if there was a specific problem. Even for the heap flags I'm struggling to see the usefulness. If a test has specific heap size requirements then the test should set them - and last setting wins, so should be no issue there (I suspect many tests are lazy though and assume defaults so for example a test may set -Xmx without -Xms and so an externally supplied -Xms may conflict with it - but in that case I'd question why anyone was forcing -Xms externally like that) . Taking a specific example, to me |
Hi again and sorry for taking so much time. I have been thinking about this for a while, and done some code search inside jtreg etc. I have not really come to a conclusion, but let me try to summarize some of it. First I want to say that the idea (in the beginning) was not to test for the final value to use but to test that certain flags does not collide/conflict with flags added by the test case. For example, the different flags that chooses a gc collides with each other, and I wanted to make similar checks for short options. I was about to try to change lots of gc test cases to use test APIs that propagates VM flags and I thought I would need that functionality. It does not help me to check the final vm flag values if the flags have conflicted before that. It also somewhat irritates me that jtreg has a mechanism to test for only However, after this review and after starting to look at certain flags, it seems that it is in /general/ alright to combine flags that obviously conflicts. There seems to be no problem to tell java to use the interpreter and then later to tell it to use the compiler (quite different from telling it to use serial gc followed by parallel that is not allowed). Another thing I have discovered is that it seems to me that vm flags are prepended and not appended when using I could remove the short flag detection in VMProps, but I would not be happy if I later see that certain of these flags do conflict. It might also be that it is good, for other reasons, to test against these flags with I am willing to remove parsing of short flags if you know that it will not be useful; I think it might be better to just fix the bug as I suspect that this functionality is useful. I also want to say that I am a bit conflicted and that I am not really sure, I do like to remove not needed code. Feedback on if/how short flag conflicts would be valuable for me. Feedback on whether I have understood the prepending of vm flags in both jtreg as well as in our test framework correctly would be welcomed as well. |
Hi again, I would like to resolve this issue in some way, as I am responsible for introducing this problem. I think the proposed fix is alright and gives us a way to |
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.
Looks OK. It was a little bit awkward to read the code at first, but I think I understand what it does. There are probably ways to structure the code to make it easier to read.
@lkorinth This change is no longer ready for integration - check the PR body for details. |
@lkorinth - I fixed the typo in the bug's synopsis. You'll need to adjust the PR's title. |
I'm okay with fixing the bug that was introduced, just so we don't have this crash potential, though I dislike the special handling of As I stated earlier I won't actually hit the Approve button because I don't understand the Java code involved. |
Hi again, is there any opposition to me integrating this? If not I will integrate with only one reviewer (as this is not hotspot code). If I need to clarify the changes, I can and will do that. |
test/jtreg-ext/requires/VMProps.java
Outdated
* | ||
* Multiple invocations of the same flag will overwrite the flag | ||
* value with the latest value. Except for -Xlog where the value | ||
* will always be NONEMPTY_TEST_SENTINEL (when pressent). |
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 you fix the typo "pressent" to "present"?
As I said previously I have no objection to this fix dealing with the bug that was introduced by JDK-8317228. But I think JDK-8317228 needs revisiting in itself. |
I have changed the code after suggestions from Stefan and Johan. I have added a test. I have verified that the test runs in tier1. I am awaiting tier 1-3 to finish. |
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.
Looks excellent to me!
/** | ||
* Split an -Xflag string into a name part (without leading dash) | ||
and a value part ("true" if no value was given) | ||
*/ |
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.
May I suggest sparing the reader some effort and adding a couple of examples e.g.:
-Xmx4g => (Xmx, 4g)
-Xcheck:jni => (Xcheck, :jni)
-Xbootclasspath/a:<path> => (Xbootclasspath, /a:<path>)
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 last example is interesting. Is it supposed to be:
-Xbootclasspath/a:<path> => (Xbootclasspath, /a:<path>
or should it be:
-Xbootclasspath/a:<path> => (Xbootclasspath/a, <path>)
I think it should be the latter and if that's the case then the regex should be updated.
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 find this version much easier to quickly read and understand. I've added a few suggestions that you consider, but only the comments around -Xbootclasspath/a is a blocker for integration.
/** | ||
* Split an -Xflag string into a name part (without leading dash) | ||
and a value part ("true" if no value was given) | ||
*/ |
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 last example is interesting. Is it supposed to be:
-Xbootclasspath/a:<path> => (Xbootclasspath, /a:<path>
or should it be:
-Xbootclasspath/a:<path> => (Xbootclasspath/a, <path>)
I think it should be the latter and if that's the case then the regex should be updated.
@@ -140,7 +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" ) | |||
map.putAll(xFlags()); // -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.
This has a slightly different style than the vmOptFinalFlags:
map.putAll(xFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" )
vs
vmOptFinalFlags(map);
It could be nice to unify the style so that we have:
vmOptXFlags(map);
vmOptFinalFlags(map);
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.
In this case I much prefer my functional style of returning a map value instead of mutating a map argument. I feel I will never finish this if I follow the rabbit hole of updating vmOptFinalFlags(map)
.
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 can unify this code after you get this integrated.
* Check if flag is an -Xflag | ||
*/ | ||
private static boolean isXFlag(String flag) { | ||
return flag.startsWith("-X") && !flag.startsWith("-XX:") && !flag.equals("-X"); |
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.
-XX:
is not wrong, but I wonder if this could/should be -XX
instead.
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.
Arguably -XXSomeFlag
is a an x flag and not an xx flag, but I will change it.
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 looking a bit more at the code, I will keep the original code as the "-XX:"
is used in many places in VMProps.java
I have created https://bugs.openjdk.org/browse/JDK-8325763. After I have fixed that I will close this, after much thinking, I think it is better to get rid of the feature. |
@lkorinth this pull request can not be integrated into git checkout _8320750
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
@lkorinth This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
@lkorinth This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
Running a testcase with muliple -Xlog crashes JTREG test cases. This is because
Collector.toMap
is not given a merge strategy.When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for
vm.opt.*
in JTREG.If the flag tested is
-Xlog
, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple-Xlog
all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to@require
on specific values by mistake.Tested with:
Running tier1
Progress
Integration blocker
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16824/head:pull/16824
$ git checkout pull/16824
Update a local copy of the PR:
$ git checkout pull/16824
$ git pull https://git.openjdk.org/jdk.git pull/16824/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 16824
View PR using the GUI difftool:
$ git pr show -t 16824
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16824.diff
Webrev
Link to Webrev Comment