RFR: 8349620: Add VMProps for static JDK [v3]

[Jiangli Zhou]

On Wed, 19 Feb 2025 06:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
>
> On a more general note, is it a goal to have the static JDK build run against all these tests that are part of the JDK repo? Would that mean that a lot of these will have to start using `@requires` to accomodate this?

@jaikiran, thanks for taking a look!

> Hello Jiangli, the change to introduce a `@requires` property for identifying a static JDK looks OK to me.
> 
> > @requires !jdk.static is added in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip running the test on static JDK. This test uses bin/jlink, which is not provided on static JDK. There are other tests that require tools in bin/. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
> 
> This part however feels odd. Updating this (and other tests in future) to use the `@requires !jdk.static` to identify the presence or absence of a specific tool in the JDK installation doesn't seem right. Perhaps they should instead rely on a tool-specific property (like maybe `@requires jdk.tool.jlink`)?

Here is some additional context. I picked `ModulesSymLink.java` rather randomly from the hotspot tier1 test failures caused by missing `bin/` tools. I included it in the current change for testing the `@requires !jdk.static` property. There are about 30 test failures in hotspot tier1 due to missing `bin/` tools, those tests execute `bin/jlink`, `bin/jcmd`, `bin/jstat`, `bin/javac`, or etc at runtime. `ModulesSymLink.constructTestJDK()` specifically runs the `jlink` tool  to create a test JDK during test execution. Since the `static-jdk` binary only provides a `bin/java` (and no other executables in `bin`), tests run any other tools at runtime in `bin/` fail. The current main issue with tools is that they require the shared libraries from JDK, for example `libjli.so`. Using a tool-specific property can be appropriate if we decide to support a specific set of tools for `static-jdk`, e.g. create a fully statically linked executable for supported tools, or including the tools required `.
 so` shared libraries in `static-jdk` image. Those details need to be discussed and worked out, we can add more fine grained properties when things are clear.

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

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2669442221