8334738: os::print_hex_dump should optionally print ASCII

[tstuefe]

Motivated by analyzing CDS dump differences for reproducible builds, I found an optional ASCII printout to be valuable. As usual with hex dumps, ascii follows hex printout

Example:

   118 0x00000000000001c0:   204b444a6e65704f 53207469422d3436 4d56207265767265 6564747361662820   OpenJDK 64-Bit Server VM (fastde
   119 0x00000000000001e0:   692d343220677562 2d6c616e7265746e 68742e636f686461 756f732e73616d6f   bug 24-internal-adhoc.thomas.sou
   120 0x0000000000000200:   726f662029656372 612d78756e696c20 45524a203436646d 746e692d34322820   rce) for linux-amd64 JRE (24-int
   121 0x0000000000000220:   64612d6c616e7265 6d6f68742e636f68 6372756f732e7361 6c697562202c2965   ernal-adhoc.thomas.source), buil
   122 0x0000000000000240:   323032206e6f2074 5430322d36302d34 32313a35343a3031 672068746977205a   t on 2024-06-20T10:45:12Z with g
   123 0x0000000000000260:   2e352e3031206363 0000000000000030 0000000000000000 0000000000000000   cc 10.5.0_______________________
   124 0x0000000000000280:   0000000000000000 0000000000000000 0000000000000000 0000000000000000   ________________________________
   125 0x00000000000002a0:   0000000000000000 0000000000000000 0000000000000000 0000000000000000   ________________________________

The patch does that.

Small unrelated changes:

• I rewrote and extended the gtests, testing now a real-life printout containing a mixture or readable and non-readable pages, and printable and non-printable characters. I re-enabled tests on Windows, since https://bugs.openjdk.org/browse/JDK-8185734 is long solved.

• The new test uncovered an issue on 32-bit when printing giant words. We shift a signed value by 32 bits upwards, which can result in -1 resp. ffffffff in the upper half of the giant word. One of the pitfalls of intptr_t vs uintptr_t (I think most uses of intptr_t should probably use uintptr_t).

• I got tired of casting constness away from to-be-printed memory range just to be able to feed an address to os::print_hex_dump. The content printed is usually const. os::print_hex_dump does not need non-constness, but since we use address, and address is typedef char*, and one cannot declare a typedef'ed pointer target-const, the issue is there. I therefore changed the input to const uint8_t*. Maybe we need a const_address or something similar.

---

Ran tests on Linux x64 and x86, Windows x86 and Mac aarch64. Fixed all issues I found. Only little-endian, I don't have big-endian machines and therefore made those changes blindly. Any maintainers of big-endian platforms should either test this or trust me.

---

Progress

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

Issue

• JDK-8334738: os::print_hex_dump should optionally print ASCII (Enhancement - P4)

Reviewers

• David Holmes (@dholmes-ora - Reviewer)
• Severin Gehwolf (@jerboaa - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19835

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper[bot]]

:wave: Welcome back stuefe! 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[bot]]

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

8334738: os::print_hex_dump should optionally print ASCII

Reviewed-by: dholmes, sgehwolf

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

• 9a91865ff38f6fbb48b9aba5028e0b529d9bce76: 8335395: G1: Verification does not detect references into Free regions
• 13b782c3de9a470a7cf1db9d5111ce19faf28729: 8334554: RISC-V: verify & fix perf of string comparison
• 8aaec37ace102b55ee1387cfd1967ec3ab662083: 8322475: Extend printing for System.map
• 19a8a2baa9e749c7527ff526b2794826f0cdebb3: 8335618: Serial: Remove unused definitions in SerialHeap
• cf4f2b53d6174a808f8b45f0bb848efd5bd91c3c: 8332517: G1: Refactor G1AllocRegion
• 5a8af2b8b93672de9b3a3e73e6984506980da932: 8335615: Clean up left-overs from 8317721
• 6923a5114b2a9f02f0d6f0fefc21141ac3b9322a: 8335607: Serial: Remove unused collection_attempt_is_safe
• 5866b16dbca3f63770c8792d204dabdf49b59839: 8335411: RISC-V: Optimize encode_heap_oop when oop is not null
• 6db4c6a772df856fc3099c32a5b2c102a30d360c: 8335536: Fix assertion failure in IdealGraphPrinter when append is true
• 350f9c1947b0eab3ee233516ceefca1e25de9583: 8322812: Manpage for jcmd is missing JFR.view command
• ... and 159 more: https://git.openjdk.org/jdk/compare/c6f3bf4bd61405c2ed374b15ef82cc987f52cd52...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[bot]]

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

• hotspot
• shenandoah

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.

[tstuefe]

/label remove shenandoah

[openjdk[bot]]

@tstuefe The shenandoah label was successfully removed.

[mlbridge[bot]]

Webrevs

• 02: Full - Incremental (ad4646b3)
• 01: Full - Incremental (648c4d4f)
• 00: Full (17e4ce2a)

[tstuefe]

I got tired of casting constness away from to-be-printed memory range just to be able to feed an address to os::print_hex_dump.

I don't follow - you didn't change/add any callsites so why would you need to cast away constness to "feed" the existing call ??

