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

Jiangli Zhou jiangli at openjdk.org
Fri May 9 22:53:51 UTC 2025


On Fri, 9 May 2025 05:14:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed?
> 
> I agree, this feels like the wrong place for this kind of logic. The tests should not have to care whether they run on a static JDK.

@dholmes-ora @tstuefe Thanks for looking at this. Setting up the `-Dtest.jdk` and `-Dcompile.jdk` in `ProcessTools` seems reasonable on the first thought. I went ahead and changed to move setting `-Dtest.jdk` and `-Dcompile.jdk` into `ProcessTools.createJavaProcessBuilder()`, in my local branch. All three tests pass on static-jdk in my local testing, without explicitly setting `-Dtest.jdk` and `-Dcompile.jdk` in test code when launching child process. However, thinking more on this I realize that some tests may want to set to a different `test.jdk` or `compile.jdk` intentionally, and we need to be careful to not cause any unexpected side-effects. Of course, if we put `-Dtest.jdk=` and `-Dcompile.jdk=` command-line options immediately after the launcher (that's the case with my new local change), the settings from test can override the default settings in `ProcessTools.createJavaProcessBuilder()`. There would be no unexpected behavior. Any other thoughts, in case I missed something?

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

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


More information about the hotspot-runtime-dev mailing list