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

[Jiangli Zhou]

On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@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.
>
> 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.

> Hi everyone! Sorry for the late reply, I've been ill for a while and have been working through my backlog.
> 
> I have independently been working on a solution to get the static JDK image to pass all JTReg tests. I have not created a JBS issue for it yet (before I prototyped this I was not sure it was a feasible way), but my current WIP branch is here: [master...magicus:jdk:add-static-relauncher](https://github.com/openjdk/jdk/compare/master...magicus:jdk:add-static-relauncher). I was just about to finish the last parts on it prior to falling ill.
> 
> In short, what we do in a normal JDK build when we create e.g. the `jar` tool is that we recompiled the `main.c` file making the launcher, but hard-coding the launcher to run the class `sun.tools.jar.Main`, using the JLI interface. In my branch, I instead create a trivial, stand-alone program (I call it a "relauncher") that will just re-execute the real `java` executable with the proper arguments to get it to run the class `sun.tools.jar.Main`. (There are some more subtleties surrounding doing this, but that is the gist of it.)
> 
> This way, we can have a single, statically linked `java` binary, but also have these tiny helper tools that just falls back on the static java. This will make a static JDK image behave indistinguishable from a normal JDK image, and thus being able to run all JTreg tests that require a tool to be present. Ideally, I'd like for the static JDK image to be able to pass the JCK, so we can be sure it is fully up to par to a normal JDK image. (But I have not tried doing that yet.)
> 
> I cannot really say how my work relates to this PR. My initial reaction is that Jiangli's addition to the whitebox API to let tests know if they are run in a static context or not is sound. Which of the existing tests really will need this annotation in the end is perhaps less clear. But it will allow for tests to explicitly check stuff that might go wrong on a static build.

@magicus Thanks for the thoughts and looking into the jtreg testing as well. IIUC, you want to make the required tools (perhaps a selected set of tools) usable for the static JDK at runtime, so any tests using tools at runtime can still be tested on static JDK. That seems to be a good goal and worth investigation. Your approach with re-executing the `java` executable sounds very interesting.

Really like your thoughts on making the static JDK image to pass the JCK!

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

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