On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou <jian...@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
