Skip to content
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

8252003: remove usage of PropertyResolvingWrapper in vmTestbase/nsk/jvmti #370

Closed
wants to merge 9 commits into from

Conversation

iignatev
Copy link
Member

@iignatev iignatev commented Sep 25, 2020

Hi all,

could you please review the patch which removes PropertyResolvingWrapper from vmTestbase/nsk/jvmti tests? as jtreg doesn't support spaces in the arguments and doesn't handle " in any special ways, the patch also:

  • s/"-javaOpts=/-javaOpts="/
  • makes nsk.jvmti.scenarios.general_functions.GF08 to use 2nd arg as verboseType and 3rd and the rest args concatenated as phrase and updates the tests accordingly
  • removes spaces and surrounding " from nsk.jvmti.test.property*
  • removes " surrounding -agentlib:, replaces spaces in -agentlib with , and updates ArgumentHandler to treat , (as well as and ~) as options delimiters, so it's consistent w/ jvmti_tools.cpp

testing: ✅ vmTestbase/nsk/jvmti on {linux,windows,macos}-x64


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8252003: remove usage of PropertyResolvingWrapper in vmTestbase/nsk/jvmti

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/370/head:pull/370
$ git checkout pull/370

@bridgekeeper
Copy link

bridgekeeper bot commented Sep 25, 2020

👋 Welcome back iignatyev! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Sep 25, 2020

@iignatev The following label will be automatically applied to this pull request: serviceability.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label (add|remove) "label" command.

@openjdk openjdk bot added the serviceability serviceability-dev@openjdk.org label Sep 25, 2020
@iignatev iignatev force-pushed the 8252003 branch 2 times, most recently from bc3d6dd to da58c7d Compare September 26, 2020 02:17
@iignatev iignatev marked this pull request as ready for review September 26, 2020 04:35
@openjdk openjdk bot added the rfr Pull request is ready for review label Sep 26, 2020
@mlbridge
Copy link

mlbridge bot commented Sep 26, 2020

Webrevs

@iignatev
Copy link
Member Author

ping?

* jni
* Registering JNI native method
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The motivation for this change isn't obvious to me, and seems less readable than the original code.

Copy link
Member Author

@iignatev iignatev Sep 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the reason I had to this change is that jtreg doesn't handle " in any special way, so gf08t003 nsk.jvmti.scenarios.general_functions.GF08.gf08t003 "Registering JNI native method" jni is passed to gf08t as
[gf08t003, nsk.jvmti.scenarios.general_functions.GF08.gf08t003, "Registering, JNI, native, method", jni]. the way I fixed that was by changing the order of phrase, verboseType, so verboseType is now 2nd arg, and phrase 3rd and the rest of args joined.

the alternative way would be to teach gf08t about " and make it join arguments until it gets an even number of " and remove them, this, from my PoV, would be a bit more confusing. if you, however, are of strong opinion here, I can go w/ that alternative (or any other if you have more suggestions)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what code used to handle passing quoted arguments? Is this something that PropertyResolvingWrapper used to do?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, PropertyResolvingWrapper was joining arguments which are within "

