RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2]

[Jiangli Zhou]

On Wed, 14 May 2025 00:43:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> > The jdk/internal/misc/VM/RuntimeArguments.java test fails due the additional command-line option
>>> 
>>> Interesting and very frustrating. It seems there are potentially other flags that could get passed already that would cause the same kind of failure.
>>> 
>>> This really is not something that tests should need to be aware of. And to be honest the fact that -Dcompiler.jdk even exists and solves this problem is somewhat of a fortuitous accident (it was added way, way back to allow testing with JRE's that did not contain all the JDK tools).
>> 
>> Hmmm, I have a different thought now after processing more on the findings/discussions. `JDKToolFinder` provides following three different methods for accessing JDK tools either from `test.jdk` or `compile.jdk` specified paths. Jtreg tests using `JDKToolFinder` directly or indirectly should be aware of how/where tools are searched. 
>> 
>> getJDKTool(String)            // search `test.jdk` first then fall back to `compile.jdk`
>> getCompileJDKTool(String) // search `compile.jdk`
>> getTestJDKTool(String) // search `test.jdk`
>> 
>> 
>> Generally tests don't need to provide `test.jdk` & `compile.jdk` settings when using `JDKToolFinder` since those are provided from the jtreg environment. The problem that we are facing are special cases where test-launched child processes require accessing JDK tools using `JDKToolFinder`. As the child processes don't automatically get the jtreg system properties, individual tests should pass  `test.jdk` & `compile.jdk` jtreg system properties to the child process if `JDKToolFinder` is used to locate JDK tools. In fact the three affected tests already pass the `test.jdk` setting to the child process. It seems reasonable to also pass the additional `compile.jdk` value as long as there's no ill effect.
>> 
>>> 
>>> Doe a static JDK image not implicitly contain all the tools, if you invoked them directly rather than via their custom launchers? Or are they stripped out unless explicitly created as part of that image? I'm just wondering if there is a more direct way for JdkToolFinder to work with static images?
>> 
>> Currently the tools are not yet included in static-jdk, https://bugs.openjdk.org/browse/JDK-8346719 is going to include the tools (relauncher) in static-jdk.
>
>> As the child processes don't automatically get the jtreg system properties, individual tests should pass test.jdk & compile.jdk jtreg system properties to the child process if JDKToolFinder is used to locate JDK tools. In fact the three affected tests already pass the test.jdk setting to the child process. It seems reasonable to also pass the additional compile.jdk value as long as there's no ill effect.
> 
> Yes I agree, and I apologise for the unnecessary diversion from your original proposal. This isn't really about the static-image per-se but that code using JDKToolFinder must know that that the tool finder has been configured correctly, or else do that configuration itself.

Thanks, @dholmes-ora!

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

PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2880545389