RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]

Kerem Kat krk at openjdk.org
Tue Oct 21 14:56:45 UTC 2025


On Fri, 17 Oct 2025 01:11:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.hotspot.agent/doc/clhsdb.html line 35:
>> 
>>> 33:   classes <font color="red">print all loaded Java classes with Klass*</font>
>>> 34:   detach <font color="red">detach SA from current target</font>
>>> 35:   dis address [ length ]  <font color="red">disassemble (amd64) specified number of instructions from given address</font>
>> 
>> Two issues here. The first is I think this was previously incorrect in that SA supports any architecture for which it can find the hsdis library. You can probably just drop the amd64 reference or add "requires hsdis".
>> 
>> The 2nd issue is with amd64 vs x86_64. It seems in SA the two basically have the same meaning, and you see a lot of C code that checks for both. However, the java code seems to always just reference AMD64 (but also works with x86_64). I'm just wondering if this is consistent with the rest of hotspot, or if we should consider a rename to x86_64 instead of amd64.
>> 
>> BTW, at the platform level there are some amd64 vs x86_64 differences. The one I noted is that MacOSX is considered x86_64 and I think linux and windows are amd64. I'm not sure why, but I recently noted a test that had an @requires for `os.arch == "amd64"` and that kept is from running on macosx-x64 until the @requires was expanded to also allow for `os.arch == "x86_64"`.  You should take extra care to make sure that these changes work with all the x86_64, including macosx. I see some places in the C code where we check for both amd64 and x86_64 and some where we only check for amd64. Perhaps x86_64 is not used by SA for macosx.
>
> AMD64 is historical, it should all be changed to x86_64. The only place AMD64 is relevant is in actual AMD processor specific code.

Thanks for the reviews. 

I have updated the html to read "requires hsdis".

Regarding checking for `amd64` vs. `x86_64`, I found two cases where one of `x86_64` and `amd64` is checked but not the other:


test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeLongIdealizationTests.java
34: * @requires os.arch == "x86_64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")

test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeIntIdealizationTests.java
34: * @requires os.arch == "x86_64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")


I checked the C++ sources for `RotateLeftNode::Value` and `RotateLeftNode::Ideal`, I couldn't find any platform-specific logic that would justify excluding `amd64`. I have updated both tests to include `amd64` in their `@requires`.

Is there a specific `x86_64` vs. `amd64` check in C you would like to point out?

For the total annihilation of the `amd64` naming, I have cut an issue at [JDK-8370339](https://bugs.openjdk.org/browse/JDK-8370339).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2448649698


More information about the serviceability-dev mailing list