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

8273684: Replace usages of java.util.Stack with ArrayDeque #5294

Closed

Conversation

turbanoff
Copy link
Member

@turbanoff turbanoff commented Aug 29, 2021

Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.


Progress

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

Issue

  • JDK-8273684: Replace usages of java.util.Stack with ArrayDeque

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5294/head:pull/5294
$ git checkout pull/5294

Update a local copy of the PR:
$ git checkout pull/5294
$ git pull https://git.openjdk.java.net/jdk pull/5294/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5294

View PR using the GUI difftool:
$ git pr show -t 5294

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5294.diff

Sorry, something went wrong.

@bridgekeeper
Copy link

bridgekeeper bot commented Aug 29, 2021

👋 Welcome back turbanoff! 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 Aug 29, 2021

@turbanoff The following labels will be automatically applied to this pull request:

  • 2d
  • serviceability
  • sound
  • swing

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.

@openjdk openjdk bot added 2d client-libs-dev@openjdk.org serviceability serviceability-dev@openjdk.org swing client-libs-dev@openjdk.org sound client-libs-dev@openjdk.org labels Aug 29, 2021
@mrserb
Copy link
Member

mrserb commented Sep 10, 2021

Looks fine

@mrserb
Copy link
Member

mrserb commented Sep 10, 2021

Or maybe not, did you check that the order of pushing and the order of iteration for the stack and ArrayDeque are the same? I am not sure about it.

Replace one usage of ArrayList instead of ArrayDeque to preserve order of array elements as it was in original code
@turbanoff
Copy link
Member Author

Yeah. You are right! TIL that order of iteration is different in ArrayDequeu vs Stack: Stack.push() adds to the "end of stack" (it just calls Vector.add()), while ArrayDeque.push adds "first element"
Luckily for us there was only one place which depend on this. It's small method javax.swing.text.html.HTMLDocument.HTMLReader#getPathTo. I've changed method to use ArrayList instead.

@turbanoff turbanoff changed the title [PATCH] Stack usages can be replaced with ArrayDequeue [PATCH] Stack usages can be replaced with ArrayDequeue or ArrayList Sep 10, 2021
@turbanoff turbanoff changed the title [PATCH] Stack usages can be replaced with ArrayDequeue or ArrayList 8273684: Unnecessary Stack usage Sep 13, 2021
@openjdk openjdk bot added the rfr Pull request is ready for review label Sep 13, 2021
@mlbridge
Copy link

mlbridge bot commented Sep 13, 2021

Webrevs

@mlbridge
Copy link

mlbridge bot commented Sep 14, 2021

Mailing list message from Bernd Eckenfels on serviceability-dev:

Maybe better use addFirst(), for example in CommandProcessor there is a comment that order matters (did not check it more closely), so it?s probably best to not reverse orders in any place? The Dequeue Javadoc lists addFirst as the aproperiate stack#push replacement.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: serviceability-dev <serviceability-dev-retn at openjdk.java.net> im Auftrag von Andrey Turbanov <github.com+741251+turbanoff at openjdk.java.net>
Gesendet: Monday, September 13, 2021 9:29:26 PM
An: client-libs-dev at openjdk.java.net <client-libs-dev at openjdk.java.net>; serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
Betreff: Re: RFR: 8273684: Unnecessary Stack usage

On Sun, 29 Aug 2021 21:14:19 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

Usage of thread-safe collection Stack is unnecessary. It's recommended to use ArrayDequeue if a thread-safe implementation is not needed.

Yeah. You are right! TIL that order of iteration is different in ArrayDequeu vs Stack: Stack.push() adds to the "end of stack" (it just calls Vector.add()), while ArrayDeque.push adds "first element"
Luckily for us there was only one place which depend on this. It's small method `javax.swing.text.html.HTMLDocument.HTMLReader#getPathTo`. I've changed method to use ArrayList instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5294
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210914/8639de58/attachment.htm>

@turbanoff
Copy link
Member Author

turbanoff commented Sep 14, 2021

Maybe better use addFirst(), for example in CommandProcessor there is a comment that order matters (did not check it more closely), so it?s probably best to not reverse orders in any place?

In all other places (except HTMLReader), iteration order don't matter. Stack only accessed via classic well known stack operations: push, pop, peek. This methods work in the same way in ArrayDeque. So I think replacing with addFirst isn't necessary.

