RFR: 8351851: Update PmemTest to run on AMD64

[Ivan Šipka]

On Wed, 16 Apr 2025 12:13:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> > It would be preferable if we retained the current test structure and swap
>>> > the x86_64 with amd64, as amd64 is the os.arch on which the test will be run
>>> 
>>> When I wrote my previous comment I was under the impression that `@requires(os.arch == "x86_64")` selects Intel x86 64-bit only while `@requires(os.arch == "amd64")` selects either Intel x86 64-bit or AMD x86 64-bit. However, having looked through the code in files:
>>> 
>>> ```
>>> test/jdk/jdk/internal/util/ArchTest.java
>>> src/java.base/share/classes/jdk/internal/util/Architecture.java
>>> src/java.base/share/classes/jdk/internal/util/PlatformProps.java
>>> /make/modules/java.base/gensrc/GensrcMisc.gmk
>>> ```
>>> 
>>> it appears to me that these two `@requires` clauses select the same thing i.e. either Intel x86 64-bit or AMD x86 64-bit. In which case the current config should mean that this test will run on AMD CPUs. Is that not the case?
>> 
>> Thanks for the details above. Currently the main linux execution platforms are returning "amd64" for the OS arch,  and that is not picked up by the current   @requires (os.arch == "x86_64")
>> to run on amd64 necessitates the removal of the @ignores directive 
>> so this is a pragmatic change to facilitate the manual execution of the most prevalent amd64 test environments.
>> 
>> It was observed that there might be a separate issue for jtreg on the @requires and
>> based on your feedback, and expectations there is a separate jtreg  issue to investigate the consistency of @requires on the os.arch attribute.
>
> @msheppar Thanks for clarifying what is at stake here. I am afraid don't know enough about the mechanics of the test infrastructure to explain why it is working the way you describe. However, given what you have observed I agree with your suggestion above that the right solution is to keep the two test declarations but switch "amd64" for "x86_64" and vice versa. That should make the tests work on amd64 CPUs while leaving it clear how anyone wanting to test on an alternative CPU would need to modify the test. I'll be happy to review the PR if it includes that change.

@adinn thank you for pointing out the additional relevant tests, the `test/jdk/jdk/internal/util/ArchTest.java` one is pure gold!

@msheppar the issue on @requires directive consistency was suspected until the following observation was made on a machine with Intel Core i9 CPU (which is clearly x86_64 ISA) :
     
     $dpkg --print-architecture
     amd64
     $gcc -dumpmachine
     x86_64-linux-gnu
     $uname -m
     x86_64
     $arch
     x86_64
     
To the best of my understanding the jtreg @requires directive is based on platform-dependent `System.getProperty("os.arch")` which is, I am speculating, populated via flags set in build time and by querying system calls during JVM startup.

Furthermore, [Oracle JDK releases for Linux](https://www.oracle.com/java/technologies/downloads/) list only `aarch64` and `x64`  ISA's.

Based on these facts (the architecture test and the releases) it is reasonable to conclude that `x86_64` and `amd64` are equivalent  - as far as the JDK VM scope is concerned - researching the topic seems to point that there still are some exotic differences but namely regarding virtualization.

Hence, in the general case any test that depends on the architecture should list `x86_64` and `amd64` together as it is uncertain (platform implementation dependent) what the exact string will be, e.g.:
   
      @requires ((os.arch == "x86_64")|(os.arch == "amd64"))

If we are aiming specifically for mentioned test enviroment it can be `amd64` as we _know_ that is what is returned.

In the case we want to proceed with two test cases - I suggest to introduce human readable ids (jtreg @id tag) so that we dont see automatically assigned `#id0` and `#id1`.

Please advise.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2812620053