RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors Execution

[David Holmes]

On Wed, 26 Feb 2025 14:17:31 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Currently, the test executes the program using `test.nativepath`, but it relies on path resolution. I propose following standard conventions in this case and running the test with the `/native` option instead.
> 
> With this change:
> - Path resolution is no longer required.
> - If `nativepath` is not specified at runtime, a standard error message will be printed to the console.
> 
> This improves consistency and simplifies the test execution process.
> 
> I kindly ask the original author of the test @swesonga and those who reviewed the original pull request  #17576 for this test to take a look at this PR: @jdksjolen and @dholmes

test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 34:

> 32:  * @library /test/lib
> 33:  * @compile GetAvailableProcessors.java
> 34:  * @run testng/othervm/native --enable-native-access=ALL-UNNAMED TestAvailableProcessors

It is a good catch that this test needs to declare it needs the native image to have been built - though `native` is not listed as a valid sub-option for `testng`. 

Why do you need the `--enable-native-access` here?

test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 171:

> 169:     @Test
> 170:     private static void testProcessorAvailability() throws IOException {
> 171:         // Launch "<nativepath>/GetProcessorInfo.exe" to gather processor counts

How does this launch the executable in the way you describe? I am not aware that the `native` directive puts the `<nativepath>` directory into the PATH. From what I can see from an existing jtr file the PATH used for executing the test is unchanged.  ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23803#discussion_r2020368426
PR Review Comment: https://git.openjdk.org/jdk/pull/23803#discussion_r2020369071