@@ -985,7 +985,7 @@ public void doit(Tokens t) {
Iterator i = agent.getTypeDataBase().getTypes();
// Make sure the types are emitted in an order than can be read back in
HashSet<String> emitted = new HashSet<>();
Stack<Type> pending = new Stack<>();
ArrayDeque<Type> pending = new ArrayDeque<>();
Copy link
Contributor

Choose a reason for hiding this comment

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

Have you run the clhsdb vmstructsdump command to make sure the ordering hasn't changed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

There is something wrong with the version of jhsdb you are running. It appears to be an old version, not the latest. You should not be seeing the following warning. The code that produces it is not even present in the latest jdk.
Warning: Nashorn engine is planned to be removed from a future JDK release

Copy link
Member Author

Choose a reason for hiding this comment

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

I wondered about this too. Perhaps this messages coming from the target JDK which I'm attached too?
I attached to my IntelliJ IDEA process. It uses JDK 11.

Copy link
Contributor

Choose a reason for hiding this comment

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

SA doesn't doesn't run any code on the target.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if you are exporting CLASSPATH and that is causing jhsdb to pick up the wrong SA implementation.

Copy link
Member Author

Choose a reason for hiding this comment

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

Rechecked again.
Now without involving IDEA. Just started small java program and then attached.
Then checkouted revision before my commits (a9188f2) and rebuild and repeated.
изображение

with_fixes_java_vmstructsdump.txt
without_fixes_java_vmstructsdump.txt

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, looks good. You can consider the SA changes reviewed.

@turbanoff turbanoff changed the title 8273684: Unnecessary Stack usage 8273684: Replace usages of java.util.Stack with ArrayDeque Sep 15, 2021
@openjdk
Copy link

openjdk bot commented Sep 15, 2021

@turbanoff 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:

8273684: Replace usages of java.util.Stack with ArrayDeque

Reviewed-by: cjplummer, serb

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

  • 2a2e919: 8273685: Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction
  • 8302061: 8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms
  • 2f8c221: 8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark
  • 17f7a45: 8273913: Problem list some headful client jtreg tests that fail on macOS 12
  • 27d747a: 8273877: os::unsetenv unused
  • 35f6f1d: 8273808: Cleanup AddFontsToX11FontPath
  • 1890d85: 8273872: ZGC: Explicitly use 2M large pages
  • 54b4567: 8273880: Zero: Print warnings when unsupported intrinsics are enabled
  • e07ab82: 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record
  • 8c022e2: 8270434: JDI+UT: Unexpected event in JDI tests
  • ... and 225 more: https://git.openjdk.java.net/jdk/compare/a9188f237ec23d4ca2a172e9a7897cb6e2b69857...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@plummercj, @mrserb) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Sep 15, 2021
@turbanoff
Copy link
Member Author

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Sep 17, 2021
@openjdk
Copy link

openjdk bot commented Sep 17, 2021

@turbanoff
Your change (at version e39a52f) is now ready to be sponsored by a Committer.

@mrserb
Copy link
Member

mrserb commented Sep 22, 2021

/sponsor

@openjdk
Copy link

openjdk bot commented Sep 22, 2021

Going to push as commit cbe57e8.
Since your change was applied there have been 277 commits pushed to the master branch:

  • a72c8aa: 8273921: Refactor NSK/JDI tests to create thread using factory
  • 161fdb4: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported
  • 0fc47e9: 8266666: Implementation for snippets
  • 6d91a3e: 8269039: Disable SHA-1 Signed JARs
  • 42d5d2a: 8274056: JavaAccessibilityUtilities leaks JNI objects
  • 57df0db: 8270873: JFR: Catch DirectoryIteratorException when scanning for .jfr files
  • 111d5e1: 8273915: Create 'nosafepoint' rank
  • 7acec3f: 8236505: Mark jdk/editpad/EditPadTest.java as @headful
  • afd218d: 8274053: [BACKOUT] JDK-8270842: G1: Only young regions need to redirty outside references in remset.
  • a5108a6: 8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher
  • ... and 267 more: https://git.openjdk.java.net/jdk/compare/a9188f237ec23d4ca2a172e9a7897cb6e2b69857...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Sep 22, 2021
@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 sponsor Pull request is ready to be sponsored labels Sep 22, 2021
@openjdk
Copy link

openjdk bot commented Sep 22, 2021

@mrserb @turbanoff Pushed as commit cbe57e8.

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

@turbanoff turbanoff deleted the avoid_unnecessary_stack_usage branch October 4, 2021 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2d client-libs-dev@openjdk.org integrated Pull request has been integrated serviceability serviceability-dev@openjdk.org sound client-libs-dev@openjdk.org swing client-libs-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.

None yet

3 participants