8294362: UL: Replace the internal usage of manual buffers with stringStream in LogSelection

[jdksjolen]

Hi,

This is only a refactoring where the usage of manual character buffers are replaced with output streams, leading to much simpler code.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8294362: UL: Replace the internal usage of manual buffers with stringStream in LogSelection

Reviewers

• David Holmes (@dholmes-ora - Reviewer)
• Robbin Ehn (@robehn - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10553/head:pull/10553
$ git checkout pull/10553

Update a local copy of the PR:
$ git checkout pull/10553
$ git pull https://git.openjdk.org/jdk pull/10553/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10553

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10553.diff

[bridgekeeper]

👋 Welcome back jsjolen! 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]

@jdksjolen The following label will be automatically applied to this pull request:

• hotspot-runtime

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 pull request command.

[mlbridge]

Webrevs

• 00: Full (57704557)

[dholmes-ora]

This definitely seems simpler and cleaner, but raises the obvious question: why was it not done this way in the first place? Are there initialization issues/constraints with use of the stream classes?

I need to see if there is some historical info on the initial implementation here.

Thanks.

[dholmes-ora]

I need to see if there is some historical info on the initial implementation here.

Nope. Lets see if anyone else knows why the code may have originally been written the way it was.

[jdksjolen]

This definitely seems simpler and cleaner, but raises the obvious question: why was it not done this way in the first place? Are there initialization issues/constraints with use of the stream classes?

I need to see if there is some historical info on the initial implementation here.

Thanks.

A guess: The features stringStream depended on used to not be available pre-initialization.

Quick edit: I noticed now that you already mentioned this as a potential issue :-).

[robehn]

Look good.

[openjdk]

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

8294362: UL: Replace the internal usage of manual buffers with stringStream in LogSelection

Reviewed-by: dholmes, rehn

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

• d9b25e8: 8296426: x86: Narrow UseAVX and UseSSE flags
• 8146e1a: 8296347: Memory leak from ClassPathDirEntry::_dir
• 671f84b: 8296143: CertAttrSet's set/get mechanism is not type-safe
• d04d656: 8296433: Encountered null CLD while loading shared lambda proxy class
• 74f2b16: 8295303: cleanup debug agent's confusing use of EI_GC_FINISH
• 0ee25de: 8296504: Memory leak in G1PLABAllocator::PLABData
• dd5d4df: 8295658: G1: Refactor G1SegmentedArray to indicate that it is an allocator
• cf65605: 8296445: C++ syntax error in jdwpTransport.h
• 1169dc0: 8296447: RISC-V: Make the operands order of vrsub_vx/vrsub_vi consistent with RVV 1.0 spec
• 4c80dff: 8296435: RISC-V: Small refactoring for increment/decrement
• ... and 530 more: https://git.openjdk.org/jdk/compare/dd51f7e0b75d3a16403608d89cd206ac0bedf882...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.

[jdksjolen]

I need to see if there is some historical info on the initial implementation here.

Nope. Lets see if anyone else knows why the code may have originally been written the way it was.

We're not seeing anyone wanting to chime in on this :-). The reasoning might simply be: "Because it happened to be written that way."

[dholmes-ora]

We're not seeing anyone wanting to chime in on this

No, unfortunately the committers who have been very active in this code most recently have not commented on it.

[jdksjolen]

Re: Why this code uses C-strings.

The commit that introduces "raw" string handling for logOutput.cpp regarding these changes is from Marcus Larsson. I doubt that we'll hear from him :-). The only reviewer (from mailing list thread) of that commit that I know still works on the JDK is @dholmes-ora. The review comments were literally: "Looks good".

[dholmes-ora]

Seems there is no more input coming on this so ... looks good enough to me.

Thanks.

[jdksjolen]

/integrate

Thank you, David!

[openjdk]

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

• fef68bb: 8296515: RISC-V: Small refactoring for MaxReductionV/MinReductionV/AddReductionV node implementation
• 82cbfb5: 8296140: Drop unused field java.util.Calendar.DATE_MASK
• fd83764: 8296239: ISO 4217 Amendment 174 Update
• d9b25e8: 8296426: x86: Narrow UseAVX and UseSSE flags
• 8146e1a: 8296347: Memory leak from ClassPathDirEntry::_dir
• 671f84b: 8296143: CertAttrSet's set/get mechanism is not type-safe
• d04d656: 8296433: Encountered null CLD while loading shared lambda proxy class
• 74f2b16: 8295303: cleanup debug agent's confusing use of EI_GC_FINISH
• 0ee25de: 8296504: Memory leak in G1PLABAllocator::PLABData
• dd5d4df: 8295658: G1: Refactor G1SegmentedArray to indicate that it is an allocator
• ... and 533 more: https://git.openjdk.org/jdk/compare/dd51f7e0b75d3a16403608d89cd206ac0bedf882...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jdksjolen Pushed as commit 4a0093c.

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