@@ -154,7 +154,7 @@ protected void parseOptionString(String optionString) {
if (optionString == null)
return;

StringTokenizer st = new StringTokenizer(optionString);
StringTokenizer st = new StringTokenizer(optionString, " ~,");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see jvmti_tools.cpp changes as part of this PR. Can you elaborate on why this change is needed now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jvmti_tools.cpp wasn't changed by this PR, jvmti_tools.cpp always accepted , ~ and/or , as delimiters[*]. as jtreg splits arguments by space symbol, we can't use in -agentlib:, so we had to change the delimiter used there to either , or ~, nsk/share/jvmti/ArgumentHandler takes these options (via getAgentOptionsString) and then parse in parseOptionString. but parseOptionString was using StringTokenizer w/ default delimiters, ie \t\n\r\f, and as a result it wasn't splitting options correctly after we changed the delimiter used in tests' -agentlib. in other words, this change is just fixing an old bug which we didn't care before as we always used in this agent's options.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess a better question would be is where is ~ being used in the arguments?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not in the tests which use nsk/share/jvmti/ArgumentHandler, otherwise, we would see these tests failing as wouldn't parse them correctly. quick grepping showed that that

  • ~ is used in vm/mlvm/*/jvmti tests, but these tests don't use nsk/share/jvmti/ArgumentHandler, they use nsk/share/ArgumentParser/IgnoreUnknownArgumentParser which doesn't parse agent options string at all
  • , has been used in nsk/jvmti/scenarios/contention/TC05/tc05t001/ before this patch, and the test wasn't getting options right, it was setting verbose,waittime equal to 5, instead of verbose to an empty string and waittime to 5.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after writing all of this, I think it makes sense to separate the fix in ArgumentHandler for the sake of clarity and easy of backporting. @plummercj, what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

separated into #438 / 8253872

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer that.

@openjdk
Copy link

openjdk bot commented Sep 30, 2020

@iignatev 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 more details.

After integration, the commit message for the final commit will be:

8252003: remove usage of PropertyResolvingWrapper in vmTestbase/nsk/jvmti

Reviewed-by: cjplummer, sspitsyn

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 72 new commits pushed to the master branch:

  • 092c227: 8252523: Add ASN.1 Formatter to work with test utility HexPrinter
  • 06d8cf6: 8253812: Cleanup AbstractMemberWriter
  • 424d7d6: 8252881: [JVMCI] ResolvedJavaType.resolveMethod fails in fastdebug when invoked with a constructor
  • 2a406f3: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package
  • 4b16f8a: 8253872: ArgumentHandler must use the same delimiters as in jvmti_tools.cpp
  • 4fb8c77: 8253733: Cleanup internal taglet API
  • e5ba020: 8253829: Wrong length compared in SSPI bridge
  • 9e453d9: 8239090: Improve CPU feature support in VM_Version
  • 8f7c9a7: 8252001: remove usage of PropertyResolvingWrapper in vmTestbase/nsk/jdi
  • 8cf8e46: 8253700: spurious "extends Throwable" at end of Optional.orElseThrow method declaration
  • ... and 62 more: https://git.openjdk.java.net/jdk/compare/a75edc29c6ce41116cc99530aa1710efb62c6d5a...master

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Sep 30, 2020
@sspitsyn
Copy link
Contributor

sspitsyn commented Sep 30, 2020

@iignatev ,
What are the meaning of these properties ?:
-Dnsk.jvmti.test.property=value_of_nsk.jvmti.test.property
-Dnsk.jvmti.test.property=initial_value_of_nsk.jvmti.test.property
-Dnsk.jvmti.test.property.empty.new=initial_value_of_nsk.jvmti.test.property.empty.new

Could you, please, explain this change? :

... scenarios/general_functions/GF08/gf08t001/TestDriver.java

@@ -87,8 +87,8 @@ public static void main(String[] args) throws Exception {
        nsk.jvmti.scenarios.general_functions.GF08.gf08t.main(new String[] {
                "gf08t001",
                nsk.jvmti.scenarios.general_functions.GF08.gf08t001.class.getName(),
 -               keyPhrase,
 -              "gc"});
 +              "gc",
 +              keyPhrase});
    }
}

@iignatev
Copy link
Member Author

What are the meaning of these properties ?:
-Dnsk.jvmti.test.property=value_of_nsk.jvmti.test.property
-Dnsk.jvmti.test.property=initial_value_of_nsk.jvmti.test.property
-Dnsk.jvmti.test.property.empty.new=initial_value_of_nsk.jvmti.test.property.empty.new

these are properties used by jvmti tests, the tests compare the actual value w/ expected values hardcoded in the test code. the purpose of these properties is different in different tests, ranging from just checking values by an agent to changing the value by the agent and checking that the value was changed.

Could you, please, explain this change? :

@@ -87,8 +87,8 @@ public static void main(String[] args) throws Exception {
        nsk.jvmti.scenarios.general_functions.GF08.gf08t.main(new String[] {
                "gf08t001",
                nsk.jvmti.scenarios.general_functions.GF08.gf08t001.class.getName(),
 -               keyPhrase,
 -              "gc"});
 +              "gc",
 +              keyPhrase});
    }
}

it's the same changes I described above, in two words, due to how jtreg handles spaces and " in the arguments, the positions of phrase and verboseType have been switched.

@sspitsyn
Copy link
Contributor

Okay, thanks!

@iignatev
Copy link
Member Author

Serguei, Chris, thanks a lot for your reviews.

/integrate

@openjdk openjdk bot closed this Sep 30, 2020
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 30, 2020
@openjdk
Copy link

openjdk bot commented Sep 30, 2020

@iignatev Since your change was applied there have been 72 commits pushed to the master branch:

  • 092c227: 8252523: Add ASN.1 Formatter to work with test utility HexPrinter
  • 06d8cf6: 8253812: Cleanup AbstractMemberWriter
  • 424d7d6: 8252881: [JVMCI] ResolvedJavaType.resolveMethod fails in fastdebug when invoked with a constructor
  • 2a406f3: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package
  • 4b16f8a: 8253872: ArgumentHandler must use the same delimiters as in jvmti_tools.cpp
  • 4fb8c77: 8253733: Cleanup internal taglet API
  • e5ba020: 8253829: Wrong length compared in SSPI bridge
  • 9e453d9: 8239090: Improve CPU feature support in VM_Version
  • 8f7c9a7: 8252001: remove usage of PropertyResolvingWrapper in vmTestbase/nsk/jdi
  • 8cf8e46: 8253700: spurious "extends Throwable" at end of Optional.orElseThrow method declaration
  • ... and 62 more: https://git.openjdk.java.net/jdk/compare/a75edc29c6ce41116cc99530aa1710efb62c6d5a...master

Your commit was automatically rebased without conflicts.

Pushed as commit ca0e014.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@iignatev iignatev deleted the 8252003 branch September 30, 2020 21:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated serviceability serviceability-dev@openjdk.org
3 participants