Mostly in tests. I rewrote them several times, one version was fed from const memory.

If this aspect turns out to be contentious, I'll revert it. I still think this function should accept const pointers as input.

I chose uint8_t since it seemed to me the closest const version of address. address, however, is signed char, but I did not want to pass const char* since that looks like a string.

I can use unsigned char*, sure. Or, maybe just const void*. Both are fine to me.

More comments below.

I like the idea in general.

[tstuefe]

Hi @dholmes-ora, thanks for your review!

I hopefully addressed all your concerns. In particular:

• I now rely on true for the default of print_ascii, and rolled back changes to all callsites that explicitly passed true. I also decorated the parameters with comments
• I changed read_safely_from to take an uintptr_t* pointer. I would like to retain the signed->unsigned change, otherwise I would have to cast more in the 32-bit path.
• I introduced a new const_address typedef to complement the ubiquitous address. If we have one, we should have the other.
• I now use a dot instead of an underscore for unprintable data. This seems to be the default most hex editors use.

[tstuefe]

I chose uint8_t since it seemed to me the closest const version of address. address, however, is signed char, but I did not want to pass const char* since that looks like a string.

I was mistaken here, address is an unsigned char*.

[tstuefe]

Okay - seems reasonable.

FYI I am away for a few days.

Thanks

Many thanks, David, and have a nice time.

[tstuefe]

Many thanks, @jerboaa !

/integrate

[openjdk[bot]]

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

• 7b894bc4afa96bc04f0d58042f69becadb573e20: 8332786: When dumping static CDS archives, explicitly assert that we don't use a CDS archive
• e01626cf09850f7b0af33cdb905ca8992266fe5b: 8335655: ProblemList serviceability/dcmd/vm tests failing after JDK-8322475
• 3efa93ba1307cedf05609c0c04b2ba986a515f6e: 8335588: Fix -Wzero-as-null-pointer-constant warnings in calls to Node ctor
• 587535c5b9bb258836b47c3a8c41ffb91bbfc131: 8334545: runtime/ClassInitErrors/TestStackOverflowDuringInit.java fails after JDK-8294960
• 68ffec9800b798927a050900a2d47000aa18ef30: 8335479: JFR: Missing documentation for -XX:StartFlightRecording
• 9a91865ff38f6fbb48b9aba5028e0b529d9bce76: 8335395: G1: Verification does not detect references into Free regions
• 13b782c3de9a470a7cf1db9d5111ce19faf28729: 8334554: RISC-V: verify & fix perf of string comparison
• 8aaec37ace102b55ee1387cfd1967ec3ab662083: 8322475: Extend printing for System.map
• 19a8a2baa9e749c7527ff526b2794826f0cdebb3: 8335618: Serial: Remove unused definitions in SerialHeap
• cf4f2b53d6174a808f8b45f0bb848efd5bd91c3c: 8332517: G1: Refactor G1AllocRegion
• ... and 164 more: https://git.openjdk.org/jdk/compare/c6f3bf4bd61405c2ed374b15ef82cc987f52cd52...master

Your commit was automatically rebased without conflicts.

[openjdk[bot]]

@tstuefe Pushed as commit 38a578d547f39c3637d97f5e0242f4a69f3bbb31.

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

[tstuefe]

/backport jdk21u-dev

[openjdk[bot]]

@tstuefe Could not automatically backport 38a578d5 to openjdk/jdk21u-dev due to conflicts in the following files:

• src/hotspot/share/runtime/os.cpp
• src/hotspot/share/utilities/globalDefinitions.hpp
• test/hotspot/gtest/runtime/test_os.cpp

Please fetch the appropriate branch/commit and manually resolve these conflicts by using the following commands in your personal fork of openjdk/jdk21u-dev. Note: these commands are just some suggestions and you can use other equivalent commands you know.

# Fetch the up-to-date version of the target branch
$ git fetch --no-tags https://git.openjdk.org/jdk21u-dev.git master:master

# Check out the target branch and create your own branch to backport
$ git checkout master
$ git checkout -b backport-tstuefe-38a578d5-master

# Fetch the commit you want to backport
$ git fetch --no-tags https://git.openjdk.org/jdk.git 38a578d547f39c3637d97f5e0242f4a69f3bbb31

# Backport the commit
$ git cherry-pick --no-commit 38a578d547f39c3637d97f5e0242f4a69f3bbb31
# Resolve conflicts now

# Commit the files you have modified
$ git add files/with/resolved/conflicts
$ git commit -m 'Backport 38a578d547f39c3637d97f5e0242f4a69f3bbb31'

Once you have resolved the conflicts as explained above continue with creating a pull request towards the openjdk/jdk21u-dev with the title Backport 38a578d547f39c3637d97f5e0242f4a69f3bbb31.

Below you can find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 38a578d5 from the openjdk/jdk repository.

The commit being backported was authored by Thomas Stuefe on 4 Jul 2024 and was reviewed by David Holmes and Severin Gehwolf.

Thanks!

[offamitkumar]

Hi @tstuefe,

GTestWrapper.java is failing on s390x, after this commit, consistently. I have opened JDK-8335906.