On Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou <jian...@openjdk.org> wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Also update build to link properly > > I compared the extracted changes in this PR with the related parts in > https://github.com/openjdk/jdk/pull/19478. They look ok. My concern (as > discussed in > https://github.com/openjdk/jdk/pull/19478#issuecomment-2278421931) is that > these runtime changes for static JDK can't be tested even they are relatively > simple, without the the actual linking change. Any timeline for the static > linking changes? > @jianglizhou > > > [...] these runtime changes for static JDK can't be tested [...] > > Yes, they can. This is just a pure refactoring of existing code. I have > deliberately kept out addition of the new places where static linking > exceptions are needed in the code. Hi @magicus, perhaps the answer is both `yes` and `no`. Since your `src/hotspot/share/runtime/linkType.cpp` change removes the needs of requiring `#ifdef STATIC_BUILD` macro from various affected JDK source files to handle the differences between dynamic linking and static linking. From that sense, it's probably `yes` (can be tested as before) as `linkType.cpp` still uses `#ifdef STATIC_BUILD`, and the dynamic v.s. static differences are still determined at build time and not at runtime, as @dholmes-ora and @TheShermanTanker have pointed out. In theory, things (especially the dynamic case) could be tested as before since the fundamental is unchanged. That's different from the changes in https://github.com/openjdk/leyden/tree/hermetic-java-runtime, which does the actual runtime checks. Since the mainline doesn't have the needed build changes to have the ability to link a `javastatic` binary, from that point of view all the `static` cases in the PR cannot be tested yet. We could test them by integrating into https://github.com/openjdk/leyden/tree/hermetic-java-runtime and downstream codebase (with full hermetic Java support) after the PR is approved/submitted in the mainline. That might help. To ease some of @dholmes-ora's concern (and my concern as well) that the initial change could affect all Java instances, perhaps providing the build support for statically linking `javastatic` should be done as an immediate follow-up step (I'm continually nudging you toward that direction :-)). We have multiple goals to achieve in the build system for just the static-Java-only part and we probably want to consider adding the support in following sequence: 1) Capability of building a fully statically linked `javastatic` executable 2) Allow linking both `java` (with dynamic linking support) and `javatatic` using the same set of `.o` object files - Eliminate the needs of `#ifdef STATIC_BUILD` macro. Your `linkType.cpp` change seems to be able to limit the macro usage within one file and just conditionally compile the single file only. So that helps. - May involve spec changes for `JNI_OnLoad` and friends to use `JNI_OnLoad_<lib_name>` naming for dynamic linking support. The needed spec change for the static linking case (built in library support) has already been done in the past by others. 3) General solution for duplicating symbol issue - `objcopy` for symbol hiding ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2311351447
