-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8339289: Enhance Attach API to support arbitrary length arguments - Windows #20782
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
Conversation
Currently Attach API has the following restrictions:
DCmd framework supports any number of command arguments, but encodes all arguments as a single attach operation arguement, so total length of all arguments are restricted by 1024 symbols. Attach API changes:
Windows implementation:
|
👋 Welcome back amenkov! A progress list of the required criteria for merging this PR into |
@alexmenkov 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 768 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 |
|
@alexmenkov The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
Thanks for putting the details in a separate comment. That will make the emails You use the word |
Also thanks for including all the testing info! |
Bytes. The code used |
Looking for reviewers for the fix |
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 is nice fix, thank you for doing this!
I still need one more pass on the Windows AttachListener
part and hope to complete it early next week.
src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java
Outdated
Show resolved
Hide resolved
renamed JVM_EnqueueOperation2 to JVM_EnqueueOperation_v2 for consistency (per Serguei request)
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've posted some nits and one questions.
Otherwise, this change looks good to me.
Thank you for the updates.
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.
Thank you for the updates. Looks good.
|
||
public static void main(String[] args) throws Exception { | ||
// if the test (client part) in the "compat" mode | ||
boolean clientCompat = "true".equals(System.getProperty("jdk.attach.compat")); |
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.
Boolean.getBoolean("jdk.attach.compat") ignores case for us as well.
But more generally, are we happy with "jdk.attach.compat" as a boolean flag, or would "jdk.attach.version" be better?
(which is mainly asking if we think there might ever be another version!)
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 thought about making the property numeric, but that adds complexity in the logic and I don't think we will need another version soon. Anyway it's internal property for testing only, so we can change it any time.
Thanks for updating, looks good. I think it's clearer now that this is not just a Windows-specific fix, but will be an enhancement for all platforms in the long term. Likely argument length is more of a limitation than number of arguments. Looking back at JDK-8215622: Add dump to file support for jmap –histo |
Thank you for review Serguei and Kevin |
/integrate |
Going to push as commit 36d7173.
Your commit was automatically rebased without conflicts. |
@alexmenkov Pushed as commit 36d7173. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
More detailed explanations on the 1st comment.
Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) on Windows with jdk21u and jdk8u.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20782/head:pull/20782
$ git checkout pull/20782
Update a local copy of the PR:
$ git checkout pull/20782
$ git pull https://git.openjdk.org/jdk.git pull/20782/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 20782
View PR using the GUI difftool:
$ git pr show -t 20782
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20782.diff
Webrev
Link to Webrev Comment