From david.holmes at oracle.com Mon Jun 2 02:55:36 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 2 Jun 2025 12:55:36 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> Message-ID: <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> On 31/05/2025 7:20 am, Jiangli Zhou wrote: > On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: >> >> On 30/05/2025 9:26 am, Jiangli Zhou wrote: >>> >>> I just thought of one more thing related to the discussion now. Any >>> concern if the implementation does not ignore JNI_OnLoad_L and etc if >>> they are defined application's dynamically linked native libraries? Or >>> that's unspecified behavior and it's up to the implement to decide? >> >> For Internal libraries or external? For external you have to follow the >> spec - if both methods exist you only want to execute one of them. > > It's for the external (non-JDK) library that I'm a bit more cautious. > > In the existing code in JDK mainline, > https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, > loadLibrary() first tries to find the built-in library using > JNI_OnLoad_L symbol (L is the library name). When dlsym is called to > find the symbol from the main process, any of the already loaded > shared libraries are also searched, as described by the dlsym man page > (included related part below). > > https://man7.org/linux/man-pages/man3/dlsym.3.html: > RTLD_DEFAULT > Find the first occurrence of the desired symbol using the > default shared object search order. The search will > include global symbols in the executable and its > dependencies, as well as symbols in shared objects that > were dynamically loaded with the RTLD_GLOBAL flag. > > I think it would be rare, it is possible to construct such case: > > There are user JNI libraries A and B, with B is built as a dependency > of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B > and JNI_OnLoad. When A is being loaded using loadLibrary(), > loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. > A is then loaded dynamically, which causes B being loaded implicitly > as a dependency of A. Later when loadLibrary() is called for B, > JNI_OnLoad_B would be found and then called. This is an existing > behavior. I think it's an unspecified behavior and we don't need to > add any additional checks to prevent JNI_OnLoad_B from being called. That sounds like a significant design flaw to me. You can't specify that JNI_OnLoad_L will only be called if L is statically linked, if the existence of JNI_OnLoad_L is used to infer that L is statically linked! I would expect libraries to have both versions of the OnLoad functions to allow for them being statically or dynamically linked - which the spec allows for by saying the alternate variant is ignored. But then the JDK will execute the wrong method if it finds JNI_OnLoad_L in a dynamically linked library. David ----- > Thanks, > Jiangli > >> >> David >> ----- >> >>> Thanks! >>> Jiangli >>>> >>>> David >>>> >>>>> Best, >>>>> Jiangli >>>>> >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> From JNI spec [3]: >>>>>>> >>>>>>> - JNI_OnLoad/JNI_OnUnload >>>>>>> Optional function defined by dynamically linked libraries. >>>>>>> >>>>>>> LINKAGE: >>>>>>> Exported from dynamically linked native libraries that contain >>>>>>> native method implementations. >>>>>>> >>>>>>> - JNI_OnLoad_L >>>>>>> Mandatory function that must be defined by statically linked libraries . >>>>>>> >>>>>>> LINKAGE: >>>>>>> Exported from statically linked native libraries that contain native >>>>>>> method implementations. >>>>>>> >>>>>>> - JNI_OnUnload_L >>>>>>> Optional function defined by statically linked libraries. >>>>>>> >>>>>>> From JVMTI spec [4]: >>>>>>> >>>>>>> An agent L whose image has been combined with the VM is defined as >>>>>>> statically linked if and only if the agent exports a function called >>>>>>> Agent_OnLoad_L. >>>>>>> >>>>>>> [1]: https://bugs.openjdk.org/browse/JDK-8350450 >>>>>>> [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>>>> [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ >>>>>>> [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html >>>>>>> >>>>>>> Best, >>>>>>> Jiangli >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. >>>>>>>>> >>>>>>>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. >>>>>>>> >>>>>>>> Thank you for taking this on! Potentially we could consider taking the >>>>>>>> objcopy to localizing hotspot symbols on unix-like platforms, based on >>>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. Additional >>>>>>>> testing is still needed to verify the solution. >>>>>>>> >>>>>>>>> >>>>>>>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. >>>>>>>> >>>>>>>> Most of the JDK resources are now supported as hermetic jimage >>>>>>>> (lib/modules) bundled in the >>>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. >>>>>>>> The remaining sound.properties, ct.sym and .jfc files can be handled >>>>>>>> later. Overally, that part of the work has confirmed the hermetic >>>>>>>> jimage bundled solution is robust and helps resolve some of the >>>>>>>> difficult start-up sequence issues observed when the hermetic resource >>>>>>>> was implemented using JAR file based solution. >>>>>>>> >>>>>>>> It might be a good idea to follow up on the static linking discussion >>>>>>>> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Jiangli >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Jiangli >>>>>>>>> >>>>>>>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >>>>>>>>>> >>>>>>>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Magnus, >>>>>>>>>>> >>>>>>>>>>> Thanks for looking into this from the build perspective. >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> First some background for build-dev: I have spent some time looking at >>>>>>>>>>>> the build implications of the Hermetic Java effort, which is part of >>>>>>>>>>>> Project Leyden. A high-level overview is available here: >>>>>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source >>>>>>>>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. >>>>>>>>>>> >>>>>>>>>>> Some additional hermetic Java related references that are also useful: >>>>>>>>>>> >>>>>>>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >>>>>>>>>>> links to the issues for resolving static linking issues so far >>>>>>>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >>>>>>>>>>> building the complete set of static libraries in JDK/VM, particularly >>>>>>>>>>> including libjvm.a >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hermetic Java faces several challenges, but the part that is relevant >>>>>>>>>>>> for the build system is the ability to create static libraries. We've >>>>>>>>>>>> had this functionality (in three different ways...) for some time, but >>>>>>>>>>>> it is rather badly implemented. >>>>>>>>>>>> >>>>>>>>>>>> As a result of my investigations, I have a bunch of questions. :-) I >>>>>>>>>>>> have gotten some answers in private discussion, but for the sake of >>>>>>>>>>>> transparency I will repeat them here, to foster an open dialogue. >>>>>>>>>>>> >>>>>>>>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise >>>>>>>>>>>> is to be able to have jmods which include static libraries (*.a) of the >>>>>>>>>>>> native code which the module uses, and that the user can then run a >>>>>>>>>>>> special jlink command to have this linked into a single executable >>>>>>>>>>>> binary (which also bundles the *.class files and any additional >>>>>>>>>>>> resources needed)? >>>>>>>>>>>> >>>>>>>>>>>> 2. If so, is the idea to create special kinds of static jmods, like >>>>>>>>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? >>>>>>>>>>>> Or is the idea that the normal jmod should contain both? >>>>>>>>>>>> >>>>>>>>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is >>>>>>>>>>>> the intention to have jlink call a system-provided ld, or to bundle ld >>>>>>>>>>>> with jlink, or to reimplement this functionality in Java? >>>>>>>>>>> >>>>>>>>>>> I have a similar view as Alan responded in your other email thread. >>>>>>>>>>> Things are still in the early stage for the general solution. >>>>>>>>>>> >>>>>>>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>>>>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK >>>>>>>>>>> binary contains the following extra artifacts: >>>>>>>>>>> >>>>>>>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries >>>>>>>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked >>>>>>>>>>> with the selected JDK .a libraries (e.g. it currently statically link >>>>>>>>>>> with the headless) and libjvm.a. It's the standard Java launcher >>>>>>>>>>> without additional work for hermetic Java. >>>>>>>>>>> >>>>>>>>>>> In our prototype for hermetic Java, we build the hermetic executable >>>>>>>>>>> image (a single image) from the following input (see description on >>>>>>>>>>> singlejar packaging tool in >>>>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >>>>>>>>>>> >>>>>>>>>>> - A customized launcher (with additional work for hermetic) executable >>>>>>>>>>> fully statically linked with JDK/VM static libraries (.a files), >>>>>>>>>>> application natives and dependencies (e.g. in .a static libraries) >>>>>>>>>>> - JDK lib/modules, JDK resource files >>>>>>>>>>> - Application classes and resource files >>>>>>>>>>> >>>>>>>>>>> Including a JDK library .a into the corresponding .jmod would require >>>>>>>>>>> extracting the .a for linking with the executable. In some systems >>>>>>>>>>> that may cause memory overhead due to the extracted copy of the .a >>>>>>>>>>> files. I think we should consider the memory overhead issue. >>>>>>>>>>> >>>>>>>>>>> One possibility (as Alan described in his response) is for jlink to >>>>>>>>>>> invoke the ld on the build system. jlink could pass the needed JDK >>>>>>>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to >>>>>>>>>>> ld based on the modules required for the application. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it >>>>>>>>>> would need to know the complete linker options and inputs. Those >>>>>>>>>> include options and inputs related to the application part as well. In >>>>>>>>>> some usages, it might be easier to handle native linking separately >>>>>>>>>> and pass the linker output, the executable to jlink directly. Maybe we >>>>>>>>>> could consider supporting different modes for various usages >>>>>>>>>> requirements, from static libraries and native linking point of view: >>>>>>>>>> >>>>>>>>>> Mode #1 >>>>>>>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a >>>>>>>>>> and application natives and dependencies. If the inputs to jlink >>>>>>>>>> include .jmods, jlink can extract the .a libraries and pass the >>>>>>>>>> information to ld to link the executable. >>>>>>>>>> >>>>>>>>>> Mode #2 >>>>>>>>>> Support separate .a as jlink input. Jlink could pass the path >>>>>>>>>> information to the .a libraries and other linker options to ld to >>>>>>>>>> create the executable. >>>>>>>>>> >>>>>>>>>> For both mode #1 and #2, jlink would then use the linker output >>>>>>>>>> executable to create the final hermetic image. >>>>>>>>>> >>>>>>>>>> Mode #3 >>>>>>>>>> Support a fully linked executable as a jlink input. When a linked >>>>>>>>>> executable is given to jlink, it can process it directly with other >>>>>>>>>> JDK data/files to create the final image, without native linking step. >>>>>>>>>> >>>>>>>>>> Any other thoughts and considerations? >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Jiangli >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 4. Is the intention is to allow users to create their own jmods with >>>>>>>>>>>> static libraries, and have these linked in as well? This seems to be the >>>>>>>>>>>> case. >>>>>>>>>>> >>>>>>>>>>> An alternative with less memory overhead could be using application >>>>>>>>>>> modular JAR and separate .a as the input for jlink. >>>>>>>>>>> >>>>>>>>>>>> If that is so, then there will always be the risk for name >>>>>>>>>>>> collisions, and we can only minimize the risk by making sure any global >>>>>>>>>>>> names are as unique as possible. >>>>>>>>>>> >>>>>>>>>>> Part of the current effort includes resolving the discovered symbol >>>>>>>>>>> collision issues with static linking. Will respond to your other email >>>>>>>>>>> on the symbol issue separately later. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5. The original implementation of static builds in the JDK, created for >>>>>>>>>>>> the Mobile project, used a configure flag, --enable-static-builds, to >>>>>>>>>>>> change the entire behavior of the build system to only produce *.a files >>>>>>>>>>>> instead of lib*.so. In contrast, the current system is using a special >>>>>>>>>>>> target instead. >>>>>>>>>>> >>>>>>>>>>> I think we would need both configure flag and special target for the >>>>>>>>>>> static builds. >>>>>>>>>>> >>>>>>>>>>>> In my eyes, this is a much worse solution. Apart from >>>>>>>>>>>> the conceptual principle (if the build should generate static or dynamic >>>>>>>>>>>> libraries is definitely a property of what a "configuration" means), >>>>>>>>>>>> this makes it much harder to implement efficiently, since we cannot make >>>>>>>>>>>> changes in NativeCompilation.gmk, where they are needed. >>>>>>>>>>> >>>>>>>>>>> For the potential objcopy work to resolve symbol issues, we can add >>>>>>>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >>>>>>>>>>> have an internal prototype (not included in >>>>>>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >>>>>>>>>>> by one of colleagues for localizing symbols in libfreetype using >>>>>>>>>>> objcopy. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That was not as much a question as a statement. ? But here is the >>>>>>>>>>>> question: Do you think it would be reasonable to restore the old >>>>>>>>>>>> behavior but with the new methods, so that we don't use special targets, >>>>>>>>>>>> but instead tells configure to generate static libraries? I'm thinking >>>>>>>>>>>> we should have a flag like "--with-library-type=" that can have values >>>>>>>>>>>> "dynamic" (which is default), "static" or "both". >>>>>>>>>>> >>>>>>>>>>> If we want to also build a fully statically linked launcher, maybe >>>>>>>>>>> --with-static-java? Being able to configure either dynamic, static or >>>>>>>>>>> both as you suggested also seems to be a good idea. >>>>>>>>>>> >>>>>>>>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files >>>>>>>>>>>> into a single jmod file (see question 2 above), then it definitely is. >>>>>>>>>>>> In general, the cost of producing two kinds of libraries are quite >>>>>>>>>>>> small, compared to the cost of compiling the source code to object files. >>>>>>>>>>> >>>>>>>>>>> Completely agree. It would be good to avoid recompiling the .o file >>>>>>>>>>> for static and dynamic builds. As proposed in >>>>>>>>>>> https://bugs.openjdk.org/browse/JDK-8303796: >>>>>>>>>>> >>>>>>>>>>> It's beneficial to be able to build both .so and .a from the same set >>>>>>>>>>> of .o files. That would involve some changes to handle the dynamic JDK >>>>>>>>>>> and static JDK difference at runtime, instead of relying on the >>>>>>>>>>> STATIC_BUILD macro. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Finally, I have looked at how to manipulate symbol visibility. There >>>>>>>>>>>> seems many ways forward, so I feel confident that we can find a good >>>>>>>>>>>> solution. >>>>>>>>>>>> >>>>>>>>>>>> One way forward is to use objcopy to manipulate symbol status >>>>>>>>>>>> (global/local). There is an option --localize-symbol in objcopy, that >>>>>>>>>>>> has been available in objcopy since at least 2.15, which was released >>>>>>>>>>>> 2004, so it should be safe to use. But ideally we should avoid using >>>>>>>>>>>> objcopy and do this as part of the linking process. This should be >>>>>>>>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- >>>>>>>>>>>> see question 5 above. >>>>>>>>>>>> >>>>>>>>>>>> As a fallback, it is also possible to rename symbols, either piecewise >>>>>>>>>>>> or wholesale, using objcopy. There are many ways to do this, using >>>>>>>>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this >>>>>>>>>>>> takes a file with a list of symbols). Thus we can always introduce a >>>>>>>>>>>> "post factum namespace" by renaming symbols. >>>>>>>>>>> >>>>>>>>>>> Renaming or redefining the symbol at build time could cause confusions >>>>>>>>>>> with debugging. That's a concern raised in >>>>>>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. >>>>>>>>>>> >>>>>>>>>>> Additionally, redefining symbols using tools like objcopy may not >>>>>>>>>>> handle member names referenced in string literals. For example, in >>>>>>>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are >>>>>>>>>>> needed in assembling and SA to reflect the symbol change. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So in the end, I think it will be fully possible to produce .a files >>>>>>>>>>>> that only has global symbols for the functions that are part of the API >>>>>>>>>>>> exposed by that library, and have all other symbols local, and make this >>>>>>>>>>>> is in a way that is consistent with the rest of the build system. >>>>>>>>>>>> >>>>>>>>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export >>>>>>>>>>>> basically all symbols in hotspot as global. This is not reasonable to do >>>>>>>>>>>> for a static build. The effect of not exporting those symbols will be >>>>>>>>>>>> that SA will not function to 100%. On the other hand, I have no idea if >>>>>>>>>>>> SA works at all with a static build. Have you tested this? Is this part >>>>>>>>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? >>>>>>>>>>> >>>>>>>>>>> We have done some testing with jtreg SA related tests for the fully >>>>>>>>>>> statically linked `javastatic`. >>>>>>>>>>> >>>>>>>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear >>>>>>>>>>> what's the impact on SA. We could do some tests. The other question >>>>>>>>>>> that I raised is the supported gcc versions (for partial linking) >>>>>>>>>>> related to the solution. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Jiangli >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>>>>>>>>>> >>>>>> >>>> >> From kbarrett at openjdk.org Mon Jun 2 03:48:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 2 Jun 2025 03:48:42 GMT Subject: RFR: 8358284: doc/testing.html is not up to date after JDK-8355003 Message-ID: Please review this trivial change to doc/testing.html, to bring it up to date with the associated source file doc/testing.md. The change was produced by running `make update-build-docs` in an up-to-date local repository. ------------- Commit messages: - update testing.html Changes: https://git.openjdk.org/jdk/pull/25573/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25573&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358284 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25573.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25573/head:pull/25573 PR: https://git.openjdk.org/jdk/pull/25573 From jwaters at openjdk.org Mon Jun 2 06:29:50 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 2 Jun 2025 06:29:50 GMT Subject: RFR: 8358284: doc/testing.html is not up to date after JDK-8355003 In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 03:43:06 GMT, Kim Barrett wrote: > Please review this trivial change to doc/testing.html, to bring it up to date > with the associated source file doc/testing.md. The change was produced by > running `make update-build-docs` in an up-to-date local repository. Looks good ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/25573#pullrequestreview-2886931921 From dholmes at openjdk.org Mon Jun 2 06:33:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Jun 2025 06:33:51 GMT Subject: RFR: 8358284: doc/testing.html is not up to date after JDK-8355003 In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 03:43:06 GMT, Kim Barrett wrote: > Please review this trivial change to doc/testing.html, to bring it up to date > with the associated source file doc/testing.md. The change was produced by > running `make update-build-docs` in an up-to-date local repository. Seems okay. Thanks for fixing. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25573#pullrequestreview-2886939718 From kbarrett at openjdk.org Mon Jun 2 07:26:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 2 Jun 2025 07:26:55 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Fri, 30 May 2025 20:58:55 GMT, Erik Gahlin wrote: > > Why would you want to do that? > > To see what I couldn't merge or apply without a conflict. +1 I think I hate this change. I just wasted some time on that very problem. If those files exist, they are interesting. They just shouldn't be committed. This change treats them as uninteresting. I don't know what a better solution is, as I'm not a git (or perhaps jcheck?) expert. But something that only prevents committing would be very much better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2929188824 From vyazici at openjdk.org Mon Jun 2 11:25:30 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 2 Jun 2025 11:25:30 GMT Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [build/tools] [v2] In-Reply-To: References: Message-ID: <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com> > Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. > > `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to build and tools. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Provide fallback for `stdin.encoding` in `ExternalEditor` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25541/files - new: https://git.openjdk.org/jdk/pull/25541/files/329180f5..c0dfa806 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25541&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25541&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25541.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25541/head:pull/25541 PR: https://git.openjdk.org/jdk/pull/25541 From vyazici at openjdk.org Mon Jun 2 11:25:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 2 Jun 2025 11:25:31 GMT Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [build/tools] [v2] In-Reply-To: <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com> References: <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com> Message-ID: On Mon, 2 Jun 2025 11:22:21 GMT, Volkan Yazici wrote: >> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. >> >> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to build and tools. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Provide fallback for `stdin.encoding` in `ExternalEditor` src/utils/src/build/tools/commentchecker/CommentChecker.java line 197: > 195: try { > 196: BufferedReader br = > 197: new BufferedReader(new InputStreamReader(System.in, System.getProperty("stdin.encoding"))); Not providing a `Charset` fallback ? `CommentChecker` build tool should better fail if an invalid `stdin.encoding` is configured. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25541#discussion_r2120845904 From erikj at openjdk.org Mon Jun 2 12:59:51 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 2 Jun 2025 12:59:51 GMT Subject: RFR: 8358284: doc/testing.html is not up to date after JDK-8355003 In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 03:43:06 GMT, Kim Barrett wrote: > Please review this trivial change to doc/testing.html, to bring it up to date > with the associated source file doc/testing.md. The change was produced by > running `make update-build-docs` in an up-to-date local repository. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25573#pullrequestreview-2888293004 From nbenalla at openjdk.org Mon Jun 2 14:46:15 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 2 Jun 2025 14:46:15 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Revert "feedback: never bump ASM version" This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=05 Stats: 1824 lines in 59 files changed: 1734 ins; 16 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Mon Jun 2 14:52:55 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 2 Jun 2025 14:52:55 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b I have bumped the ASM version in [0dbdde7](https://github.com/openjdk/jdk/pull/25008/commits/0dbdde7bf6a0343acca74b284a8114c60919dd25) because various HotSpot tests use ASM fail under JDK 26 without this change. This can be rolled back later after [JDK-8356548](https://bugs.openjdk.org/browse/JDK-8356548) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931105555 From nbenalla at openjdk.org Mon Jun 2 15:05:54 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 2 Jun 2025 15:05:54 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: <-CUDiWjPLN2ywVxx5RQWUpmsjgkPLb0AmtnLi3MACP4=.d2aebd91-1220-4a2a-acf2-fb3dc953d908@github.com> On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b There were no API changes in JDK 25 build 25. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931159736 From ihse at openjdk.org Mon Jun 2 16:00:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 16:00:55 GMT Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version In-Reply-To: References: Message-ID: On Wed, 28 May 2025 14:24:47 GMT, Doug Simon wrote: > There are plans to have libgraal be built for JDK master using a version of Native Image running on a JDK one version behind the current JDK. This Native Image execution needs to be able to load the JVMCI classes. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of the current JDK. I don't think this is a good way. We should not call to shell to make calculations in the makefiles; if that were needed, it should be done in configure. However, we are already doing this, or at least something very similar. Have a look at line 398 in boot-jdk.m4. We set up `OLDEST_BOOT_JDK` as the oldest JDK from the list in version-numbers.conf. That should, I think, match your expectation of N-1. There is always a bit uncertainty how you want these things to be handled around the version rollover, and I'm not sure about your use case in those situations. But in general, the oldest boot JDK will match the version number actually used in the build as the boot JDK, that is, N-1. Now, OLDEST_BOOT_JDK is not exported to make. But that is however: BOOT_JDK_SOURCETARGET="-source $OLDEST_BOOT_JDK -target $OLDEST_BOOT_JDK -Xlint:-options" which is almost, but not exactly, what you were planning to add. The added `-Xlint:-options` is harmless afaict, and I think was likely added at some point due to option mismatch between N and N-1 javac lint support, so I think it would make sense for you to use it as well. So, in essense, my suggestion boils down to that you should only add `$(BOOT_JDK_SOURCETARGET)` to your command line. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25494#issuecomment-2931378030 From ihse at openjdk.org Mon Jun 2 16:48:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 16:48:04 GMT Subject: RFR: 8357991: make bootcycle-images is broken after JDK-8349665 Message-ID: `make bootcycle-images` broke after JDK-8349665, with the symptom: jdk.internal.md.interim/module-info.java:51: error: module not found: jdk.compiler.interim requires jdk.compiler.interim; This is since the bootcycle build use a special spec.gmk files which point to a special `make-support` directory, and this did not contain the necessary files needed to start running make targets. (Ever since JDK-8292944 they need to be explicitly generated.) ------------- Commit messages: - 8357991: make bootcycle-images is broken after JDK-8349665 Changes: https://git.openjdk.org/jdk/pull/25594/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25594&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357991 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25594/head:pull/25594 PR: https://git.openjdk.org/jdk/pull/25594 From shade at openjdk.org Mon Jun 2 16:48:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 16:48:05 GMT Subject: RFR: 8357991: make bootcycle-images is broken after JDK-8349665 In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:24:28 GMT, Magnus Ihse Bursie wrote: > `make bootcycle-images` broke after JDK-8349665, with the symptom: > > > jdk.internal.md.interim/module-info.java:51: error: module not found: jdk.compiler.interim > requires jdk.compiler.interim; > > > This is since the bootcycle build use a special spec.gmk files which point to a special `make-support` directory, and this did not contain the necessary files needed to start running make targets. (Ever since JDK-8292944 they need to be explicitly generated.) make/Main.gmk line 429: > 427: ( cd $(TOPDIR) && \ > 428: $(MAKE) $(MAKE_ARGS) -f make/GenerateFindTests.gmk \ > 429: SPEC=$(BOOTCYCLE_SPEC)) Indentation looks a bit off here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25594#discussion_r2121665021 From ihse at openjdk.org Mon Jun 2 16:48:05 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 16:48:05 GMT Subject: RFR: 8357991: make bootcycle-images is broken after JDK-8349665 In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:39:20 GMT, Aleksey Shipilev wrote: >> `make bootcycle-images` broke after JDK-8349665, with the symptom: >> >> >> jdk.internal.md.interim/module-info.java:51: error: module not found: jdk.compiler.interim >> requires jdk.compiler.interim; >> >> >> This is since the bootcycle build use a special spec.gmk files which point to a special `make-support` directory, and this did not contain the necessary files needed to start running make targets. (Ever since JDK-8292944 they need to be explicitly generated.) > > make/Main.gmk line 429: > >> 427: ( cd $(TOPDIR) && \ >> 428: $(MAKE) $(MAKE_ARGS) -f make/GenerateFindTests.gmk \ >> 429: SPEC=$(BOOTCYCLE_SPEC)) > > Indentation looks a bit off here. Yeah, it was completely borked. Not only was there an extra space here, but I did not realize the opening parenthesis should set the base indentation level. Fixed now, thanks for noticing! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25594#discussion_r2121678143 From erikj at openjdk.org Mon Jun 2 16:48:04 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 2 Jun 2025 16:48:04 GMT Subject: RFR: 8357991: make bootcycle-images is broken after JDK-8349665 In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:24:28 GMT, Magnus Ihse Bursie wrote: > `make bootcycle-images` broke after JDK-8349665, with the symptom: > > > jdk.internal.md.interim/module-info.java:51: error: module not found: jdk.compiler.interim > requires jdk.compiler.interim; > > > This is since the bootcycle build use a special spec.gmk files which point to a special `make-support` directory, and this did not contain the necessary files needed to start running make targets. (Ever since JDK-8292944 they need to be explicitly generated.) Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25594#pullrequestreview-2889170961 From ihse at openjdk.org Mon Jun 2 16:52:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 16:52:58 GMT Subject: Integrated: 8357991: make bootcycle-images is broken after JDK-8349665 In-Reply-To: References: Message-ID: <6MTFzLiPRSSKpX43sbteyB074nHVee4HYSwu9E843AE=.10526aab-7c6b-4407-aad0-95e2df77e743@github.com> On Mon, 2 Jun 2025 16:24:28 GMT, Magnus Ihse Bursie wrote: > `make bootcycle-images` broke after JDK-8349665, with the symptom: > > > jdk.internal.md.interim/module-info.java:51: error: module not found: jdk.compiler.interim > requires jdk.compiler.interim; > > > This is since the bootcycle build use a special spec.gmk files which point to a special `make-support` directory, and this did not contain the necessary files needed to start running make targets. (Ever since JDK-8292944 they need to be explicitly generated.) This pull request has now been integrated. Changeset: ab5de456 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/ab5de45636f0bf96e52c0ae0dcf080f279d9caee Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod 8357991: make bootcycle-images is broken after JDK-8349665 Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25594 From ihse at openjdk.org Mon Jun 2 16:56:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 16:56:01 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. I am open for reverting this if it causes trouble in established workflows. But the problem with committed .rej files is real too, and I'm not sure how to solve that without using .gitignore. I think we need to either: A) establish that this new behavior is much worse than the risk for integrating unwanted files (if so, we can just revert this), or B) find another solution that allows us to remove this change but still catch the unwanted .rej and .orig files. I don't have any good suggestions on B, and I am not sure how we could decide if A is applicable or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2931581297 From ihse at openjdk.org Mon Jun 2 16:57:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 16:57:03 GMT Subject: RFR: 8357991: make bootcycle-images is broken after JDK-8349665 In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:24:28 GMT, Magnus Ihse Bursie wrote: > `make bootcycle-images` broke after JDK-8349665, with the symptom: > > > jdk.internal.md.interim/module-info.java:51: error: module not found: jdk.compiler.interim > requires jdk.compiler.interim; > > > This is since the bootcycle build use a special spec.gmk files which point to a special `make-support` directory, and this did not contain the necessary files needed to start running make targets. (Ever since JDK-8292944 they need to be explicitly generated.) Oh crap. My push with the indentation fix did not go through, and I did not notice, so I was awaiting for a re-review with the additional commit. *sigh* I'll make a repair PR... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25594#issuecomment-2931587286 From dnsimon at openjdk.org Mon Jun 2 17:00:32 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 2 Jun 2025 17:00:32 GMT Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version [v2] In-Reply-To: References: Message-ID: > There are plans to have libgraal be built for JDK master using a version of Native Image running on a JDK one version behind the current JDK. This Native Image execution needs to be able to load the JVMCI classes. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of the current JDK. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: use BOOT_JDK_SOURCETARGET instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25494/files - new: https://git.openjdk.org/jdk/pull/25494/files/fb1adbe4..739c5fb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25494&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25494&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25494.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25494/head:pull/25494 PR: https://git.openjdk.org/jdk/pull/25494 From dnsimon at openjdk.org Mon Jun 2 17:00:32 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 2 Jun 2025 17:00:32 GMT Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version In-Reply-To: References: Message-ID: On Wed, 28 May 2025 14:24:47 GMT, Doug Simon wrote: > There are plans to have libgraal be built for JDK master using a version of Native Image running on a JDK one version behind the current JDK. This Native Image execution needs to be able to load the JVMCI classes. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of the current JDK. Thanks for the suggestion - I've applied it. I assume OLDEST_BOOT_JDK will always be at least one behind the current version so this looks future proof and should any manual adjustment during version rollover. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25494#issuecomment-2931601504 From erikj at openjdk.org Mon Jun 2 17:02:23 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 2 Jun 2025 17:02:23 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. This does seem like a reasonably easy check for jcheck to perform, at least in theory. It could be configured with a regex for file name patterns we don't want. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2931607074 From ihse at openjdk.org Mon Jun 2 17:03:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 17:03:55 GMT Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version [v2] In-Reply-To: References: Message-ID: <2ZR5m0TEgYENtJ5JCyyi0zHxgLnnJyxnAmTqYfOslHQ=.653828e1-08c2-4ed6-81ae-b6d6a9884d6e@github.com> On Mon, 2 Jun 2025 17:00:32 GMT, Doug Simon wrote: >> There are plans to have libgraal be built for JDK master using a version of Native Image running on a JDK one version behind the current JDK. This Native Image execution needs to be able to load the JVMCI classes. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of the current JDK. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > use BOOT_JDK_SOURCETARGET instead Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25494#pullrequestreview-2889271599 From ihse at openjdk.org Mon Jun 2 17:05:25 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 17:05:25 GMT Subject: RFR: 8358337: JDK-8357991 was committed with incorrect indentation Message-ID: Due to user error (I screwed up) the changes in indentation that was requested in the review was not included when the PR was integrated. ------------- Commit messages: - 8358337: JDK-8357991 was committed with incorrect indentation Changes: https://git.openjdk.org/jdk/pull/25595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25595&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358337 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25595/head:pull/25595 PR: https://git.openjdk.org/jdk/pull/25595 From shade at openjdk.org Mon Jun 2 17:09:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 17:09:54 GMT Subject: RFR: 8358337: JDK-8357991 was committed with incorrect indentation In-Reply-To: References: Message-ID: <6cLnhHDPu-13_ZRjyX4BT1v5Sigac-HkVJu2wMSd1m0=.71e91516-37ef-42ce-a4d7-3d8c0def1adc@github.com> On Mon, 2 Jun 2025 16:59:15 GMT, Magnus Ihse Bursie wrote: > Due to user error (I screwed up) the changes in indentation that was requested in the review was not included when the PR was integrated. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25595#pullrequestreview-2889283637 From ihse at openjdk.org Mon Jun 2 17:09:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Jun 2025 17:09:55 GMT Subject: Integrated: 8358337: JDK-8357991 was committed with incorrect indentation In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:59:15 GMT, Magnus Ihse Bursie wrote: > Due to user error (I screwed up) the changes in indentation that was requested in the review was not included when the PR was integrated. This pull request has now been integrated. Changeset: a7671e73 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a7671e7360ce23df9577110266e66a1c1a790196 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8358337: JDK-8357991 was committed with incorrect indentation Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/25595 From darcy at openjdk.org Mon Jun 2 17:23:52 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 2 Jun 2025 17:23:52 GMT Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 15:58:10 GMT, Magnus Ihse Bursie wrote: > I don't think this is a good way. We should not call to shell to make calculations in the makefiles; if that were needed, it should be done in configure. However, we are already doing this, or at least something very similar. Have a look at line 398 in boot-jdk.m4. We set up `OLDEST_BOOT_JDK` as the oldest JDK from the list in version-numbers.conf. > > That should, I think, match your expectation of N-1. There is always a bit uncertainty how you want these things to be handled around the version rollover, and I'm not sure about your use case in those situations. But in general, the oldest boot JDK will match the version number actually used in the build as the boot JDK, that is, N-1. > > Now, OLDEST_BOOT_JDK is not exported to make. But that is however: > > ``` > BOOT_JDK_SOURCETARGET="-source $OLDEST_BOOT_JDK -target $OLDEST_BOOT_JDK -Xlint:-options" > ``` > > which is almost, but not exactly, what you were planning to add. The added `-Xlint:-options` is harmless afaict, and I think was likely added at some point due to option mismatch between N and N-1 javac lint support, so I think it would make sense for you to use it as well. > > So, in essense, my suggestion boils down to that you should only add `$(BOOT_JDK_SOURCETARGET)` to your command line. I don't know the particulars here, but using `javac -source $OLD -target $OLD ..." is _almost_ never more appropriate than using `javac --release $OLD ..." The `options` warning would be noting the possible use of `--release`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25494#issuecomment-2931680491 From dnsimon at openjdk.org Mon Jun 2 19:38:50 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 2 Jun 2025 19:38:50 GMT Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version In-Reply-To: References: Message-ID: <3zZUXexKLHEJslvGrjgXjB3fRlCkaudK-viBPWY9HgQ=.72c614a0-9eaa-428d-9c78-30996de28753@github.com> On Mon, 2 Jun 2025 17:21:21 GMT, Joe Darcy wrote: > is _almost_ never more appropriate than using > > `javac --release $OLD ..." > > The `options` warning would be noting the possible use of `--release`. I wanted to use `--release` initially but it is not configurable in a module's `Java.gmk`. That is, TARGET_RELEASE is not supported in [CompileJavaModules.gmk](https://github.com/openjdk/jdk/blob/5243f3851b0345b874ff51ea3a07e82f73741546/make/CompileJavaModules.gmk#L101-L124). However, thinking this through a little more, we really do need something closer to `--release` for the use case behind this PR. I'll postpone working on this PR and try capture the requirements in more detail in [JDK-8357979](https://bugs.openjdk.org/browse/JDK-8357979). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25494#issuecomment-2932184001 From jianglizhou at google.com Mon Jun 2 23:29:34 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 2 Jun 2025 16:29:34 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> Message-ID: On Sun, Jun 1, 2025 at 7:55?PM David Holmes wrote: > > On 31/05/2025 7:20 am, Jiangli Zhou wrote: > > On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: > >> > >> On 30/05/2025 9:26 am, Jiangli Zhou wrote: > >>> > >>> I just thought of one more thing related to the discussion now. Any > >>> concern if the implementation does not ignore JNI_OnLoad_L and etc if > >>> they are defined application's dynamically linked native libraries? Or > >>> that's unspecified behavior and it's up to the implement to decide? > >> > >> For Internal libraries or external? For external you have to follow the > >> spec - if both methods exist you only want to execute one of them. > > > > It's for the external (non-JDK) library that I'm a bit more cautious. > > > > In the existing code in JDK mainline, > > https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, > > loadLibrary() first tries to find the built-in library using > > JNI_OnLoad_L symbol (L is the library name). When dlsym is called to > > find the symbol from the main process, any of the already loaded > > shared libraries are also searched, as described by the dlsym man page > > (included related part below). > > > > https://man7.org/linux/man-pages/man3/dlsym.3.html: > > RTLD_DEFAULT > > Find the first occurrence of the desired symbol using the > > default shared object search order. The search will > > include global symbols in the executable and its > > dependencies, as well as symbols in shared objects that > > were dynamically loaded with the RTLD_GLOBAL flag. > > > > I think it would be rare, it is possible to construct such case: > > > > There are user JNI libraries A and B, with B is built as a dependency > > of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B > > and JNI_OnLoad. When A is being loaded using loadLibrary(), > > loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. > > A is then loaded dynamically, which causes B being loaded implicitly > > as a dependency of A. Later when loadLibrary() is called for B, > > JNI_OnLoad_B would be found and then called. This is an existing > > behavior. I think it's an unspecified behavior and we don't need to > > add any additional checks to prevent JNI_OnLoad_B from being called. > > That sounds like a significant design flaw to me. You can't specify that > JNI_OnLoad_L will only be called if L is statically linked, if the > existence of JNI_OnLoad_L is used to infer that L is statically linked! > I would expect libraries to have both versions of the OnLoad functions > to allow for them being statically or dynamically linked - which the > spec allows for by saying the alternate variant is ignored. But then the > JDK will execute the wrong method if it finds JNI_OnLoad_L in a > dynamically linked library. JNI_OnLoad_L is used to determine if a requested JNI native library is a built-in (statically linked) library. Thus, it can avoid the operation of explicit loading for the shared library, e.g. with dlopen on Linux. JNI_OnLoad_L is expected to provide the same implementation as JNI_OnLoad besides being used as an identifier of a built-in library, IIUC. In the scenario that I described in the previous message, when a JNI shared library is already implicitly loaded as a dependency of another native library, dlopen for explicitly loading the shared library is not necessary. From the implementation point of view, the code seems to have been doing the right thing since JDK 8. I did some search and found https://stackoverflow.com/questions/32302262/does-dlopen-re-load-already-loaded-dependencies-if-so-what-are-the-implication, which point out to the following in POSIX spec (latest https://pubs.opengroup.org/onlinepubs/9799919799/): "Only a single copy of an executable object file shall be brought into the address space, even if dlopen() is invoked multiple times in reference to the executable object file, and even if different pathnames are used to reference the executable object file." Then avoiding calling dlopen for the already loaded native library doesn't cause any undesired side effects. Perhaps we can update the JNI spec to include the "already loaded" JNI native libraries case, in addition to the built-in native libraries, regarding JNI_OnLoad_L. Also clarify the "these functions will be ignored" part in JNI spec for the dynamically linked libraries. "If dynamically linked library defines JNI_OnLoad_L and/or JNI_OnUnload_L functions, these functions will be ignored." Thoughts? Thanks! Jiangli > > David > ----- > > > Thanks, > > Jiangli > > > >> > >> David > >> ----- > >> > >>> Thanks! > >>> Jiangli > >>>> > >>>> David > >>>> > >>>>> Best, > >>>>> Jiangli > >>>>> > >>>>> > >>>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>> > >>>>>>> From JNI spec [3]: > >>>>>>> > >>>>>>> - JNI_OnLoad/JNI_OnUnload > >>>>>>> Optional function defined by dynamically linked libraries. > >>>>>>> > >>>>>>> LINKAGE: > >>>>>>> Exported from dynamically linked native libraries that contain > >>>>>>> native method implementations. > >>>>>>> > >>>>>>> - JNI_OnLoad_L > >>>>>>> Mandatory function that must be defined by statically linked libraries . > >>>>>>> > >>>>>>> LINKAGE: > >>>>>>> Exported from statically linked native libraries that contain native > >>>>>>> method implementations. > >>>>>>> > >>>>>>> - JNI_OnUnload_L > >>>>>>> Optional function defined by statically linked libraries. > >>>>>>> > >>>>>>> From JVMTI spec [4]: > >>>>>>> > >>>>>>> An agent L whose image has been combined with the VM is defined as > >>>>>>> statically linked if and only if the agent exports a function called > >>>>>>> Agent_OnLoad_L. > >>>>>>> > >>>>>>> [1]: https://bugs.openjdk.org/browse/JDK-8350450 > >>>>>>> [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>>>> [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ > >>>>>>> [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html > >>>>>>> > >>>>>>> Best, > >>>>>>> Jiangli > >>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > >>>>>>>>> > >>>>>>>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > >>>>>>>> > >>>>>>>> Thank you for taking this on! Potentially we could consider taking the > >>>>>>>> objcopy to localizing hotspot symbols on unix-like platforms, based on > >>>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. Additional > >>>>>>>> testing is still needed to verify the solution. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > >>>>>>>> > >>>>>>>> Most of the JDK resources are now supported as hermetic jimage > >>>>>>>> (lib/modules) bundled in the > >>>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. > >>>>>>>> The remaining sound.properties, ct.sym and .jfc files can be handled > >>>>>>>> later. Overally, that part of the work has confirmed the hermetic > >>>>>>>> jimage bundled solution is robust and helps resolve some of the > >>>>>>>> difficult start-up sequence issues observed when the hermetic resource > >>>>>>>> was implemented using JAR file based solution. > >>>>>>>> > >>>>>>>> It might be a good idea to follow up on the static linking discussion > >>>>>>>> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> > >>>>>>>> Jiangli > >>>>>>>>> > >>>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks! > >>>>>>>>> Jiangli > >>>>>>>>> > >>>>>>>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >>>>>>>>>> > >>>>>>>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Magnus, > >>>>>>>>>>> > >>>>>>>>>>> Thanks for looking into this from the build perspective. > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> First some background for build-dev: I have spent some time looking at > >>>>>>>>>>>> the build implications of the Hermetic Java effort, which is part of > >>>>>>>>>>>> Project Leyden. A high-level overview is available here: > >>>>>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source > >>>>>>>>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. > >>>>>>>>>>> > >>>>>>>>>>> Some additional hermetic Java related references that are also useful: > >>>>>>>>>>> > >>>>>>>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >>>>>>>>>>> links to the issues for resolving static linking issues so far > >>>>>>>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >>>>>>>>>>> building the complete set of static libraries in JDK/VM, particularly > >>>>>>>>>>> including libjvm.a > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Hermetic Java faces several challenges, but the part that is relevant > >>>>>>>>>>>> for the build system is the ability to create static libraries. We've > >>>>>>>>>>>> had this functionality (in three different ways...) for some time, but > >>>>>>>>>>>> it is rather badly implemented. > >>>>>>>>>>>> > >>>>>>>>>>>> As a result of my investigations, I have a bunch of questions. :-) I > >>>>>>>>>>>> have gotten some answers in private discussion, but for the sake of > >>>>>>>>>>>> transparency I will repeat them here, to foster an open dialogue. > >>>>>>>>>>>> > >>>>>>>>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise > >>>>>>>>>>>> is to be able to have jmods which include static libraries (*.a) of the > >>>>>>>>>>>> native code which the module uses, and that the user can then run a > >>>>>>>>>>>> special jlink command to have this linked into a single executable > >>>>>>>>>>>> binary (which also bundles the *.class files and any additional > >>>>>>>>>>>> resources needed)? > >>>>>>>>>>>> > >>>>>>>>>>>> 2. If so, is the idea to create special kinds of static jmods, like > >>>>>>>>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? > >>>>>>>>>>>> Or is the idea that the normal jmod should contain both? > >>>>>>>>>>>> > >>>>>>>>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is > >>>>>>>>>>>> the intention to have jlink call a system-provided ld, or to bundle ld > >>>>>>>>>>>> with jlink, or to reimplement this functionality in Java? > >>>>>>>>>>> > >>>>>>>>>>> I have a similar view as Alan responded in your other email thread. > >>>>>>>>>>> Things are still in the early stage for the general solution. > >>>>>>>>>>> > >>>>>>>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>>>>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK > >>>>>>>>>>> binary contains the following extra artifacts: > >>>>>>>>>>> > >>>>>>>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries > >>>>>>>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > >>>>>>>>>>> with the selected JDK .a libraries (e.g. it currently statically link > >>>>>>>>>>> with the headless) and libjvm.a. It's the standard Java launcher > >>>>>>>>>>> without additional work for hermetic Java. > >>>>>>>>>>> > >>>>>>>>>>> In our prototype for hermetic Java, we build the hermetic executable > >>>>>>>>>>> image (a single image) from the following input (see description on > >>>>>>>>>>> singlejar packaging tool in > >>>>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >>>>>>>>>>> > >>>>>>>>>>> - A customized launcher (with additional work for hermetic) executable > >>>>>>>>>>> fully statically linked with JDK/VM static libraries (.a files), > >>>>>>>>>>> application natives and dependencies (e.g. in .a static libraries) > >>>>>>>>>>> - JDK lib/modules, JDK resource files > >>>>>>>>>>> - Application classes and resource files > >>>>>>>>>>> > >>>>>>>>>>> Including a JDK library .a into the corresponding .jmod would require > >>>>>>>>>>> extracting the .a for linking with the executable. In some systems > >>>>>>>>>>> that may cause memory overhead due to the extracted copy of the .a > >>>>>>>>>>> files. I think we should consider the memory overhead issue. > >>>>>>>>>>> > >>>>>>>>>>> One possibility (as Alan described in his response) is for jlink to > >>>>>>>>>>> invoke the ld on the build system. jlink could pass the needed JDK > >>>>>>>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to > >>>>>>>>>>> ld based on the modules required for the application. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >>>>>>>>>> would need to know the complete linker options and inputs. Those > >>>>>>>>>> include options and inputs related to the application part as well. In > >>>>>>>>>> some usages, it might be easier to handle native linking separately > >>>>>>>>>> and pass the linker output, the executable to jlink directly. Maybe we > >>>>>>>>>> could consider supporting different modes for various usages > >>>>>>>>>> requirements, from static libraries and native linking point of view: > >>>>>>>>>> > >>>>>>>>>> Mode #1 > >>>>>>>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a > >>>>>>>>>> and application natives and dependencies. If the inputs to jlink > >>>>>>>>>> include .jmods, jlink can extract the .a libraries and pass the > >>>>>>>>>> information to ld to link the executable. > >>>>>>>>>> > >>>>>>>>>> Mode #2 > >>>>>>>>>> Support separate .a as jlink input. Jlink could pass the path > >>>>>>>>>> information to the .a libraries and other linker options to ld to > >>>>>>>>>> create the executable. > >>>>>>>>>> > >>>>>>>>>> For both mode #1 and #2, jlink would then use the linker output > >>>>>>>>>> executable to create the final hermetic image. > >>>>>>>>>> > >>>>>>>>>> Mode #3 > >>>>>>>>>> Support a fully linked executable as a jlink input. When a linked > >>>>>>>>>> executable is given to jlink, it can process it directly with other > >>>>>>>>>> JDK data/files to create the final image, without native linking step. > >>>>>>>>>> > >>>>>>>>>> Any other thoughts and considerations? > >>>>>>>>>> > >>>>>>>>>> Best, > >>>>>>>>>> Jiangli > >>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 4. Is the intention is to allow users to create their own jmods with > >>>>>>>>>>>> static libraries, and have these linked in as well? This seems to be the > >>>>>>>>>>>> case. > >>>>>>>>>>> > >>>>>>>>>>> An alternative with less memory overhead could be using application > >>>>>>>>>>> modular JAR and separate .a as the input for jlink. > >>>>>>>>>>> > >>>>>>>>>>>> If that is so, then there will always be the risk for name > >>>>>>>>>>>> collisions, and we can only minimize the risk by making sure any global > >>>>>>>>>>>> names are as unique as possible. > >>>>>>>>>>> > >>>>>>>>>>> Part of the current effort includes resolving the discovered symbol > >>>>>>>>>>> collision issues with static linking. Will respond to your other email > >>>>>>>>>>> on the symbol issue separately later. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 5. The original implementation of static builds in the JDK, created for > >>>>>>>>>>>> the Mobile project, used a configure flag, --enable-static-builds, to > >>>>>>>>>>>> change the entire behavior of the build system to only produce *.a files > >>>>>>>>>>>> instead of lib*.so. In contrast, the current system is using a special > >>>>>>>>>>>> target instead. > >>>>>>>>>>> > >>>>>>>>>>> I think we would need both configure flag and special target for the > >>>>>>>>>>> static builds. > >>>>>>>>>>> > >>>>>>>>>>>> In my eyes, this is a much worse solution. Apart from > >>>>>>>>>>>> the conceptual principle (if the build should generate static or dynamic > >>>>>>>>>>>> libraries is definitely a property of what a "configuration" means), > >>>>>>>>>>>> this makes it much harder to implement efficiently, since we cannot make > >>>>>>>>>>>> changes in NativeCompilation.gmk, where they are needed. > >>>>>>>>>>> > >>>>>>>>>>> For the potential objcopy work to resolve symbol issues, we can add > >>>>>>>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >>>>>>>>>>> have an internal prototype (not included in > >>>>>>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >>>>>>>>>>> by one of colleagues for localizing symbols in libfreetype using > >>>>>>>>>>> objcopy. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> That was not as much a question as a statement. ? But here is the > >>>>>>>>>>>> question: Do you think it would be reasonable to restore the old > >>>>>>>>>>>> behavior but with the new methods, so that we don't use special targets, > >>>>>>>>>>>> but instead tells configure to generate static libraries? I'm thinking > >>>>>>>>>>>> we should have a flag like "--with-library-type=" that can have values > >>>>>>>>>>>> "dynamic" (which is default), "static" or "both". > >>>>>>>>>>> > >>>>>>>>>>> If we want to also build a fully statically linked launcher, maybe > >>>>>>>>>>> --with-static-java? Being able to configure either dynamic, static or > >>>>>>>>>>> both as you suggested also seems to be a good idea. > >>>>>>>>>>> > >>>>>>>>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files > >>>>>>>>>>>> into a single jmod file (see question 2 above), then it definitely is. > >>>>>>>>>>>> In general, the cost of producing two kinds of libraries are quite > >>>>>>>>>>>> small, compared to the cost of compiling the source code to object files. > >>>>>>>>>>> > >>>>>>>>>>> Completely agree. It would be good to avoid recompiling the .o file > >>>>>>>>>>> for static and dynamic builds. As proposed in > >>>>>>>>>>> https://bugs.openjdk.org/browse/JDK-8303796: > >>>>>>>>>>> > >>>>>>>>>>> It's beneficial to be able to build both .so and .a from the same set > >>>>>>>>>>> of .o files. That would involve some changes to handle the dynamic JDK > >>>>>>>>>>> and static JDK difference at runtime, instead of relying on the > >>>>>>>>>>> STATIC_BUILD macro. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Finally, I have looked at how to manipulate symbol visibility. There > >>>>>>>>>>>> seems many ways forward, so I feel confident that we can find a good > >>>>>>>>>>>> solution. > >>>>>>>>>>>> > >>>>>>>>>>>> One way forward is to use objcopy to manipulate symbol status > >>>>>>>>>>>> (global/local). There is an option --localize-symbol in objcopy, that > >>>>>>>>>>>> has been available in objcopy since at least 2.15, which was released > >>>>>>>>>>>> 2004, so it should be safe to use. But ideally we should avoid using > >>>>>>>>>>>> objcopy and do this as part of the linking process. This should be > >>>>>>>>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- > >>>>>>>>>>>> see question 5 above. > >>>>>>>>>>>> > >>>>>>>>>>>> As a fallback, it is also possible to rename symbols, either piecewise > >>>>>>>>>>>> or wholesale, using objcopy. There are many ways to do this, using > >>>>>>>>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this > >>>>>>>>>>>> takes a file with a list of symbols). Thus we can always introduce a > >>>>>>>>>>>> "post factum namespace" by renaming symbols. > >>>>>>>>>>> > >>>>>>>>>>> Renaming or redefining the symbol at build time could cause confusions > >>>>>>>>>>> with debugging. That's a concern raised in > >>>>>>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. > >>>>>>>>>>> > >>>>>>>>>>> Additionally, redefining symbols using tools like objcopy may not > >>>>>>>>>>> handle member names referenced in string literals. For example, in > >>>>>>>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > >>>>>>>>>>> needed in assembling and SA to reflect the symbol change. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> So in the end, I think it will be fully possible to produce .a files > >>>>>>>>>>>> that only has global symbols for the functions that are part of the API > >>>>>>>>>>>> exposed by that library, and have all other symbols local, and make this > >>>>>>>>>>>> is in a way that is consistent with the rest of the build system. > >>>>>>>>>>>> > >>>>>>>>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export > >>>>>>>>>>>> basically all symbols in hotspot as global. This is not reasonable to do > >>>>>>>>>>>> for a static build. The effect of not exporting those symbols will be > >>>>>>>>>>>> that SA will not function to 100%. On the other hand, I have no idea if > >>>>>>>>>>>> SA works at all with a static build. Have you tested this? Is this part > >>>>>>>>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? > >>>>>>>>>>> > >>>>>>>>>>> We have done some testing with jtreg SA related tests for the fully > >>>>>>>>>>> statically linked `javastatic`. > >>>>>>>>>>> > >>>>>>>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > >>>>>>>>>>> what's the impact on SA. We could do some tests. The other question > >>>>>>>>>>> that I raised is the supported gcc versions (for partial linking) > >>>>>>>>>>> related to the solution. > >>>>>>>>>>> > >>>>>>>>>>> Best, > >>>>>>>>>>> Jiangli > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> /Magnus > >>>>>>>>>>>> > >>>>>> > >>>> > >> > From darcy at openjdk.org Mon Jun 2 23:45:40 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 2 Jun 2025 23:45:40 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v3] In-Reply-To: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: > First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread > > "Where to put supplementary docs?" > https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html Joe Darcy 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. The pull request contains four additional commits since the last revision: - Merge branch 'master' into JDK-8357000 - Respond to review feedback. - Appease jcheck. - JDK-8357000: Write overview documentation for start of release changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25317/files - new: https://git.openjdk.org/jdk/pull/25317/files/8e10f57b..1e221090 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25317&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25317&range=01-02 Stats: 104522 lines in 1479 files changed: 61995 ins; 28502 del; 14025 mod Patch: https://git.openjdk.org/jdk/pull/25317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25317/head:pull/25317 PR: https://git.openjdk.org/jdk/pull/25317 From david.holmes at oracle.com Tue Jun 3 01:22:26 2025 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Jun 2025 11:22:26 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> Message-ID: <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> On 3/06/2025 9:29 am, Jiangli Zhou wrote: > On Sun, Jun 1, 2025 at 7:55?PM David Holmes wrote: >> >> On 31/05/2025 7:20 am, Jiangli Zhou wrote: >>> On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: >>>> >>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: >>>>> >>>>> I just thought of one more thing related to the discussion now. Any >>>>> concern if the implementation does not ignore JNI_OnLoad_L and etc if >>>>> they are defined application's dynamically linked native libraries? Or >>>>> that's unspecified behavior and it's up to the implement to decide? >>>> >>>> For Internal libraries or external? For external you have to follow the >>>> spec - if both methods exist you only want to execute one of them. >>> >>> It's for the external (non-JDK) library that I'm a bit more cautious. >>> >>> In the existing code in JDK mainline, >>> https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, >>> loadLibrary() first tries to find the built-in library using >>> JNI_OnLoad_L symbol (L is the library name). When dlsym is called to >>> find the symbol from the main process, any of the already loaded >>> shared libraries are also searched, as described by the dlsym man page >>> (included related part below). >>> >>> https://man7.org/linux/man-pages/man3/dlsym.3.html: >>> RTLD_DEFAULT >>> Find the first occurrence of the desired symbol using the >>> default shared object search order. The search will >>> include global symbols in the executable and its >>> dependencies, as well as symbols in shared objects that >>> were dynamically loaded with the RTLD_GLOBAL flag. >>> >>> I think it would be rare, it is possible to construct such case: >>> >>> There are user JNI libraries A and B, with B is built as a dependency >>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B >>> and JNI_OnLoad. When A is being loaded using loadLibrary(), >>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. >>> A is then loaded dynamically, which causes B being loaded implicitly >>> as a dependency of A. Later when loadLibrary() is called for B, >>> JNI_OnLoad_B would be found and then called. This is an existing >>> behavior. I think it's an unspecified behavior and we don't need to >>> add any additional checks to prevent JNI_OnLoad_B from being called. >> >> That sounds like a significant design flaw to me. You can't specify that >> JNI_OnLoad_L will only be called if L is statically linked, if the >> existence of JNI_OnLoad_L is used to infer that L is statically linked! >> I would expect libraries to have both versions of the OnLoad functions >> to allow for them being statically or dynamically linked - which the >> spec allows for by saying the alternate variant is ignored. But then the >> JDK will execute the wrong method if it finds JNI_OnLoad_L in a >> dynamically linked library. > > JNI_OnLoad_L is used to determine if a requested JNI native library is > a built-in (statically linked) library. Thus, it can avoid the > operation of explicit loading for the shared library, e.g. with dlopen > on Linux. JNI_OnLoad_L is expected to provide the same implementation > as JNI_OnLoad besides being used as an identifier of a built-in > library, IIUC. > > In the scenario that I described in the previous message, when a JNI > shared library is already implicitly loaded as a dependency of another > native library, dlopen for explicitly loading the shared library is > not necessary. From the implementation point of view, the code seems > to have been doing the right thing since JDK 8. I did some search and > found https://stackoverflow.com/questions/32302262/does-dlopen-re-load-already-loaded-dependencies-if-so-what-are-the-implication, > which point out to the following in POSIX spec (latest > https://pubs.opengroup.org/onlinepubs/9799919799/): > > "Only a single copy of an executable object file shall be brought into > the address space, even if dlopen() is invoked multiple times in > reference to the executable object file, and even if different > pathnames are used to reference the executable object file." > > Then avoiding calling dlopen for the already loaded native library > doesn't cause any undesired side effects. > > Perhaps we can update the JNI spec to include the "already loaded" JNI > native libraries case, in addition to the built-in native libraries, > regarding JNI_OnLoad_L. Also clarify the "these functions will be > ignored" part in JNI spec for the dynamically linked libraries. > > "If dynamically linked library defines JNI_OnLoad_L and/or > JNI_OnUnload_L functions, these functions will be ignored." > > Thoughts? The problem is, as I see it, that the spec assumes that if it finds the JNI_OnLoad_L symbol then L must be a statically linked library. But that ignores the case you highlight where L was implicitly dynamically loaded as a dependency on another library. Hence the existence test for the symbol is not sufficient to determine if L was statically linked. If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do exactly the same thing it would not make any practical difference, but surely that is not always the case? I can certainly postulate the existence of a library that only needs the "on load" hook for the statically linked case, in which case invoking it when actually dynamically linked would be incorrect and potentially harmful. It seems we lack a way to know if a given library is truly statically linked, or to be advised when a library is implicitly loaded as a dependency. I am no expert on linking but I've been unable to locate any information on programmatically determining these conditions. If there is no real solution then documenting the problem may be all we can do. David ----- > Thanks! > Jiangli From darcy at openjdk.org Tue Jun 3 04:43:59 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 3 Jun 2025 04:43:59 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v4] In-Reply-To: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: > First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread > > "Where to put supplementary docs?" > https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Update description of start of release changes. - Move file up a directory. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25317/files - new: https://git.openjdk.org/jdk/pull/25317/files/1e221090..87b06f84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25317&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25317&range=02-03 Stats: 238 lines in 3 files changed: 195 ins; 43 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25317/head:pull/25317 PR: https://git.openjdk.org/jdk/pull/25317 From sgehwolf at redhat.com Tue Jun 3 09:31:54 2025 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 03 Jun 2025 11:31:54 +0200 Subject: Applying JEP 493 results in "has been modified error" In-Reply-To: <97ca1dbd-2084-4b41-a633-ac72dc144995@skymatic.de> References: <97ca1dbd-2084-4b41-a633-ac72dc144995@skymatic.de> Message-ID: Hi, On Tue, 2025-05-20 at 14:12 +0200, Armin Schrenk wrote:? > Hi all, > > I need to build the JDK due to a strict security environment. The > build system is Ubuntu 22.04 x64 6.8.0 kernel inside a VM. > > I read about JEP 493 (https://openjdk.org/jeps/493) and used the > option "--enable-linkable-runtime". My configure command is: > ?configure \ > ???? --with-conf-name=coffeelibs-openjdk-24 \ > ???? --with-boot-jdk=/path/to/jdk23 \ > ???? --with-version-pre= \ > ???? --with-version-string="24.0.1+9" \ > ???? --with-version-opt=coffeelibs \ > ???? --with-native-debug-symbols=none \ > ???? --enable-linkable-runtime > > ?The jlink tool of this JDK is used later on. But when i try to build > a minial jre with "coffeelibs-openjdk-24/bin/jlink --output runtime - > -module-path "coffeelibs-openjdk-24/jmods" --add-modules java.base", > ?it throws the "... has been modified" error mentioned in the JEP, > not for cacerts or other config files, **but binaries (e.g. java or > lib/libextnet.so ).** > > Does anyone know where the problem is? When that error happens it means the sha512sum of the binary/library in the installation (without JMODs) differs from the binary/library that was present when the linkable runtime was being generated at JDK build time (which uses the JMOD's version of the binary/library to generate the SHA 512 sum for that file and includes it in the jdk.jlink module as a resource file). This can happen for a number of reasons. For example some sort of post- processing is being done by the operating system/build tool (e.g. dpkg) after the JDK has been built. You need to figure out what kind of processing happens and why. If you can prevent that from happening a link from the run-time image should work. Aside: You seem to be using --module-path when generating a runtime from the run-time image (and pointing it to a directory which doesn't find the JMODs; otherwise a JMOD-based link would be performed). That seems confusing. Add `--verbose` and you'll see what "source" for JDK modules the JDK is using when running jlink. Thanks, Severin From kbarrett at openjdk.org Tue Jun 3 10:10:56 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jun 2025 10:10:56 GMT Subject: RFR: 8358284: doc/testing.html is not up to date after JDK-8355003 In-Reply-To: References: Message-ID: <5vTXOVD8deRgbCg8a4t5bUg4WNw5yNXoFaBeCjGtYfI=.9df32e18-de65-4654-803b-df94bcd72bca@github.com> On Mon, 2 Jun 2025 03:43:06 GMT, Kim Barrett wrote: > Please review this trivial change to doc/testing.html, to bring it up to date > with the associated source file doc/testing.md. The change was produced by > running `make update-build-docs` in an up-to-date local repository. Thanks for reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25573#issuecomment-2934489318 From kbarrett at openjdk.org Tue Jun 3 10:10:57 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jun 2025 10:10:57 GMT Subject: Integrated: 8358284: doc/testing.html is not up to date after JDK-8355003 In-Reply-To: References: Message-ID: <0hyIjhNc9h8m7BZcianfPGW3w-Xan1ycgxrHSca9b4o=.de108a32-c8c2-4a6c-8a6d-898418de22b2@github.com> On Mon, 2 Jun 2025 03:43:06 GMT, Kim Barrett wrote: > Please review this trivial change to doc/testing.html, to bring it up to date > with the associated source file doc/testing.md. The change was produced by > running `make update-build-docs` in an up-to-date local repository. This pull request has now been integrated. Changeset: c1a81cfb Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/c1a81cfb51f9c4e7c32a44126746e8655adc349e Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8358284: doc/testing.html is not up to date after JDK-8355003 Reviewed-by: jwaters, dholmes, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25573 From nbenalla at openjdk.org Tue Jun 3 11:14:36 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 3 Jun 2025 11:14:36 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into jdk.8355746 - Problemlist JavaBaseCheckSince - Revert "feedback: never bump ASM version" This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=06 Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Tue Jun 3 11:14:37 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 3 Jun 2025 11:14:37 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com> On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2934728105 From erikj at openjdk.org Tue Jun 3 13:05:03 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jun 2025 13:05:03 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v4] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 3 Jun 2025 04:43:59 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Update description of start of release changes. > - Move file up a directory. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2892258524 From iris at openjdk.org Tue Jun 3 16:26:54 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 3 Jun 2025 16:26:54 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v4] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 3 Jun 2025 04:43:59 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Update description of start of release changes. > - Move file up a directory. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2893262736 From ihse at openjdk.org Tue Jun 3 17:27:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 17:27:01 GMT Subject: RFR: 8358515: make cmp-baseline is broken after JDK-8349665 Message-ID: The fix in to [JDK-8357991](https://bugs.openjdk.org/browse/JDK-8357991) was not enough to solve all problems that had been introduced with JDK-8349665. Also builds run using `COMPARE_BUILD` was affected. The core of the problem was that there were multiple additional ways to run what esstentially amount to `make -f Init.gmk main`, in places that I did not find before. So I took a step back and chose a safer approach: now the `main` target in `Init.gmk` depends on an additional target, that will always make sure that the necessary helper files are present. This means the specific patch for bootcycle builds in JDK-8357991 could be reverted. This solution is also future-proof if we should figure out any new creative ways of calling `main` in `Init.gmk`. ------------- Commit messages: - 8358515: make cmp-baseline is broken after JDK-8349665 Changes: https://git.openjdk.org/jdk/pull/25618/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25618&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358515 Stats: 29 lines in 3 files changed: 12 ins; 13 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25618/head:pull/25618 PR: https://git.openjdk.org/jdk/pull/25618 From ihse at openjdk.org Tue Jun 3 17:33:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 17:33:24 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v4] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 3 Jun 2025 04:43:59 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Update description of start of release changes. > - Move file up a directory. LGTM ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2893439123 From erikj at openjdk.org Tue Jun 3 18:16:17 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jun 2025 18:16:17 GMT Subject: RFR: 8358515: make cmp-baseline is broken after JDK-8349665 In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 14:56:32 GMT, Magnus Ihse Bursie wrote: > The fix in to [JDK-8357991](https://bugs.openjdk.org/browse/JDK-8357991) was not enough to solve all problems that had been introduced with JDK-8349665. Also builds run using `COMPARE_BUILD` was affected. > > The core of the problem was that there were multiple additional ways to run what esstentially amount to `make -f Init.gmk main`, in places that I did not find before. So I took a step back and chose a safer approach: now the `main` target in `Init.gmk` depends on an additional target, that will always make sure that the necessary helper files are present. This means the specific patch for bootcycle builds in JDK-8357991 could be reverted. This solution is also future-proof if we should figure out any new creative ways of calling `main` in `Init.gmk`. Marked as reviewed by erikj (Reviewer). make/Init.gmk line 121: > 119: $(MAKE) $(MAKE_ARGS) -j 1 -f make/Main.gmk $(USER_MAKE_VARS) \ > 120: UPDATE_MODULE_DEPS=true NO_RECIPES=true \ > 121: create-main-targets-include ) That looks like a bit of extra indentation. ------------- PR Review: https://git.openjdk.org/jdk/pull/25618#pullrequestreview-2893553379 PR Review Comment: https://git.openjdk.org/jdk/pull/25618#discussion_r2124559367 From jianglizhou at google.com Tue Jun 3 19:00:26 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 3 Jun 2025 12:00:26 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> Message-ID: On Mon, Jun 2, 2025 at 6:22?PM David Holmes wrote: > > On 3/06/2025 9:29 am, Jiangli Zhou wrote: > > On Sun, Jun 1, 2025 at 7:55?PM David Holmes wrote: > >> > >> On 31/05/2025 7:20 am, Jiangli Zhou wrote: > >>> On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: > >>>> > >>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: > >>>>> > >>>>> I just thought of one more thing related to the discussion now. Any > >>>>> concern if the implementation does not ignore JNI_OnLoad_L and etc if > >>>>> they are defined application's dynamically linked native libraries? Or > >>>>> that's unspecified behavior and it's up to the implement to decide? > >>>> > >>>> For Internal libraries or external? For external you have to follow the > >>>> spec - if both methods exist you only want to execute one of them. > >>> > >>> It's for the external (non-JDK) library that I'm a bit more cautious. > >>> > >>> In the existing code in JDK mainline, > >>> https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, > >>> loadLibrary() first tries to find the built-in library using > >>> JNI_OnLoad_L symbol (L is the library name). When dlsym is called to > >>> find the symbol from the main process, any of the already loaded > >>> shared libraries are also searched, as described by the dlsym man page > >>> (included related part below). > >>> > >>> https://man7.org/linux/man-pages/man3/dlsym.3.html: > >>> RTLD_DEFAULT > >>> Find the first occurrence of the desired symbol using the > >>> default shared object search order. The search will > >>> include global symbols in the executable and its > >>> dependencies, as well as symbols in shared objects that > >>> were dynamically loaded with the RTLD_GLOBAL flag. > >>> > >>> I think it would be rare, it is possible to construct such case: > >>> > >>> There are user JNI libraries A and B, with B is built as a dependency > >>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B > >>> and JNI_OnLoad. When A is being loaded using loadLibrary(), > >>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. > >>> A is then loaded dynamically, which causes B being loaded implicitly > >>> as a dependency of A. Later when loadLibrary() is called for B, > >>> JNI_OnLoad_B would be found and then called. This is an existing > >>> behavior. I think it's an unspecified behavior and we don't need to > >>> add any additional checks to prevent JNI_OnLoad_B from being called. > >> > >> That sounds like a significant design flaw to me. You can't specify that > >> JNI_OnLoad_L will only be called if L is statically linked, if the > >> existence of JNI_OnLoad_L is used to infer that L is statically linked! > >> I would expect libraries to have both versions of the OnLoad functions > >> to allow for them being statically or dynamically linked - which the > >> spec allows for by saying the alternate variant is ignored. But then the > >> JDK will execute the wrong method if it finds JNI_OnLoad_L in a > >> dynamically linked library. > > > > JNI_OnLoad_L is used to determine if a requested JNI native library is > > a built-in (statically linked) library. Thus, it can avoid the > > operation of explicit loading for the shared library, e.g. with dlopen > > on Linux. JNI_OnLoad_L is expected to provide the same implementation > > as JNI_OnLoad besides being used as an identifier of a built-in > > library, IIUC. > > > > In the scenario that I described in the previous message, when a JNI > > shared library is already implicitly loaded as a dependency of another > > native library, dlopen for explicitly loading the shared library is > > not necessary. From the implementation point of view, the code seems > > to have been doing the right thing since JDK 8. I did some search and > > found https://stackoverflow.com/questions/32302262/does-dlopen-re-load-already-loaded-dependencies-if-so-what-are-the-implication, > > which point out to the following in POSIX spec (latest > > https://pubs.opengroup.org/onlinepubs/9799919799/): > > > > "Only a single copy of an executable object file shall be brought into > > the address space, even if dlopen() is invoked multiple times in > > reference to the executable object file, and even if different > > pathnames are used to reference the executable object file." > > > > Then avoiding calling dlopen for the already loaded native library > > doesn't cause any undesired side effects. > > > > Perhaps we can update the JNI spec to include the "already loaded" JNI > > native libraries case, in addition to the built-in native libraries, > > regarding JNI_OnLoad_L. Also clarify the "these functions will be > > ignored" part in JNI spec for the dynamically linked libraries. > > > > "If dynamically linked library defines JNI_OnLoad_L and/or > > JNI_OnUnload_L functions, these functions will be ignored." > > > > Thoughts? > > The problem is, as I see it, that the spec assumes that if it finds the > JNI_OnLoad_L symbol then L must be a statically linked library. But that > ignores the case you highlight where L was implicitly dynamically loaded > as a dependency on another library. Hence the existence test for the > symbol is not sufficient to determine if L was statically linked. Right. > > If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do exactly the > same thing it would not make any practical difference, but surely that > is not always the case? I can certainly postulate the existence of a > library that only needs the "on load" hook for the statically linked > case, in which case invoking it when actually dynamically linked would > be incorrect and potentially harmful. Hmmm, I haven't thought of such a case. David, could you please give a concrete example for the case? > > It seems we lack a way to know if a given library is truly statically > linked, or to be advised when a library is implicitly loaded as a > dependency. I am no expert on linking but I've been unable to locate any > information on programmatically determining these conditions. I haven't found anything either. > > If there is no real solution then documenting the problem may be all we > can do. That sounds reasonable to me. I mentioned the new mailing list discussions to Ron, Alan and Magnus today during the hermetic Java meeting. They may have follow up thoughts. Thanks! Jiangli > > David > ----- > > > Thanks! > > Jiangli From ihse at openjdk.org Tue Jun 3 19:19:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 19:19:32 GMT Subject: RFR: 8358515: make cmp-baseline is broken after JDK-8349665 [v2] In-Reply-To: References: Message-ID: > The fix in to [JDK-8357991](https://bugs.openjdk.org/browse/JDK-8357991) was not enough to solve all problems that had been introduced with JDK-8349665. Also builds run using `COMPARE_BUILD` was affected. > > The core of the problem was that there were multiple additional ways to run what esstentially amount to `make -f Init.gmk main`, in places that I did not find before. So I took a step back and chose a safer approach: now the `main` target in `Init.gmk` depends on an additional target, that will always make sure that the necessary helper files are present. This means the specific patch for bootcycle builds in JDK-8357991 could be reverted. This solution is also future-proof if we should figure out any new creative ways of calling `main` in `Init.gmk`. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25618/files - new: https://git.openjdk.org/jdk/pull/25618/files/afc1b8cf..fd88653b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25618&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25618&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25618.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25618/head:pull/25618 PR: https://git.openjdk.org/jdk/pull/25618 From ihse at openjdk.org Tue Jun 3 19:19:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 19:19:32 GMT Subject: RFR: 8358515: make cmp-baseline is broken after JDK-8349665 [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 18:05:13 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation > > make/Init.gmk line 121: > >> 119: $(MAKE) $(MAKE_ARGS) -j 1 -f make/Main.gmk $(USER_MAKE_VARS) \ >> 120: UPDATE_MODULE_DEPS=true NO_RECIPES=true \ >> 121: create-main-targets-include ) > > That looks like a bit of extra indentation. Does it...? *checking...* Yeah, I see what you mean. I wish there were an editor that were configurable to be actually usable when editing makefiles. (Even more than this, I wish make didn't use tab as a significant syntactic element...) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25618#discussion_r2124711388 From erikj at openjdk.org Tue Jun 3 19:28:22 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jun 2025 19:28:22 GMT Subject: RFR: 8358515: make cmp-baseline is broken after JDK-8349665 [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:19:32 GMT, Magnus Ihse Bursie wrote: >> The fix in to [JDK-8357991](https://bugs.openjdk.org/browse/JDK-8357991) was not enough to solve all problems that had been introduced with JDK-8349665. Also builds run using `COMPARE_BUILD` was affected. >> >> The core of the problem was that there were multiple additional ways to run what esstentially amount to `make -f Init.gmk main`, in places that I did not find before. So I took a step back and chose a safer approach: now the `main` target in `Init.gmk` depends on an additional target, that will always make sure that the necessary helper files are present. This means the specific patch for bootcycle builds in JDK-8357991 could be reverted. This solution is also future-proof if we should figure out any new creative ways of calling `main` in `Init.gmk`. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25618#pullrequestreview-2893804265 From erikj at openjdk.org Tue Jun 3 19:28:23 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jun 2025 19:28:23 GMT Subject: RFR: 8358515: make cmp-baseline is broken after JDK-8349665 [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:15:30 GMT, Magnus Ihse Bursie wrote: >> make/Init.gmk line 121: >> >>> 119: $(MAKE) $(MAKE_ARGS) -j 1 -f make/Main.gmk $(USER_MAKE_VARS) \ >>> 120: UPDATE_MODULE_DEPS=true NO_RECIPES=true \ >>> 121: create-main-targets-include ) >> >> That looks like a bit of extra indentation. > > Does it...? *checking...* Yeah, I see what you mean. I wish there were an editor that were configurable to be actually usable when editing makefiles. (Even more than this, I wish make didn't use tab as a significant syntactic element...) I configured my Emacs to have visible whitespace. Makes it pretty obvious. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25618#discussion_r2124726443 From ihse at openjdk.org Tue Jun 3 19:28:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 19:28:24 GMT Subject: Integrated: 8358515: make cmp-baseline is broken after JDK-8349665 In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 14:56:32 GMT, Magnus Ihse Bursie wrote: > The fix in to [JDK-8357991](https://bugs.openjdk.org/browse/JDK-8357991) was not enough to solve all problems that had been introduced with JDK-8349665. Also builds run using `COMPARE_BUILD` was affected. > > The core of the problem was that there were multiple additional ways to run what esstentially amount to `make -f Init.gmk main`, in places that I did not find before. So I took a step back and chose a safer approach: now the `main` target in `Init.gmk` depends on an additional target, that will always make sure that the necessary helper files are present. This means the specific patch for bootcycle builds in JDK-8357991 could be reverted. This solution is also future-proof if we should figure out any new creative ways of calling `main` in `Init.gmk`. This pull request has now been integrated. Changeset: a44a4700 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a44a470052aff3b17fa53165f043ccce36c1ef9b Stats: 29 lines in 3 files changed: 12 ins; 13 del; 4 mod 8358515: make cmp-baseline is broken after JDK-8349665 Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25618 From ihse at openjdk.org Tue Jun 3 20:18:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 20:18:19 GMT Subject: RFR: 8358543: Remove CommentChecker.java and DirDiff.java Message-ID: These two tools were moved to src/utils/src/build/tools/ during the build-infra project. It was not part of the build, but two standalone tools that nobody knew who created or who used them. I think we can safely delete them now. ------------- Commit messages: - 8358543: Remove CommentChecker.java and DirDiff.java Changes: https://git.openjdk.org/jdk/pull/25629/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25629&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358543 Stats: 492 lines in 2 files changed: 0 ins; 492 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25629.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25629/head:pull/25629 PR: https://git.openjdk.org/jdk/pull/25629 From ihse at openjdk.org Tue Jun 3 20:18:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 20:18:19 GMT Subject: RFR: 8358543: Remove CommentChecker.java and DirDiff.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 20:11:27 GMT, Magnus Ihse Bursie wrote: > These two tools were moved to src/utils/src/build/tools/ during the build-infra project. It was not part of the build, but two standalone tools that nobody knew who created or who used them. > > I think we can safely delete them now. This became apparent due to https://github.com/openjdk/jdk/pull/25541. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25629#issuecomment-2937042275 From ihse at openjdk.org Tue Jun 3 20:19:49 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 20:19:49 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 Message-ID: GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. ------------- Commit messages: - now can we please restore configure option? - maybe 14.43 is installed? - remove toolset from configure again - now maybe like it finally works? - list directories - test 14.42 instead - list all files - new new - try next - try fix vs studio - ... and 2 more: https://git.openjdk.org/jdk/compare/78a392aa...aa322a1c Changes: https://git.openjdk.org/jdk/pull/25628/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25628&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358538 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25628/head:pull/25628 PR: https://git.openjdk.org/jdk/pull/25628 From ihse at openjdk.org Tue Jun 3 20:19:49 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 20:19:49 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:56:37 GMT, Magnus Ihse Bursie wrote: > GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. Also, for the record, fixing stuff like this for GHA where you have no control over the environment is painful. Like in, **P a i n f u l**. You could use it as a curse: "May all your future bugs be GHA problems" and it would put stuff like "May you burn in hell" to shame. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25628#issuecomment-2936972798 From david.holmes at oracle.com Wed Jun 4 04:31:20 2025 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jun 2025 14:31:20 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> Message-ID: <00171a77-af77-4129-b8f3-a168be44c188@oracle.com> On 4/06/2025 5:00 am, Jiangli Zhou wrote: > On Mon, Jun 2, 2025 at 6:22?PM David Holmes wrote: >> >> On 3/06/2025 9:29 am, Jiangli Zhou wrote: >>> On Sun, Jun 1, 2025 at 7:55?PM David Holmes wrote: >>>> >>>> On 31/05/2025 7:20 am, Jiangli Zhou wrote: >>>>> On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: >>>>>> >>>>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: >>>>>>> >>>>>>> I just thought of one more thing related to the discussion now. Any >>>>>>> concern if the implementation does not ignore JNI_OnLoad_L and etc if >>>>>>> they are defined application's dynamically linked native libraries? Or >>>>>>> that's unspecified behavior and it's up to the implement to decide? >>>>>> >>>>>> For Internal libraries or external? For external you have to follow the >>>>>> spec - if both methods exist you only want to execute one of them. >>>>> >>>>> It's for the external (non-JDK) library that I'm a bit more cautious. >>>>> >>>>> In the existing code in JDK mainline, >>>>> https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, >>>>> loadLibrary() first tries to find the built-in library using >>>>> JNI_OnLoad_L symbol (L is the library name). When dlsym is called to >>>>> find the symbol from the main process, any of the already loaded >>>>> shared libraries are also searched, as described by the dlsym man page >>>>> (included related part below). >>>>> >>>>> https://man7.org/linux/man-pages/man3/dlsym.3.html: >>>>> RTLD_DEFAULT >>>>> Find the first occurrence of the desired symbol using the >>>>> default shared object search order. The search will >>>>> include global symbols in the executable and its >>>>> dependencies, as well as symbols in shared objects that >>>>> were dynamically loaded with the RTLD_GLOBAL flag. >>>>> >>>>> I think it would be rare, it is possible to construct such case: >>>>> >>>>> There are user JNI libraries A and B, with B is built as a dependency >>>>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B >>>>> and JNI_OnLoad. When A is being loaded using loadLibrary(), >>>>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. >>>>> A is then loaded dynamically, which causes B being loaded implicitly >>>>> as a dependency of A. Later when loadLibrary() is called for B, >>>>> JNI_OnLoad_B would be found and then called. This is an existing >>>>> behavior. I think it's an unspecified behavior and we don't need to >>>>> add any additional checks to prevent JNI_OnLoad_B from being called. >>>> >>>> That sounds like a significant design flaw to me. You can't specify that >>>> JNI_OnLoad_L will only be called if L is statically linked, if the >>>> existence of JNI_OnLoad_L is used to infer that L is statically linked! >>>> I would expect libraries to have both versions of the OnLoad functions >>>> to allow for them being statically or dynamically linked - which the >>>> spec allows for by saying the alternate variant is ignored. But then the >>>> JDK will execute the wrong method if it finds JNI_OnLoad_L in a >>>> dynamically linked library. >>> >>> JNI_OnLoad_L is used to determine if a requested JNI native library is >>> a built-in (statically linked) library. Thus, it can avoid the >>> operation of explicit loading for the shared library, e.g. with dlopen >>> on Linux. JNI_OnLoad_L is expected to provide the same implementation >>> as JNI_OnLoad besides being used as an identifier of a built-in >>> library, IIUC. >>> >>> In the scenario that I described in the previous message, when a JNI >>> shared library is already implicitly loaded as a dependency of another >>> native library, dlopen for explicitly loading the shared library is >>> not necessary. From the implementation point of view, the code seems >>> to have been doing the right thing since JDK 8. I did some search and >>> found https://stackoverflow.com/questions/32302262/does-dlopen-re-load-already-loaded-dependencies-if-so-what-are-the-implication, >>> which point out to the following in POSIX spec (latest >>> https://pubs.opengroup.org/onlinepubs/9799919799/): >>> >>> "Only a single copy of an executable object file shall be brought into >>> the address space, even if dlopen() is invoked multiple times in >>> reference to the executable object file, and even if different >>> pathnames are used to reference the executable object file." >>> >>> Then avoiding calling dlopen for the already loaded native library >>> doesn't cause any undesired side effects. >>> >>> Perhaps we can update the JNI spec to include the "already loaded" JNI >>> native libraries case, in addition to the built-in native libraries, >>> regarding JNI_OnLoad_L. Also clarify the "these functions will be >>> ignored" part in JNI spec for the dynamically linked libraries. >>> >>> "If dynamically linked library defines JNI_OnLoad_L and/or >>> JNI_OnUnload_L functions, these functions will be ignored." >>> >>> Thoughts? >> >> The problem is, as I see it, that the spec assumes that if it finds the >> JNI_OnLoad_L symbol then L must be a statically linked library. But that >> ignores the case you highlight where L was implicitly dynamically loaded >> as a dependency on another library. Hence the existence test for the >> symbol is not sufficient to determine if L was statically linked. > > Right. > >> >> If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do exactly the >> same thing it would not make any practical difference, but surely that >> is not always the case? I can certainly postulate the existence of a >> library that only needs the "on load" hook for the statically linked >> case, in which case invoking it when actually dynamically linked would >> be incorrect and potentially harmful. > > Hmmm, I haven't thought of such a case. David, could you please give a > concrete example for the case? I don't have a concrete example, that's why I just said I could "postulate the existence" of such a case. :) >> >> It seems we lack a way to know if a given library is truly statically >> linked, or to be advised when a library is implicitly loaded as a >> dependency. I am no expert on linking but I've been unable to locate any >> information on programmatically determining these conditions. > > I haven't found anything either. > >> >> If there is no real solution then documenting the problem may be all we >> can do. > > That sounds reasonable to me. > > I mentioned the new mailing list discussions to Ron, Alan and Magnus > today during the hermetic Java meeting. They may have follow up > thoughts. Okay. David ----- > Thanks! > Jiangli > >> >> David >> ----- >> >>> Thanks! >>> Jiangli From vyazici at openjdk.org Wed Jun 4 07:54:15 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 4 Jun 2025 07:54:15 GMT Subject: RFR: 8358543: Remove CommentChecker.java and DirDiff.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 20:11:27 GMT, Magnus Ihse Bursie wrote: > These two tools were moved to src/utils/src/build/tools/ during the build-infra project. It was not part of the build, but two standalone tools that nobody knew who created or who used them. > > I think we can safely delete them now. Changes LGTM. Could not spot any usages of the removed files. I will skip approving, since, IMHO, a more seasoned maintainer who can bring some historical context should ideally do that. Note that the in-review #25541 also touches `CommentChecker`. I'm perfectly fine with dropping `CommentChecker` changes in #25541 if this PR gets integrated first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25629#issuecomment-2938990007 From ihse at openjdk.org Wed Jun 4 08:13:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 4 Jun 2025 08:13:18 GMT Subject: RFR: 8358543: Remove CommentChecker.java and DirDiff.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 20:11:27 GMT, Magnus Ihse Bursie wrote: > These two tools were moved to src/utils/src/build/tools/ during the build-infra project. It was not part of the build, but two standalone tools that nobody knew who created or who used them. > > I think we can safely delete them now. Yes, it was your changes in https://github.com/openjdk/jdk/pull/25541 that triggered me to remove these files... I had just forgotten about them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25629#issuecomment-2939052009 From shade at openjdk.org Wed Jun 4 11:28:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Jun 2025 11:28:23 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:56:37 GMT, Magnus Ihse Bursie wrote: > GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. .github/workflows/main.yml line 313: > 311: with: > 312: platform: windows-x64 > 313: msvc-toolset-version: '14.43' I wish I understood why `14.43`, since I don't see any reference to it in current runner docs: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md. But I see you have tried other versions, and this one works? >From https://learn.microsoft.com/en-us/lifecycle/faq/visual-c-faq it sounds like `14.43` is not the final one, listed as `TBD`. (Compare with `14.29` for VS 2019.) It is not even listed as "supported"... `14.42` is listed as supported until July 14, 2026. I see you have tried `14.42`: https://github.com/openjdk/jdk/pull/25628/commits/6f7922f5c70e4ffef82005b3ea702673b589eb64 -- did it not work? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25628#discussion_r2126358650 From andrew at openjdk.org Wed Jun 4 13:10:16 2025 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 4 Jun 2025 13:10:16 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:56:37 GMT, Magnus Ihse Bursie wrote: > GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. There's another case of WIndows 2019 in `main.xml` for `test-windows-x64` not fixed here, which is why the testing is stalled. > Also, for the record, fixing stuff like this for GHA where you have no control over the environment is painful. Like in, **P a i n f u l**. You could use it as a curse: "May all your future bugs be GHA problems" and it would put stuff like "May you burn in hell" to shame. Yes... I'm not looking forward to the pain of this on the update releases. Thanks for tackling it on trunk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25628#issuecomment-2939972202 PR Comment: https://git.openjdk.org/jdk/pull/25628#issuecomment-2939975731 From erikj at openjdk.org Wed Jun 4 13:13:52 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 4 Jun 2025 13:13:52 GMT Subject: RFR: 8358543: Remove CommentChecker.java and DirDiff.java In-Reply-To: References: Message-ID: <8f8iHkreE9baiDlqpIFRFmhJo3U61eyX-j5pMlUS4cY=.b2a58b25-43b6-4118-a8b2-490d0ee5b680@github.com> On Tue, 3 Jun 2025 20:11:27 GMT, Magnus Ihse Bursie wrote: > These two tools were moved to src/utils/src/build/tools/ during the build-infra project. It was not part of the build, but two standalone tools that nobody knew who created or who used them. > > I think we can safely delete them now. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25629#pullrequestreview-2896675165 From jianglizhou at google.com Wed Jun 4 15:33:43 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 4 Jun 2025 08:33:43 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <00171a77-af77-4129-b8f3-a168be44c188@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> <00171a77-af77-4129-b8f3-a168be44c188@oracle.com> Message-ID: Ok, still thanks for the thoughts, David. To summarize, here is what we can do for the current step: - Allow JNI_OnLoad_L and etc for JDK internal native libraries with the dynamic linking case. - JNI spec already allows JNI_OnLoad_L and etc for dynamically linked native libraries. No spec change is required to the above. - JNI_OnLoad_L and etc should not be called for dynamically linked native libraries when the library is loaded due to loadLibrary() by default. If a dynamic library is already loaded as a dependency of other native libraries, when loadLibrary() is called for the library, JNI_OnLoad_L can be called. That is an existing behavior since JDK 8. Need to document (in spec or release notes?). Best, Jiangli On Tue, Jun 3, 2025 at 9:31?PM David Holmes wrote: > > On 4/06/2025 5:00 am, Jiangli Zhou wrote: > > On Mon, Jun 2, 2025 at 6:22?PM David Holmes wrote: > >> > >> On 3/06/2025 9:29 am, Jiangli Zhou wrote: > >>> On Sun, Jun 1, 2025 at 7:55?PM David Holmes wrote: > >>>> > >>>> On 31/05/2025 7:20 am, Jiangli Zhou wrote: > >>>>> On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: > >>>>>> > >>>>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: > >>>>>>> > >>>>>>> I just thought of one more thing related to the discussion now. Any > >>>>>>> concern if the implementation does not ignore JNI_OnLoad_L and etc if > >>>>>>> they are defined application's dynamically linked native libraries? Or > >>>>>>> that's unspecified behavior and it's up to the implement to decide? > >>>>>> > >>>>>> For Internal libraries or external? For external you have to follow the > >>>>>> spec - if both methods exist you only want to execute one of them. > >>>>> > >>>>> It's for the external (non-JDK) library that I'm a bit more cautious. > >>>>> > >>>>> In the existing code in JDK mainline, > >>>>> https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, > >>>>> loadLibrary() first tries to find the built-in library using > >>>>> JNI_OnLoad_L symbol (L is the library name). When dlsym is called to > >>>>> find the symbol from the main process, any of the already loaded > >>>>> shared libraries are also searched, as described by the dlsym man page > >>>>> (included related part below). > >>>>> > >>>>> https://man7.org/linux/man-pages/man3/dlsym.3.html: > >>>>> RTLD_DEFAULT > >>>>> Find the first occurrence of the desired symbol using the > >>>>> default shared object search order. The search will > >>>>> include global symbols in the executable and its > >>>>> dependencies, as well as symbols in shared objects that > >>>>> were dynamically loaded with the RTLD_GLOBAL flag. > >>>>> > >>>>> I think it would be rare, it is possible to construct such case: > >>>>> > >>>>> There are user JNI libraries A and B, with B is built as a dependency > >>>>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B > >>>>> and JNI_OnLoad. When A is being loaded using loadLibrary(), > >>>>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. > >>>>> A is then loaded dynamically, which causes B being loaded implicitly > >>>>> as a dependency of A. Later when loadLibrary() is called for B, > >>>>> JNI_OnLoad_B would be found and then called. This is an existing > >>>>> behavior. I think it's an unspecified behavior and we don't need to > >>>>> add any additional checks to prevent JNI_OnLoad_B from being called. > >>>> > >>>> That sounds like a significant design flaw to me. You can't specify that > >>>> JNI_OnLoad_L will only be called if L is statically linked, if the > >>>> existence of JNI_OnLoad_L is used to infer that L is statically linked! > >>>> I would expect libraries to have both versions of the OnLoad functions > >>>> to allow for them being statically or dynamically linked - which the > >>>> spec allows for by saying the alternate variant is ignored. But then the > >>>> JDK will execute the wrong method if it finds JNI_OnLoad_L in a > >>>> dynamically linked library. > >>> > >>> JNI_OnLoad_L is used to determine if a requested JNI native library is > >>> a built-in (statically linked) library. Thus, it can avoid the > >>> operation of explicit loading for the shared library, e.g. with dlopen > >>> on Linux. JNI_OnLoad_L is expected to provide the same implementation > >>> as JNI_OnLoad besides being used as an identifier of a built-in > >>> library, IIUC. > >>> > >>> In the scenario that I described in the previous message, when a JNI > >>> shared library is already implicitly loaded as a dependency of another > >>> native library, dlopen for explicitly loading the shared library is > >>> not necessary. From the implementation point of view, the code seems > >>> to have been doing the right thing since JDK 8. I did some search and > >>> found https://stackoverflow.com/questions/32302262/does-dlopen-re-load-already-loaded-dependencies-if-so-what-are-the-implication, > >>> which point out to the following in POSIX spec (latest > >>> https://pubs.opengroup.org/onlinepubs/9799919799/): > >>> > >>> "Only a single copy of an executable object file shall be brought into > >>> the address space, even if dlopen() is invoked multiple times in > >>> reference to the executable object file, and even if different > >>> pathnames are used to reference the executable object file." > >>> > >>> Then avoiding calling dlopen for the already loaded native library > >>> doesn't cause any undesired side effects. > >>> > >>> Perhaps we can update the JNI spec to include the "already loaded" JNI > >>> native libraries case, in addition to the built-in native libraries, > >>> regarding JNI_OnLoad_L. Also clarify the "these functions will be > >>> ignored" part in JNI spec for the dynamically linked libraries. > >>> > >>> "If dynamically linked library defines JNI_OnLoad_L and/or > >>> JNI_OnUnload_L functions, these functions will be ignored." > >>> > >>> Thoughts? > >> > >> The problem is, as I see it, that the spec assumes that if it finds the > >> JNI_OnLoad_L symbol then L must be a statically linked library. But that > >> ignores the case you highlight where L was implicitly dynamically loaded > >> as a dependency on another library. Hence the existence test for the > >> symbol is not sufficient to determine if L was statically linked. > > > > Right. > > > >> > >> If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do exactly the > >> same thing it would not make any practical difference, but surely that > >> is not always the case? I can certainly postulate the existence of a > >> library that only needs the "on load" hook for the statically linked > >> case, in which case invoking it when actually dynamically linked would > >> be incorrect and potentially harmful. > > > > Hmmm, I haven't thought of such a case. David, could you please give a > > concrete example for the case? > > I don't have a concrete example, that's why I just said I could > "postulate the existence" of such a case. :) > > >> > >> It seems we lack a way to know if a given library is truly statically > >> linked, or to be advised when a library is implicitly loaded as a > >> dependency. I am no expert on linking but I've been unable to locate any > >> information on programmatically determining these conditions. > > > > I haven't found anything either. > > > >> > >> If there is no real solution then documenting the problem may be all we > >> can do. > > > > That sounds reasonable to me. > > > > I mentioned the new mailing list discussions to Ron, Alan and Magnus > > today during the hermetic Java meeting. They may have follow up > > thoughts. > > Okay. > > David > ----- > > > > Thanks! > > Jiangli > > > >> > >> David > >> ----- > >> > >>> Thanks! > >>> Jiangli > From ihse at openjdk.org Wed Jun 4 17:03:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 4 Jun 2025 17:03:07 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 [v2] In-Reply-To: References: Message-ID: > GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update windows version for testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25628/files - new: https://git.openjdk.org/jdk/pull/25628/files/aa322a1c..a5f117b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25628&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25628&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25628/head:pull/25628 PR: https://git.openjdk.org/jdk/pull/25628 From ihse at openjdk.org Wed Jun 4 17:03:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 4 Jun 2025 17:03:07 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: <0syX2sYWvvOG3Y23uhnYGxgUm6J626lEKH8-KMpE4yE=.358a0947-adc1-4613-ba50-26bfa66fc1f4@github.com> On Wed, 4 Jun 2025 13:06:07 GMT, Andrew John Hughes wrote: > There's another case of WIndows 2019 in `main.xml` for `test-windows-x64` not fixed here, which is why the testing is stalled. Oh bummer, I did not see that. Fingers crossed that it's enough to just bump that number. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25628#issuecomment-2940758578 From ihse at openjdk.org Wed Jun 4 17:03:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 4 Jun 2025 17:03:07 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 11:24:45 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Update windows version for testing > > .github/workflows/main.yml line 313: > >> 311: with: >> 312: platform: windows-x64 >> 313: msvc-toolset-version: '14.43' > > I wish I understood why `14.43`, since I don't see any reference to it in current runner docs: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md. But I see you have tried other versions, and this one works? > > From https://learn.microsoft.com/en-us/lifecycle/faq/visual-c-faq it sounds like `14.43` is not supported/final one, listed as `TBD` for start/end dates. (Compare with `14.29` for VS 2019.) `14.42` is listed as supported until July 14, 2026. I see you have tried `14.42`: https://github.com/openjdk/jdk/pull/25628/commits/6f7922f5c70e4ffef82005b3ea702673b589eb64 -- did it not work? Yes, neither 14.44 nor 14.42, which I thought I had good reasons to believe should work did in fact work. :-( I'm not very keen on trying to debug this further. The brownouts have already started. Feel free to either take over this PR, or come up with a follow-up where you try to figure out what VS versions work... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25628#discussion_r2127047780 From shade at openjdk.org Wed Jun 4 17:03:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Jun 2025 17:03:07 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 16:55:12 GMT, Magnus Ihse Bursie wrote: >> .github/workflows/main.yml line 313: >> >>> 311: with: >>> 312: platform: windows-x64 >>> 313: msvc-toolset-version: '14.43' >> >> I wish I understood why `14.43`, since I don't see any reference to it in current runner docs: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md. But I see you have tried other versions, and this one works? >> >> From https://learn.microsoft.com/en-us/lifecycle/faq/visual-c-faq it sounds like `14.43` is not supported/final one, listed as `TBD` for start/end dates. (Compare with `14.29` for VS 2019.) `14.42` is listed as supported until July 14, 2026. I see you have tried `14.42`: https://github.com/openjdk/jdk/pull/25628/commits/6f7922f5c70e4ffef82005b3ea702673b589eb64 -- did it not work? > > Yes, neither 14.44 nor 14.42, which I thought I had good reasons to believe should work did in fact work. :-( I'm not very keen on trying to debug this further. The brownouts have already started. Feel free to either take over this PR, or come up with a follow-up where you try to figure out what VS versions work... Yeah, all right, just checking. If `14.42` worked, it would be tempting to use that. But it does not. So if `14.43` works, let's ship that. We can amend it later. Fix the test job definition: https://github.com/openjdk/jdk/pull/25628#issuecomment-2939972202 -- and I'll approve. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25628#discussion_r2127051108 From shade at openjdk.org Wed Jun 4 17:05:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Jun 2025 17:05:50 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:56:37 GMT, Magnus Ihse Bursie wrote: > GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. Pretty sure it will just work (tm). I'll hang around for a couple hours. So if you are signing off already, set PR to auto-integrate, I'll look at GHA results later and then push the review button, so it integrates itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25628#issuecomment-2940770990 From shade at openjdk.org Wed Jun 4 20:04:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Jun 2025 20:04:52 GMT Subject: RFR: 8358538: Update GHA Windows runner to 2025 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 17:03:07 GMT, Magnus Ihse Bursie wrote: >> GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Update windows version for testing GHA seems fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25628#pullrequestreview-2897956513 From darcy at openjdk.org Wed Jun 4 20:07:00 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 4 Jun 2025 20:07:00 GMT Subject: Integrated: 8357000: Write overview documentation for start of release changes In-Reply-To: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 04:30:57 GMT, Joe Darcy wrote: > First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread > > "Where to put supplementary docs?" > https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html This pull request has now been integrated. Changeset: 77c110c3 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/77c110c309739c2e10c9b321914309affe749e6d Stats: 195 lines in 2 files changed: 195 ins; 0 del; 0 mod 8357000: Write overview documentation for start of release changes Reviewed-by: erikj, iris, ihse, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25317 From darcy at openjdk.org Wed Jun 4 20:13:56 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 4 Jun 2025 20:13:56 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2897980100 From iris at openjdk.org Wed Jun 4 20:37:51 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 4 Jun 2025 20:37:51 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: <35K5iPJmI7-SaswDGvLtPKD87st1QJcFgfka38TsImQ=.b8f56c80-d2c6-4282-8b85-eca97880dfe0@github.com> On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898034878 From kcr at openjdk.org Wed Jun 4 20:37:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 20:37:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com> References: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com> Message-ID: <_Vfw9XCw0xZe8UevwOD5UOW4dZHoT2VzKC4_PT5nIGI=.9f6c8119-c437-49b1-90f5-740793992c20@github.com> On Tue, 3 Jun 2025 11:10:30 GMT, Nizar Benalla wrote: > I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind. What is your plan for addressing this? In its current state, that problem list entry will prevent integration. If you intend to integrate this PR with that test problem listed, you will need to file a new bug and use that bug ID in the problem list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2941383168 From kcr at openjdk.org Wed Jun 4 20:46:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 20:46:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 test/jdk/ProblemList.txt line 843: > 841: # jdk_since_checks > 842: > 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127408934 From nbenalla at openjdk.org Wed Jun 4 21:36:52 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 4 Jun 2025 21:36:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 20:44:12 GMT, Kevin Rushforth wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge branch 'master' into jdk.8355746 >> - Problemlist JavaBaseCheckSince >> - Revert "feedback: never bump ASM version" >> >> This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. >> - Merge branch 'master' into jdk.8355746 >> - Merge branch 'master' into jdk.8355746 >> - Merge branch 'master' into jdk.8355746 >> - Update --release 25 symbol information for JDK 25 build 24 >> The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ >> - Merge branch 'master' into jdk.8355746 >> - problem list some failing tests >> - Merge branch 'master' into jdk.8355746 >> - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 > > test/jdk/ProblemList.txt line 843: > >> 841: # jdk_since_checks >> 842: >> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all > > You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list. Will update this in a couple of hours. Thanks Kevin. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127478174 From kcr at openjdk.org Wed Jun 4 21:51:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 21:51:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 test/jdk/ProblemList.txt line 843: > 841: # jdk_since_checks > 842: > 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all Suggestion: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8358627 generic-all @nizarbenalla Per our offline discussion, I created [JDK-8358627](https://bugs.openjdk.org/browse/JDK-8358627) to track this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127497730 From nbenalla at openjdk.org Wed Jun 4 23:01:14 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 4 Jun 2025 23:01:14 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v8] In-Reply-To: References: Message-ID: <0wD_TZCgYfWRZurWBE_yoLoNtP7xlUUUPxJ3Stqi5Cs=.42b298e3-bbd7-4d9e-bdfd-ae9176ffc9b5@github.com> > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - use a different bug ID to problemlist `kevinrushforth ` - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Problemlist JavaBaseCheckSince - Revert "feedback: never bump ASM version" This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - ... and 12 more: https://git.openjdk.org/jdk/compare/5b27e9c2...09df3b66 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=07 Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Wed Jun 4 23:09:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 4 Jun 2025 23:09:08 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v9] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25008/files - new: https://git.openjdk.org/jdk/pull/25008/files/09df3b66..9929da7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From ihse at openjdk.org Wed Jun 4 23:21:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 4 Jun 2025 23:21:55 GMT Subject: Integrated: 8358538: Update GHA Windows runner to 2025 In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:56:37 GMT, Magnus Ihse Bursie wrote: > GitHub is retiring the windows-2019 runner, starting with brownouts now, and complete removal in about a month. We need to upgrade to Windows 2022 or possible Windows 2025. This pull request has now been integrated. Changeset: b787ff6d Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/b787ff6def08a050b690b60e4a0ceb3aec2b73c8 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod 8358538: Update GHA Windows runner to 2025 Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/25628 From iris at openjdk.org Wed Jun 4 23:56:52 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 4 Jun 2025 23:56:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v9] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 23:09:08 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898378068 From naoto at openjdk.org Thu Jun 5 01:44:56 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 5 Jun 2025 01:44:56 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato wrote: > Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) Looks like this PR did not send out the email in the first place, I am leaving a comment to kick the bot ------------- PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2942422941 From vyazici at openjdk.org Thu Jun 5 06:17:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 5 Jun 2025 06:17:53 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato wrote: > The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) @naotoj, shall we add this note as a comment to places where `-utf8` is added? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2942906463 From david.holmes at oracle.com Thu Jun 5 08:33:08 2025 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Jun 2025 18:33:08 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> <00171a77-af77-4129-b8f3-a168be44c188@oracle.com> Message-ID: <3157708d-6f50-4edc-8479-68c1e974a156@oracle.com> On 5/06/2025 1:33 am, Jiangli Zhou wrote: > Ok, still thanks for the thoughts, David. > > To summarize, here is what we can do for the current step: > > - Allow JNI_OnLoad_L and etc for JDK internal native libraries with > the dynamic linking case. > - JNI spec already allows JNI_OnLoad_L and etc for dynamically linked > native libraries. No spec change is required to the above. Sorry but where does the spec allow this? I thought we had agreed that this was a limitation of the implementation in regard to detecting whether a library is loaded dynamically or statically, and that we needed to document this case in the spec. ?? David ----- > - JNI_OnLoad_L and etc should not be called for dynamically linked > native libraries when the library is loaded due to loadLibrary() by > default. If a dynamic library is already loaded as a dependency of > other native libraries, when loadLibrary() is called for the library, > JNI_OnLoad_L can be called. That is an existing behavior since JDK 8. > Need to document (in spec or release notes?). > > Best, > Jiangli > > On Tue, Jun 3, 2025 at 9:31?PM David Holmes wrote: >> >> On 4/06/2025 5:00 am, Jiangli Zhou wrote: >>> On Mon, Jun 2, 2025 at 6:22?PM David Holmes wrote: >>>> >>>> On 3/06/2025 9:29 am, Jiangli Zhou wrote: >>>>> On Sun, Jun 1, 2025 at 7:55?PM David Holmes wrote: >>>>>> >>>>>> On 31/05/2025 7:20 am, Jiangli Zhou wrote: >>>>>>> On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: >>>>>>>> >>>>>>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: >>>>>>>>> >>>>>>>>> I just thought of one more thing related to the discussion now. Any >>>>>>>>> concern if the implementation does not ignore JNI_OnLoad_L and etc if >>>>>>>>> they are defined application's dynamically linked native libraries? Or >>>>>>>>> that's unspecified behavior and it's up to the implement to decide? >>>>>>>> >>>>>>>> For Internal libraries or external? For external you have to follow the >>>>>>>> spec - if both methods exist you only want to execute one of them. >>>>>>> >>>>>>> It's for the external (non-JDK) library that I'm a bit more cautious. >>>>>>> >>>>>>> In the existing code in JDK mainline, >>>>>>> https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, >>>>>>> loadLibrary() first tries to find the built-in library using >>>>>>> JNI_OnLoad_L symbol (L is the library name). When dlsym is called to >>>>>>> find the symbol from the main process, any of the already loaded >>>>>>> shared libraries are also searched, as described by the dlsym man page >>>>>>> (included related part below). >>>>>>> >>>>>>> https://man7.org/linux/man-pages/man3/dlsym.3.html: >>>>>>> RTLD_DEFAULT >>>>>>> Find the first occurrence of the desired symbol using the >>>>>>> default shared object search order. The search will >>>>>>> include global symbols in the executable and its >>>>>>> dependencies, as well as symbols in shared objects that >>>>>>> were dynamically loaded with the RTLD_GLOBAL flag. >>>>>>> >>>>>>> I think it would be rare, it is possible to construct such case: >>>>>>> >>>>>>> There are user JNI libraries A and B, with B is built as a dependency >>>>>>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B >>>>>>> and JNI_OnLoad. When A is being loaded using loadLibrary(), >>>>>>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. >>>>>>> A is then loaded dynamically, which causes B being loaded implicitly >>>>>>> as a dependency of A. Later when loadLibrary() is called for B, >>>>>>> JNI_OnLoad_B would be found and then called. This is an existing >>>>>>> behavior. I think it's an unspecified behavior and we don't need to >>>>>>> add any additional checks to prevent JNI_OnLoad_B from being called. >>>>>> >>>>>> That sounds like a significant design flaw to me. You can't specify that >>>>>> JNI_OnLoad_L will only be called if L is statically linked, if the >>>>>> existence of JNI_OnLoad_L is used to infer that L is statically linked! >>>>>> I would expect libraries to have both versions of the OnLoad functions >>>>>> to allow for them being statically or dynamically linked - which the >>>>>> spec allows for by saying the alternate variant is ignored. But then the >>>>>> JDK will execute the wrong method if it finds JNI_OnLoad_L in a >>>>>> dynamically linked library. >>>>> >>>>> JNI_OnLoad_L is used to determine if a requested JNI native library is >>>>> a built-in (statically linked) library. Thus, it can avoid the >>>>> operation of explicit loading for the shared library, e.g. with dlopen >>>>> on Linux. JNI_OnLoad_L is expected to provide the same implementation >>>>> as JNI_OnLoad besides being used as an identifier of a built-in >>>>> library, IIUC. >>>>> >>>>> In the scenario that I described in the previous message, when a JNI >>>>> shared library is already implicitly loaded as a dependency of another >>>>> native library, dlopen for explicitly loading the shared library is >>>>> not necessary. From the implementation point of view, the code seems >>>>> to have been doing the right thing since JDK 8. I did some search and >>>>> found https://stackoverflow.com/questions/32302262/does-dlopen-re-load-already-loaded-dependencies-if-so-what-are-the-implication, >>>>> which point out to the following in POSIX spec (latest >>>>> https://pubs.opengroup.org/onlinepubs/9799919799/): >>>>> >>>>> "Only a single copy of an executable object file shall be brought into >>>>> the address space, even if dlopen() is invoked multiple times in >>>>> reference to the executable object file, and even if different >>>>> pathnames are used to reference the executable object file." >>>>> >>>>> Then avoiding calling dlopen for the already loaded native library >>>>> doesn't cause any undesired side effects. >>>>> >>>>> Perhaps we can update the JNI spec to include the "already loaded" JNI >>>>> native libraries case, in addition to the built-in native libraries, >>>>> regarding JNI_OnLoad_L. Also clarify the "these functions will be >>>>> ignored" part in JNI spec for the dynamically linked libraries. >>>>> >>>>> "If dynamically linked library defines JNI_OnLoad_L and/or >>>>> JNI_OnUnload_L functions, these functions will be ignored." >>>>> >>>>> Thoughts? >>>> >>>> The problem is, as I see it, that the spec assumes that if it finds the >>>> JNI_OnLoad_L symbol then L must be a statically linked library. But that >>>> ignores the case you highlight where L was implicitly dynamically loaded >>>> as a dependency on another library. Hence the existence test for the >>>> symbol is not sufficient to determine if L was statically linked. >>> >>> Right. >>> >>>> >>>> If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do exactly the >>>> same thing it would not make any practical difference, but surely that >>>> is not always the case? I can certainly postulate the existence of a >>>> library that only needs the "on load" hook for the statically linked >>>> case, in which case invoking it when actually dynamically linked would >>>> be incorrect and potentially harmful. >>> >>> Hmmm, I haven't thought of such a case. David, could you please give a >>> concrete example for the case? >> >> I don't have a concrete example, that's why I just said I could >> "postulate the existence" of such a case. :) >> >>>> >>>> It seems we lack a way to know if a given library is truly statically >>>> linked, or to be advised when a library is implicitly loaded as a >>>> dependency. I am no expert on linking but I've been unable to locate any >>>> information on programmatically determining these conditions. >>> >>> I haven't found anything either. >>> >>>> >>>> If there is no real solution then documenting the problem may be all we >>>> can do. >>> >>> That sounds reasonable to me. >>> >>> I mentioned the new mailing list discussions to Ron, Alan and Magnus >>> today during the hermetic Java meeting. They may have follow up >>> thoughts. >> >> Okay. >> >> David >> ----- >> >> >>> Thanks! >>> Jiangli >>> >>>> >>>> David >>>> ----- >>>> >>>>> Thanks! >>>>> Jiangli >> From ihse at openjdk.org Thu Jun 5 09:33:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 5 Jun 2025 09:33:56 GMT Subject: Integrated: 8358543: Remove CommentChecker.java and DirDiff.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 20:11:27 GMT, Magnus Ihse Bursie wrote: > These two tools were moved to src/utils/src/build/tools/ during the build-infra project. It was not part of the build, but two standalone tools that nobody knew who created or who used them. > > I think we can safely delete them now. This pull request has now been integrated. Changeset: 66feb490 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/66feb490bdf670c9b101f36b2fa1d0a923c0c3df Stats: 492 lines in 2 files changed: 0 ins; 492 del; 0 mod 8358543: Remove CommentChecker.java and DirDiff.java Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25629 From erikj at openjdk.org Thu Jun 5 12:55:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 5 Jun 2025 12:55:53 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato wrote: > Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2900205154 From jianglizhou at google.com Thu Jun 5 15:23:47 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 5 Jun 2025 08:23:47 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <3157708d-6f50-4edc-8479-68c1e974a156@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> <00171a77-af77-4129-b8f3-a168be44c188@oracle.com> <3157708d-6f50-4edc-8479-68c1e974a156@oracle.com> Message-ID: On Thu, Jun 5, 2025 at 1:33?AM David Holmes wrote: > > On 5/06/2025 1:33 am, Jiangli Zhou wrote: > > Ok, still thanks for the thoughts, David. > > > > To summarize, here is what we can do for the current step: > > > > - Allow JNI_OnLoad_L and etc for JDK internal native libraries with > > the dynamic linking case. > > - JNI spec already allows JNI_OnLoad_L and etc for dynamically linked > > native libraries. No spec change is required to the above. > > Sorry but where does the spec allow this? I thought we had agreed that > this was a limitation of the implementation in regard to detecting > whether a library is loaded dynamically or statically, and that we > needed to document this case in the spec. ?? It's based on the following (referenced in https://mail.openjdk.org/pipermail/leyden-dev/2025-May/002144.html message) specified in https://docs.oracle.com/en/java/javase/21/docs/specs/jni/invocation.html#support-for-statically-linked-libraries : Support for Statically Linked Libraries "If dynamically linked library defines JNI_OnLoad_L and/or JNI_OnUnload_L functions, these functions will be ignored." There are two parts to the above. The first part indicates that the spec allows JNI_OnLoad_L and/or JNI_OnUnload_L being defined in a dynamically linked library. The second part stating "these functions will be ignored" however does not reflect the limitation of the implementation when handling implicitly loaded native libraries. That part needs to be documented. Please let me know if that's more clear. Best, Jiangli > > David > ----- > > > - JNI_OnLoad_L and etc should not be called for dynamically linked > > native libraries when the library is loaded due to loadLibrary() by > > default. If a dynamic library is already loaded as a dependency of > > other native libraries, when loadLibrary() is called for the library, > > JNI_OnLoad_L can be called. That is an existing behavior since JDK 8. > > Need to document (in spec or release notes?). > > > > Best, > > Jiangli > > > > On Tue, Jun 3, 2025 at 9:31?PM David Holmes wrote: > >> > >> On 4/06/2025 5:00 am, Jiangli Zhou wrote: > >>> On Mon, Jun 2, 2025 at 6:22?PM David Holmes wrote: > >>>> > >>>> On 3/06/2025 9:29 am, Jiangli Zhou wrote: > >>>>> On Sun, Jun 1, 2025 at 7:55?PM David Holmes wrote: > >>>>>> > >>>>>> On 31/05/2025 7:20 am, Jiangli Zhou wrote: > >>>>>>> On Thu, May 29, 2025 at 11:54?PM David Holmes < david.holmes at oracle.com> wrote: > >>>>>>>> > >>>>>>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: > >>>>>>>>> > >>>>>>>>> I just thought of one more thing related to the discussion now. Any > >>>>>>>>> concern if the implementation does not ignore JNI_OnLoad_L and etc if > >>>>>>>>> they are defined application's dynamically linked native libraries? Or > >>>>>>>>> that's unspecified behavior and it's up to the implement to decide? > >>>>>>>> > >>>>>>>> For Internal libraries or external? For external you have to follow the > >>>>>>>> spec - if both methods exist you only want to execute one of them. > >>>>>>> > >>>>>>> It's for the external (non-JDK) library that I'm a bit more cautious. > >>>>>>> > >>>>>>> In the existing code in JDK mainline, > >>>>>>> https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117 , > >>>>>>> loadLibrary() first tries to find the built-in library using > >>>>>>> JNI_OnLoad_L symbol (L is the library name). When dlsym is called to > >>>>>>> find the symbol from the main process, any of the already loaded > >>>>>>> shared libraries are also searched, as described by the dlsym man page > >>>>>>> (included related part below). > >>>>>>> > >>>>>>> https://man7.org/linux/man-pages/man3/dlsym.3.html: > >>>>>>> RTLD_DEFAULT > >>>>>>> Find the first occurrence of the desired symbol using the > >>>>>>> default shared object search order. The search will > >>>>>>> include global symbols in the executable and its > >>>>>>> dependencies, as well as symbols in shared objects that > >>>>>>> were dynamically loaded with the RTLD_GLOBAL flag. > >>>>>>> > >>>>>>> I think it would be rare, it is possible to construct such case: > >>>>>>> > >>>>>>> There are user JNI libraries A and B, with B is built as a dependency > >>>>>>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B > >>>>>>> and JNI_OnLoad. When A is being loaded using loadLibrary(), > >>>>>>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. > >>>>>>> A is then loaded dynamically, which causes B being loaded implicitly > >>>>>>> as a dependency of A. Later when loadLibrary() is called for B, > >>>>>>> JNI_OnLoad_B would be found and then called. This is an existing > >>>>>>> behavior. I think it's an unspecified behavior and we don't need to > >>>>>>> add any additional checks to prevent JNI_OnLoad_B from being called. > >>>>>> > >>>>>> That sounds like a significant design flaw to me. You can't specify that > >>>>>> JNI_OnLoad_L will only be called if L is statically linked, if the > >>>>>> existence of JNI_OnLoad_L is used to infer that L is statically linked! > >>>>>> I would expect libraries to have both versions of the OnLoad functions > >>>>>> to allow for them being statically or dynamically linked - which the > >>>>>> spec allows for by saying the alternate variant is ignored. But then the > >>>>>> JDK will execute the wrong method if it finds JNI_OnLoad_L in a > >>>>>> dynamically linked library. > >>>>> > >>>>> JNI_OnLoad_L is used to determine if a requested JNI native library is > >>>>> a built-in (statically linked) library. Thus, it can avoid the > >>>>> operation of explicit loading for the shared library, e.g. with dlopen > >>>>> on Linux. JNI_OnLoad_L is expected to provide the same implementation > >>>>> as JNI_OnLoad besides being used as an identifier of a built-in > >>>>> library, IIUC. > >>>>> > >>>>> In the scenario that I described in the previous message, when a JNI > >>>>> shared library is already implicitly loaded as a dependency of another > >>>>> native library, dlopen for explicitly loading the shared library is > >>>>> not necessary. From the implementation point of view, the code seems > >>>>> to have been doing the right thing since JDK 8. I did some search and > >>>>> found https://stackoverflow.com/questions/32302262/does-dlopen-re-load-already-loaded-dependencies-if-so-what-are-the-implication , > >>>>> which point out to the following in POSIX spec (latest > >>>>> https://pubs.opengroup.org/onlinepubs/9799919799/): > >>>>> > >>>>> "Only a single copy of an executable object file shall be brought into > >>>>> the address space, even if dlopen() is invoked multiple times in > >>>>> reference to the executable object file, and even if different > >>>>> pathnames are used to reference the executable object file." > >>>>> > >>>>> Then avoiding calling dlopen for the already loaded native library > >>>>> doesn't cause any undesired side effects. > >>>>> > >>>>> Perhaps we can update the JNI spec to include the "already loaded" JNI > >>>>> native libraries case, in addition to the built-in native libraries, > >>>>> regarding JNI_OnLoad_L. Also clarify the "these functions will be > >>>>> ignored" part in JNI spec for the dynamically linked libraries. > >>>>> > >>>>> "If dynamically linked library defines JNI_OnLoad_L and/or > >>>>> JNI_OnUnload_L functions, these functions will be ignored." > >>>>> > >>>>> Thoughts? > >>>> > >>>> The problem is, as I see it, that the spec assumes that if it finds the > >>>> JNI_OnLoad_L symbol then L must be a statically linked library. But that > >>>> ignores the case you highlight where L was implicitly dynamically loaded > >>>> as a dependency on another library. Hence the existence test for the > >>>> symbol is not sufficient to determine if L was statically linked. > >>> > >>> Right. > >>> > >>>> > >>>> If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do exactly the > >>>> same thing it would not make any practical difference, but surely that > >>>> is not always the case? I can certainly postulate the existence of a > >>>> library that only needs the "on load" hook for the statically linked > >>>> case, in which case invoking it when actually dynamically linked would > >>>> be incorrect and potentially harmful. > >>> > >>> Hmmm, I haven't thought of such a case. David, could you please give a > >>> concrete example for the case? > >> > >> I don't have a concrete example, that's why I just said I could > >> "postulate the existence" of such a case. :) > >> > >>>> > >>>> It seems we lack a way to know if a given library is truly statically > >>>> linked, or to be advised when a library is implicitly loaded as a > >>>> dependency. I am no expert on linking but I've been unable to locate any > >>>> information on programmatically determining these conditions. > >>> > >>> I haven't found anything either. > >>> > >>>> > >>>> If there is no real solution then documenting the problem may be all we > >>>> can do. > >>> > >>> That sounds reasonable to me. > >>> > >>> I mentioned the new mailing list discussions to Ron, Alan and Magnus > >>> today during the hermetic Java meeting. They may have follow up > >>> thoughts. > >> > >> Okay. > >> > >> David > >> ----- > >> > >> > >>> Thanks! > >>> Jiangli > >>> > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> Thanks! > >>>>> Jiangli > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbenalla at openjdk.org Thu Jun 5 16:03:58 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 5 Jun 2025 16:03:58 GMT Subject: Integrated: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: <-TeQIT9Gmt8CLUcMmPfOQzcPTIGyMpqqVsuEloBx6x8=.55986278-6168-4eff-9784-d91ed7768650@github.com> On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla wrote: > Get JDK 26 underway. This pull request has now been integrated. Changeset: af87035b Author: Nizar Benalla Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/af87035b713f8bfe05a007a4d4670cefc6a6aaf2 Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod 8355746: Start of release updates for JDK 26 8355748: Add SourceVersion.RELEASE_26 8355751: Add source 26 and target 26 to javac Co-authored-by: Joe Darcy Reviewed-by: iris, coleenp, darcy ------------- PR: https://git.openjdk.org/jdk/pull/25008 From cstein at openjdk.org Thu Jun 5 17:32:54 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 5 Jun 2025 17:32:54 GMT Subject: Integrated: 8357141: Update to use jtreg 7.5.2 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 09:51:56 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.5.2. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Tested with tier 1 ? tier 8. This pull request has now been integrated. Changeset: fe3be498 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/fe3be498b83e70a9f4739ddad6642c3aa04a97d3 Stats: 10 lines in 9 files changed: 0 ins; 0 del; 10 mod 8357141: Update to use jtreg 7.5.2 Reviewed-by: erikj, ihse, iris ------------- PR: https://git.openjdk.org/jdk/pull/25263 From naoto at openjdk.org Thu Jun 5 18:30:40 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 5 Jun 2025 18:30:40 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2] In-Reply-To: References: Message-ID: > Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: java.base/Gensrc.gmk comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25648/files - new: https://git.openjdk.org/jdk/pull/25648/files/a5b1c576..5f87c71e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25648&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25648&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25648/head:pull/25648 PR: https://git.openjdk.org/jdk/pull/25648 From naoto at openjdk.org Thu Jun 5 18:30:40 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 5 Jun 2025 18:30:40 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 01:42:00 GMT, Naoto Sato wrote: >> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) > > Looks like this PR did not send out the email in the first place, I am leaving a comment to kick the bot > @naotoj, shall we add this note as a comment to places where `-utf8` is added? Good point. Added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2945607754 From shurailine at openjdk.org Thu Jun 5 23:10:43 2025 From: shurailine at openjdk.org (Alexandre Iline) Date: Thu, 5 Jun 2025 23:10:43 GMT Subject: RFR: 8358721: Update JCov for class file version 70 Message-ID: JDK-8358721: Update JCov for class file version 70 ------------- Commit messages: - JDK-8358721: Update JCov for class file version 70 Changes: https://git.openjdk.org/jdk/pull/25665/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25665&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358721 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25665.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25665/head:pull/25665 PR: https://git.openjdk.org/jdk/pull/25665 From iris at openjdk.org Fri Jun 6 02:54:01 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 6 Jun 2025 02:54:01 GMT Subject: RFR: 8358721: Update JCov for class file version 70 In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 23:05:53 GMT, Alexandre Iline wrote: > JDK-8358721: Update JCov for class file version 70 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25665#pullrequestreview-2903635571 From alanb at openjdk.org Fri Jun 6 05:49:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jun 2025 05:49:51 GMT Subject: RFR: 8358721: Update JCov for class file version 70 In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 23:05:53 GMT, Alexandre Iline wrote: > JDK-8358721: Update JCov for class file version 70 Confirmed that jcov-test target works with this update. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25665#pullrequestreview-2903857679 From vyazici at openjdk.org Fri Jun 6 07:04:00 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 6 Jun 2025 07:04:00 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato wrote: >> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > java.base/Gensrc.gmk comment Verified that 1. `TOOL_CLDRCONVERTER` points to `CLDRConverter` 2. `CLDRConverter` indeed accepts `-utf8` 3. `make/modules/java.base/Gensrc.gmk` and `make/modules/jdk.localedata/Gensrc.gmk` are the only two places where `CLDRConverter` is invoked make/modules/jdk.localedata/Gensrc.gmk line 49: > 47: -o $(GENSRC_DIR) \ > 48: -tzdatadir $(TZ_DATA_DIR) \ > 49: -utf8) @naotoj, I assume you did not add the comment to this change intentionally. ------------- Marked as reviewed by vyazici (Committer). PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2903974963 PR Review Comment: https://git.openjdk.org/jdk/pull/25648#discussion_r2131625005 From erikj at openjdk.org Fri Jun 6 08:50:50 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 6 Jun 2025 08:50:50 GMT Subject: RFR: 8358721: Update JCov for class file version 70 In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 23:05:53 GMT, Alexandre Iline wrote: > JDK-8358721: Update JCov for class file version 70 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25665#pullrequestreview-2904254702 From erikj at openjdk.org Fri Jun 6 08:51:51 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 6 Jun 2025 08:51:51 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato wrote: >> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > java.base/Gensrc.gmk comment Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2904257875 From shurailine at openjdk.org Fri Jun 6 15:09:00 2025 From: shurailine at openjdk.org (Alexandre Iline) Date: Fri, 6 Jun 2025 15:09:00 GMT Subject: Integrated: 8358721: Update JCov for class file version 70 In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 23:05:53 GMT, Alexandre Iline wrote: > JDK-8358721: Update JCov for class file version 70 This pull request has now been integrated. Changeset: 026975a1 Author: Alexandre Iline URL: https://git.openjdk.org/jdk/commit/026975a1aa290613934ae421bbc56326627bad8d Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8358721: Update JCov for class file version 70 Reviewed-by: iris, alanb, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25665 From naoto at openjdk.org Fri Jun 6 15:18:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 6 Jun 2025 15:18:51 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 06:57:20 GMT, Volkan Yazici wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> java.base/Gensrc.gmk comment > > make/modules/jdk.localedata/Gensrc.gmk line 49: > >> 47: -o $(GENSRC_DIR) \ >> 48: -tzdatadir $(TZ_DATA_DIR) \ >> 49: -utf8) > > @naotoj, I assume you did not add the comment to this change intentionally. Yes, that was intentional. It seems apparent that `jdk.localedata` contains resources in non-Latin1 characters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25648#discussion_r2132387343 From david.holmes at oracle.com Mon Jun 9 03:18:56 2025 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Jun 2025 13:18:56 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> <00171a77-af77-4129-b8f3-a168be44c188@oracle.com> <3157708d-6f50-4edc-8479-68c1e974a156@oracle.com> Message-ID: <90713024-8fa6-43ab-bdd3-810b1fef5c2b@oracle.com> On 6/06/2025 1:23 am, Jiangli Zhou wrote: > On Thu, Jun 5, 2025 at 1:33?AM David Holmes > wrote: > > > > On 5/06/2025 1:33 am, Jiangli Zhou wrote: > > > Ok, still thanks for the thoughts, David. > > > > > > To summarize, here is what we can do for the current step: > > > > > > - Allow JNI_OnLoad_L and etc for JDK internal native libraries with > > > the dynamic linking case. > > > - JNI spec already allows JNI_OnLoad_L and etc for dynamically linked > > > native libraries. No spec change is required to the above. > > > > Sorry but where does the spec allow this? I thought we had agreed that > > this was a limitation of the implementation in regard to detecting > > whether a library is loaded dynamically or statically, and that we > > needed to document this case in the spec. ?? > > It's based on the following (referenced in https://mail.openjdk.org/ > pipermail/leyden-dev/2025-May/002144.html pipermail/leyden-dev/2025-May/002144.html> message) specified in > https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ > invocation.html#support-for-statically-linked-libraries docs.oracle.com/en/java/javase/21/docs/specs/jni/ > invocation.html#support-for-statically-linked-libraries>: > > Support for Statically Linked Libraries > > > "If dynamically linked library defines JNI_OnLoad_L and/or > JNI_OnUnload_L functions, these functions will be ignored." > > There are two parts to the above. The first part indicates that the spec > allows JNI_OnLoad_L and/or JNI_OnUnload_L being defined in a dynamically > linked library. I don't agree that you can split that one sentence into two parts to allow the first section to be a justification of allowing JNI_OnLoad_L in a dynamically linked library. The intent of this part of to say these functions should not exist but if they do we will ignore them. We have a situation where the spec is clear in intent, but the implementation doesn't have enough information to accurately implement what the spec states. So the intent here is to document this gap between the spec and implementation by adding a note to the spec. David ----- > The second part stating "these functions will be ignored" however does > not reflect the limitation of the implementation when handling > implicitly loaded native libraries. That part needs to be documented. > > Please let me know if that's more clear. > > Best, > > Jiangli > > > > > David > > ----- > > > > > - JNI_OnLoad_L and etc should not be called for dynamically linked > > > native libraries when the library is loaded due to loadLibrary() by > > > default. If a dynamic library is already loaded as a dependency of > > > other native libraries, when loadLibrary() is called for the library, > > > JNI_OnLoad_L can be called. That is an existing behavior since JDK 8. > > > Need to document (in spec or release notes?). > > > > > > Best, > > > Jiangli > > > > > > On Tue, Jun 3, 2025 at 9:31?PM David Holmes > > wrote: > > >> > > >> On 4/06/2025 5:00 am, Jiangli Zhou wrote: > > >>> On Mon, Jun 2, 2025 at 6:22?PM David Holmes > > wrote: > > >>>> > > >>>> On 3/06/2025 9:29 am, Jiangli Zhou wrote: > > >>>>> On Sun, Jun 1, 2025 at 7:55?PM David Holmes > > wrote: > > >>>>>> > > >>>>>> On 31/05/2025 7:20 am, Jiangli Zhou wrote: > > >>>>>>> On Thu, May 29, 2025 at 11:54?PM David Holmes > > wrote: > > >>>>>>>> > > >>>>>>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: > > >>>>>>>>> > > >>>>>>>>> I just thought of one more thing related to the discussion > now. Any > > >>>>>>>>> concern if the implementation does not ignore JNI_OnLoad_L > and etc if > > >>>>>>>>> they are defined application's dynamically linked native > libraries? Or > > >>>>>>>>> that's unspecified behavior and it's up to the implement to > decide? > > >>>>>>>> > > >>>>>>>> For Internal libraries or external? For external you have to > follow the > > >>>>>>>> spec - if both methods exist you only want to execute one of > them. > > >>>>>>> > > >>>>>>> It's for the external (non-JDK) library that I'm a bit more > cautious. > > >>>>>>> > > >>>>>>> In the existing code in JDK mainline, > > >>>>>>> https://github.com/openjdk/jdk/ > blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/ > classes/jdk/internal/loader/NativeLibraries.java#L117 github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/ > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117>, > > >>>>>>> loadLibrary() first tries to find the built-in library using > > >>>>>>> JNI_OnLoad_L symbol (L is the library name). When dlsym is > called to > > >>>>>>> find the symbol from the main process, any of the already loaded > > >>>>>>> shared libraries are also searched, as described by the dlsym > man page > > >>>>>>> (included related part below). > > >>>>>>> > > >>>>>>> https://man7.org/linux/man-pages/man3/dlsym.3.html man7.org/linux/man-pages/man3/dlsym.3.html>: > > >>>>>>> ? ? ? ? ? ?RTLD_DEFAULT > > >>>>>>> ? ? ? ? ? ? ? ? ? Find the first occurrence of the desired > symbol using the > > >>>>>>> ? ? ? ? ? ? ? ? ? default shared object search order.? The > search will > > >>>>>>> ? ? ? ? ? ? ? ? ? include global symbols in the executable > and its > > >>>>>>> ? ? ? ? ? ? ? ? ? dependencies, as well as symbols in shared > objects that > > >>>>>>> ? ? ? ? ? ? ? ? ? were dynamically loaded with the > RTLD_GLOBAL flag. > > >>>>>>> > > >>>>>>> I think it would be rare, it is possible to construct such case: > > >>>>>>> > > >>>>>>> There are user JNI libraries A and B, with B is built as a > dependency > > >>>>>>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines > JNI_OnLoad_B > > >>>>>>> and JNI_OnLoad. When A is being loaded using loadLibrary(), > > >>>>>>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is > not found. > > >>>>>>> A is then loaded dynamically, which causes B being loaded > implicitly > > >>>>>>> as a dependency of A. Later when loadLibrary() is called for B, > > >>>>>>> JNI_OnLoad_B would be found and then called. This is an existing > > >>>>>>> behavior. I think it's an unspecified behavior and we don't > need to > > >>>>>>> add any additional checks to prevent JNI_OnLoad_B from being > called. > > >>>>>> > > >>>>>> That sounds like a significant design flaw to me. You can't > specify that > > >>>>>> JNI_OnLoad_L will only be called if L is statically linked, if the > > >>>>>> existence of JNI_OnLoad_L is used to infer that L is > statically linked! > > >>>>>> I would expect libraries to have both versions of the OnLoad > functions > > >>>>>> to allow for them being statically or dynamically linked - > which the > > >>>>>> spec allows for by saying the alternate variant is ignored. > But then the > > >>>>>> JDK will execute the wrong method if it finds JNI_OnLoad_L in a > > >>>>>> dynamically linked library. > > >>>>> > > >>>>> JNI_OnLoad_L is used to determine if a requested JNI native > library is > > >>>>> a built-in (statically linked) library. Thus, it can avoid the > > >>>>> operation of explicit loading for the shared library, e.g. with > dlopen > > >>>>> on Linux. JNI_OnLoad_L is expected to provide the same > implementation > > >>>>> as JNI_OnLoad besides being used as an identifier of a built-in > > >>>>> library, IIUC. > > >>>>> > > >>>>> In the scenario that I described in the previous message, when > a JNI > > >>>>> shared library is already implicitly loaded as a dependency of > another > > >>>>> native library, dlopen for explicitly loading the shared library is > > >>>>> not necessary. From the implementation point of view, the code > seems > > >>>>> to have been doing the right thing since JDK 8. I did some > search and > > >>>>> found https://stackoverflow.com/questions/32302262/does-dlopen- > re-load-already-loaded-dependencies-if-so-what-are-the-implication > already-loaded-dependencies-if-so-what-are-the-implication>, > > >>>>> which point out to the following in POSIX spec (latest > > >>>>> https://pubs.opengroup.org/onlinepubs/9799919799/ pubs.opengroup.org/onlinepubs/9799919799/>): > > >>>>> > > >>>>> "Only a single copy of an executable object file shall be > brought into > > >>>>> the address space, even if dlopen() is invoked multiple times in > > >>>>> reference to the executable object file, and even if different > > >>>>> pathnames are used to reference the executable object file." > > >>>>> > > >>>>> Then avoiding calling dlopen for the already loaded native library > > >>>>> doesn't cause any undesired side effects. > > >>>>> > > >>>>> Perhaps we can update the JNI spec to include the "already > loaded" JNI > > >>>>> native libraries case, in addition to the built-in native > libraries, > > >>>>> regarding JNI_OnLoad_L. Also clarify the "these functions will be > > >>>>> ignored" part in JNI spec for the dynamically linked libraries. > > >>>>> > > >>>>> "If dynamically linked library defines JNI_OnLoad_L and/or > > >>>>> JNI_OnUnload_L functions, these functions will be ignored." > > >>>>> > > >>>>> Thoughts? > > >>>> > > >>>> The problem is, as I see it, that the spec assumes that if it > finds the > > >>>> JNI_OnLoad_L symbol then L must be a statically linked library. > But that > > >>>> ignores the case you highlight where L was implicitly > dynamically loaded > > >>>> as a dependency on another library. Hence the existence test for the > > >>>> symbol is not sufficient to determine if L was statically linked. > > >>> > > >>> Right. > > >>> > > >>>> > > >>>> If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do > exactly the > > >>>> same thing it would not make any practical difference, but > surely that > > >>>> is not always the case? I can certainly postulate the existence of a > > >>>> library that only needs the "on load" hook for the statically linked > > >>>> case, in which case invoking it when actually dynamically linked > would > > >>>> be incorrect and potentially harmful. > > >>> > > >>> Hmmm, I haven't thought of such a case. David, could you please > give a > > >>> concrete example for the case? > > >> > > >> I don't have a concrete example, that's why I just said I could > > >> "postulate the existence" of such a case. :) > > >> > > >>>> > > >>>> It seems we lack a way to know if a given library is truly > statically > > >>>> linked, or to be advised when a library is implicitly loaded as a > > >>>> dependency. I am no expert on linking but I've been unable to > locate any > > >>>> information on programmatically determining these conditions. > > >>> > > >>> I haven't found anything either. > > >>> > > >>>> > > >>>> If there is no real solution then documenting the problem may be > all we > > >>>> can do. > > >>> > > >>> That sounds reasonable to me. > > >>> > > >>> I mentioned the new mailing list discussions to Ron, Alan and Magnus > > >>> today during the hermetic Java meeting. They may have follow up > > >>> thoughts. > > >> > > >> Okay. > > >> > > >> David > > >> ----- > > >> > > >> > > >>> Thanks! > > >>> Jiangli > > >>> > > >>>> > > >>>> David > > >>>> ----- > > >>>> > > >>>>> Thanks! > > >>>>> Jiangli > > >> > > From ihse at openjdk.org Mon Jun 9 13:42:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 13:42:56 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. I opened https://bugs.openjdk.org/browse/SKARA-2514 for a jcheck enhancement. I recommend that we revert this change once that is implemented. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2955829763 From jianglizhou at google.com Mon Jun 9 18:17:37 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 9 Jun 2025 11:17:37 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <90713024-8fa6-43ab-bdd3-810b1fef5c2b@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> <472b8b8a-53ce-4e43-ab20-8b3b7f71fd9d@oracle.com> <3f0bdc84-4fde-4e1a-a89d-fa9c66a51aae@oracle.com> <00171a77-af77-4129-b8f3-a168be44c188@oracle.com> <3157708d-6f50-4edc-8479-68c1e974a156@oracle.com> <90713024-8fa6-43ab-bdd3-810b1fef5c2b@oracle.com> Message-ID: On Sun, Jun 8, 2025 at 8:19?PM David Holmes wrote: > On 6/06/2025 1:23 am, Jiangli Zhou wrote: > > On Thu, Jun 5, 2025 at 1:33?AM David Holmes > > wrote: > > > > > > On 5/06/2025 1:33 am, Jiangli Zhou wrote: > > > > Ok, still thanks for the thoughts, David. > > > > > > > > To summarize, here is what we can do for the current step: > > > > > > > > - Allow JNI_OnLoad_L and etc for JDK internal native libraries with > > > > the dynamic linking case. > > > > - JNI spec already allows JNI_OnLoad_L and etc for dynamically > linked > > > > native libraries. No spec change is required to the above. > > > > > > Sorry but where does the spec allow this? I thought we had agreed that > > > this was a limitation of the implementation in regard to detecting > > > whether a library is loaded dynamically or statically, and that we > > > needed to document this case in the spec. ?? > > > > It's based on the following (referenced in https://mail.openjdk.org/ > > pipermail/leyden-dev/2025-May/002144.html > pipermail/leyden-dev/2025-May/002144.html> message) specified in > > https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ > > invocation.html#support-for-statically-linked-libraries > docs.oracle.com/en/java/javase/21/docs/specs/jni/ > > invocation.html#support-for-statically-linked-libraries>: > > > > Support for Statically Linked Libraries > > > > > > "If dynamically linked library defines JNI_OnLoad_L and/or > > JNI_OnUnload_L functions, these functions will be ignored." > > > > There are two parts to the above. The first part indicates that the spec > > allows JNI_OnLoad_L and/or JNI_OnUnload_L being defined in a dynamically > > linked library. > > I don't agree that you can split that one sentence into two parts to > allow the first section to be a justification of allowing JNI_OnLoad_L > in a dynamically linked library. The intent of this part of to say these > functions should not exist but if they do we will ignore them. > > We have a situation where the spec is clear in intent, but the > implementation doesn't have enough information to accurately implement > what the spec states. > > So the intent here is to document this gap between the spec and > implementation by adding a note to the spec. > Thanks, David. Your interpretation and reasoning sounds ok to me. More importantly, we have consensus on documenting the case with implicitly loaded dynamically linked native libraries. I'll file a bug. Best Jiangli > > David > ----- > > > The second part stating "these functions will be ignored" however does > > not reflect the limitation of the implementation when handling > > implicitly loaded native libraries. That part needs to be documented. > > > > Please let me know if that's more clear. > > > > Best, > > > > Jiangli > > > > > > > > David > > > ----- > > > > > > > - JNI_OnLoad_L and etc should not be called for dynamically linked > > > > native libraries when the library is loaded due to loadLibrary() by > > > > default. If a dynamic library is already loaded as a dependency of > > > > other native libraries, when loadLibrary() is called for the > library, > > > > JNI_OnLoad_L can be called. That is an existing behavior since JDK > 8. > > > > Need to document (in spec or release notes?). > > > > > > > > Best, > > > > Jiangli > > > > > > > > On Tue, Jun 3, 2025 at 9:31?PM David Holmes > > > wrote: > > > >> > > > >> On 4/06/2025 5:00 am, Jiangli Zhou wrote: > > > >>> On Mon, Jun 2, 2025 at 6:22?PM David Holmes > > > wrote: > > > >>>> > > > >>>> On 3/06/2025 9:29 am, Jiangli Zhou wrote: > > > >>>>> On Sun, Jun 1, 2025 at 7:55?PM David Holmes > > > wrote: > > > >>>>>> > > > >>>>>> On 31/05/2025 7:20 am, Jiangli Zhou wrote: > > > >>>>>>> On Thu, May 29, 2025 at 11:54?PM David Holmes > > > wrote: > > > >>>>>>>> > > > >>>>>>>> On 30/05/2025 9:26 am, Jiangli Zhou wrote: > > > >>>>>>>>> > > > >>>>>>>>> I just thought of one more thing related to the discussion > > now. Any > > > >>>>>>>>> concern if the implementation does not ignore JNI_OnLoad_L > > and etc if > > > >>>>>>>>> they are defined application's dynamically linked native > > libraries? Or > > > >>>>>>>>> that's unspecified behavior and it's up to the implement to > > decide? > > > >>>>>>>> > > > >>>>>>>> For Internal libraries or external? For external you have to > > follow the > > > >>>>>>>> spec - if both methods exist you only want to execute one of > > them. > > > >>>>>>> > > > >>>>>>> It's for the external (non-JDK) library that I'm a bit more > > cautious. > > > >>>>>>> > > > >>>>>>> In the existing code in JDK mainline, > > > >>>>>>> https://github.com/openjdk/jdk/ > > blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/ > > classes/jdk/internal/loader/NativeLibraries.java#L117 > github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/ > > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117>, > > > >>>>>>> loadLibrary() first tries to find the built-in library using > > > >>>>>>> JNI_OnLoad_L symbol (L is the library name). When dlsym is > > called to > > > >>>>>>> find the symbol from the main process, any of the already > loaded > > > >>>>>>> shared libraries are also searched, as described by the dlsym > > man page > > > >>>>>>> (included related part below). > > > >>>>>>> > > > >>>>>>> https://man7.org/linux/man-pages/man3/dlsym.3.html > man7.org/linux/man-pages/man3/dlsym.3.html>: > > > >>>>>>> RTLD_DEFAULT > > > >>>>>>> Find the first occurrence of the desired > > symbol using the > > > >>>>>>> default shared object search order. The > > search will > > > >>>>>>> include global symbols in the executable > > and its > > > >>>>>>> dependencies, as well as symbols in shared > > objects that > > > >>>>>>> were dynamically loaded with the > > RTLD_GLOBAL flag. > > > >>>>>>> > > > >>>>>>> I think it would be rare, it is possible to construct such > case: > > > >>>>>>> > > > >>>>>>> There are user JNI libraries A and B, with B is built as a > > dependency > > > >>>>>>> of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines > > JNI_OnLoad_B > > > >>>>>>> and JNI_OnLoad. When A is being loaded using loadLibrary(), > > > >>>>>>> loadLibrary() tries first to lookup JNI_OnLoad_A, which is > > not found. > > > >>>>>>> A is then loaded dynamically, which causes B being loaded > > implicitly > > > >>>>>>> as a dependency of A. Later when loadLibrary() is called for > B, > > > >>>>>>> JNI_OnLoad_B would be found and then called. This is an > existing > > > >>>>>>> behavior. I think it's an unspecified behavior and we don't > > need to > > > >>>>>>> add any additional checks to prevent JNI_OnLoad_B from being > > called. > > > >>>>>> > > > >>>>>> That sounds like a significant design flaw to me. You can't > > specify that > > > >>>>>> JNI_OnLoad_L will only be called if L is statically linked, if > the > > > >>>>>> existence of JNI_OnLoad_L is used to infer that L is > > statically linked! > > > >>>>>> I would expect libraries to have both versions of the OnLoad > > functions > > > >>>>>> to allow for them being statically or dynamically linked - > > which the > > > >>>>>> spec allows for by saying the alternate variant is ignored. > > But then the > > > >>>>>> JDK will execute the wrong method if it finds JNI_OnLoad_L in a > > > >>>>>> dynamically linked library. > > > >>>>> > > > >>>>> JNI_OnLoad_L is used to determine if a requested JNI native > > library is > > > >>>>> a built-in (statically linked) library. Thus, it can avoid the > > > >>>>> operation of explicit loading for the shared library, e.g. with > > dlopen > > > >>>>> on Linux. JNI_OnLoad_L is expected to provide the same > > implementation > > > >>>>> as JNI_OnLoad besides being used as an identifier of a built-in > > > >>>>> library, IIUC. > > > >>>>> > > > >>>>> In the scenario that I described in the previous message, when > > a JNI > > > >>>>> shared library is already implicitly loaded as a dependency of > > another > > > >>>>> native library, dlopen for explicitly loading the shared > library is > > > >>>>> not necessary. From the implementation point of view, the code > > seems > > > >>>>> to have been doing the right thing since JDK 8. I did some > > search and > > > >>>>> found https://stackoverflow.com/questions/32302262/does-dlopen- > > re-load-already-loaded-dependencies-if-so-what-are-the-implication > > > already-loaded-dependencies-if-so-what-are-the-implication>, > > > >>>>> which point out to the following in POSIX spec (latest > > > >>>>> https://pubs.opengroup.org/onlinepubs/9799919799/ > pubs.opengroup.org/onlinepubs/9799919799/>): > > > >>>>> > > > >>>>> "Only a single copy of an executable object file shall be > > brought into > > > >>>>> the address space, even if dlopen() is invoked multiple times in > > > >>>>> reference to the executable object file, and even if different > > > >>>>> pathnames are used to reference the executable object file." > > > >>>>> > > > >>>>> Then avoiding calling dlopen for the already loaded native > library > > > >>>>> doesn't cause any undesired side effects. > > > >>>>> > > > >>>>> Perhaps we can update the JNI spec to include the "already > > loaded" JNI > > > >>>>> native libraries case, in addition to the built-in native > > libraries, > > > >>>>> regarding JNI_OnLoad_L. Also clarify the "these functions will > be > > > >>>>> ignored" part in JNI spec for the dynamically linked libraries. > > > >>>>> > > > >>>>> "If dynamically linked library defines JNI_OnLoad_L and/or > > > >>>>> JNI_OnUnload_L functions, these functions will be ignored." > > > >>>>> > > > >>>>> Thoughts? > > > >>>> > > > >>>> The problem is, as I see it, that the spec assumes that if it > > finds the > > > >>>> JNI_OnLoad_L symbol then L must be a statically linked library. > > But that > > > >>>> ignores the case you highlight where L was implicitly > > dynamically loaded > > > >>>> as a dependency on another library. Hence the existence test for > the > > > >>>> symbol is not sufficient to determine if L was statically linked. > > > >>> > > > >>> Right. > > > >>> > > > >>>> > > > >>>> If JNI_OnLoad_L and JNI_OnLoad were guaranteed to always do > > exactly the > > > >>>> same thing it would not make any practical difference, but > > surely that > > > >>>> is not always the case? I can certainly postulate the existence > of a > > > >>>> library that only needs the "on load" hook for the statically > linked > > > >>>> case, in which case invoking it when actually dynamically linked > > would > > > >>>> be incorrect and potentially harmful. > > > >>> > > > >>> Hmmm, I haven't thought of such a case. David, could you please > > give a > > > >>> concrete example for the case? > > > >> > > > >> I don't have a concrete example, that's why I just said I could > > > >> "postulate the existence" of such a case. :) > > > >> > > > >>>> > > > >>>> It seems we lack a way to know if a given library is truly > > statically > > > >>>> linked, or to be advised when a library is implicitly loaded as a > > > >>>> dependency. I am no expert on linking but I've been unable to > > locate any > > > >>>> information on programmatically determining these conditions. > > > >>> > > > >>> I haven't found anything either. > > > >>> > > > >>>> > > > >>>> If there is no real solution then documenting the problem may be > > all we > > > >>>> can do. > > > >>> > > > >>> That sounds reasonable to me. > > > >>> > > > >>> I mentioned the new mailing list discussions to Ron, Alan and > Magnus > > > >>> today during the hermetic Java meeting. They may have follow up > > > >>> thoughts. > > > >> > > > >> Okay. > > > >> > > > >> David > > > >> ----- > > > >> > > > >> > > > >>> Thanks! > > > >>> Jiangli > > > >>> > > > >>>> > > > >>>> David > > > >>>> ----- > > > >>>> > > > >>>>> Thanks! > > > >>>>> Jiangli > > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Mon Jun 9 18:56:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 9 Jun 2025 18:56:45 GMT Subject: RFR: 8358626: Emit UTF-8 CLDR resources [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato wrote: >> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > java.base/Gensrc.gmk comment Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2956654203 From naoto at openjdk.org Mon Jun 9 19:07:36 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 9 Jun 2025 19:07:36 GMT Subject: Integrated: 8358626: Emit UTF-8 CLDR resources In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato wrote: > Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye) This pull request has now been integrated. Changeset: fcb68ea2 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/fcb68ea22d020d567c560c7bd5976d3c070d9806 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod 8358626: Emit UTF-8 CLDR resources Reviewed-by: erikj, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/25648 From swen at openjdk.org Tue Jun 10 01:20:59 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 10 Jun 2025 01:20:59 GMT Subject: RFR: 8359068: Remove the unused Cstyle code in GenerateCharacter Message-ID: According to the suggestions of @cl4es and @naotoj, Cstyle is no longer used in GenerateCharacter, so remove the Cstyle related code. ------------- Commit messages: - remove `Csyntax` Changes: https://git.openjdk.org/jdk/pull/25480/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25480&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359068 Stats: 38 lines in 1 file changed: 0 ins; 14 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/25480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25480/head:pull/25480 PR: https://git.openjdk.org/jdk/pull/25480 From syan at openjdk.org Wed Jun 11 03:26:14 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 11 Jun 2025 03:26:14 GMT Subject: RFR: 8359181: Error messages generated by configure --help after 8301197 Message-ID: Hi all, I have no idea why in make function `HELP_PRINT_ADDITIONAL_HELP_AND_EXIT` can use `$PRINTF` variable but can not use `$ECHO` varibale. This PR use `$PRINTF` instead of `$ECHO`. Change has been verified locally, almost no risk. ------------- Commit messages: - 8359181: Error messages generated by configure --help after 8301197 Changes: https://git.openjdk.org/jdk/pull/25740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25740&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359181 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25740/head:pull/25740 PR: https://git.openjdk.org/jdk/pull/25740 From erikj at openjdk.org Wed Jun 11 08:07:28 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 11 Jun 2025 08:07:28 GMT Subject: RFR: 8359181: Error messages generated by configure --help after 8301197 In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 03:21:06 GMT, SendaoYan wrote: > Hi all, > > I have no idea why in make function `HELP_PRINT_ADDITIONAL_HELP_AND_EXIT` can use `$PRINTF` variable but can not use `$ECHO` varibale. This PR use `$PRINTF` instead of `$ECHO`. > > Change has been verified locally, almost no risk. This does not seem like the correct solution. This macro is only called directly from `make/autoconf/configure`, which is our wrapper script around the autoconf generated scripts. That wrapper expects this macro to be using `printf` so it sets `PRINTF=printf` on the command line: https://github.com/openjdk/jdk/blob/9586817cea3f1cad8a49d43e9106e25dafa04765/make/autoconf/configure#L369 In JDK-8301197, we changed most uses of `printf` to `echo`, but this explicit call wasn't updated to also set `ECHO=echo`. Doing that fixes the issue. ------------- PR Review: https://git.openjdk.org/jdk/pull/25740#pullrequestreview-2916080514 From syan at openjdk.org Wed Jun 11 08:56:25 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 11 Jun 2025 08:56:25 GMT Subject: RFR: 8359181: Error messages generated by configure --help after 8301197 [v2] In-Reply-To: References: Message-ID: <1iLLJh2klGKVaCncFQ5toeqxxpRchB8-G-o762jXIBw=.c42228af-cbaf-4805-a273-bbb8a6c4cc24@github.com> > Hi all, > > I have no idea why in make function `HELP_PRINT_ADDITIONAL_HELP_AND_EXIT` can use `$PRINTF` variable but can not use `$ECHO` varibale. This PR use `$PRINTF` instead of `$ECHO`. > > Change has been verified locally, almost no risk. SendaoYan has updated the pull request incrementally with two additional commits since the last revision: - add ECHO=echo when call generated configure script - Revert "8359181: Error messages generated by configure --help after 8301197" This reverts commit ffbd770f099030f72870c096eb9694d16cc2f34f. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25740/files - new: https://git.openjdk.org/jdk/pull/25740/files/ffbd770f..ede9e55b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25740&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25740&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25740/head:pull/25740 PR: https://git.openjdk.org/jdk/pull/25740 From erikj at openjdk.org Wed Jun 11 09:01:28 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 11 Jun 2025 09:01:28 GMT Subject: RFR: 8359181: Error messages generated by configure --help after 8301197 [v2] In-Reply-To: <1iLLJh2klGKVaCncFQ5toeqxxpRchB8-G-o762jXIBw=.c42228af-cbaf-4805-a273-bbb8a6c4cc24@github.com> References: <1iLLJh2klGKVaCncFQ5toeqxxpRchB8-G-o762jXIBw=.c42228af-cbaf-4805-a273-bbb8a6c4cc24@github.com> Message-ID: On Wed, 11 Jun 2025 08:56:25 GMT, SendaoYan wrote: >> Hi all, >> >> I have no idea why in make function `HELP_PRINT_ADDITIONAL_HELP_AND_EXIT` can use `$PRINTF` variable but can not use `$ECHO` varibale. This PR use `$PRINTF` instead of `$ECHO`. >> >> Change has been verified locally, almost no risk. > > SendaoYan has updated the pull request incrementally with two additional commits since the last revision: > > - add ECHO=echo when call generated configure script > - Revert "8359181: Error messages generated by configure --help after 8301197" > > This reverts commit ffbd770f099030f72870c096eb9694d16cc2f34f. I think this looks good, but please give Magnus a chance to review as his opinion may differ and this is more of his area than mine. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25740#pullrequestreview-2916251382 From syan at openjdk.org Wed Jun 11 09:07:28 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 11 Jun 2025 09:07:28 GMT Subject: RFR: 8359181: Error messages generated by configure --help after 8301197 [v2] In-Reply-To: References: Message-ID: <1ExJjPtMBmOpzqg0DO66aefXaKm8mcP1e6gtz3IQpUc=.55556f65-812e-4845-bd6f-174025800697@github.com> On Wed, 11 Jun 2025 08:05:00 GMT, Erik Joelsson wrote: > In JDK-8301197, we changed most uses of `printf` to `echo`, but this explicit call wasn't updated to also set `ECHO=echo`. Doing that fixes the issue. @erikj79 Thanks your correction, I have revert the original commit and add ` ECHO=echo` when call the mcaro, the PR description also updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25740#issuecomment-2961829536 From ihse at openjdk.org Wed Jun 11 12:13:29 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 11 Jun 2025 12:13:29 GMT Subject: RFR: 8359181: Error messages generated by configure --help after 8301197 [v2] In-Reply-To: <1iLLJh2klGKVaCncFQ5toeqxxpRchB8-G-o762jXIBw=.c42228af-cbaf-4805-a273-bbb8a6c4cc24@github.com> References: <1iLLJh2klGKVaCncFQ5toeqxxpRchB8-G-o762jXIBw=.c42228af-cbaf-4805-a273-bbb8a6c4cc24@github.com> Message-ID: On Wed, 11 Jun 2025 08:56:25 GMT, SendaoYan wrote: >> Hi all, >> >> The macro `HELP_PRINT_ADDITIONAL_HELP_AND_EXIT` is only called directly from make/autoconf/configure. In JDK-8301197, most uses of `printf` was changed to `echo`, but this explicit call wasn't updated to also set ` ECHO=echo`, this PR add ` ECHO=echo` when call this macro. >> >> Change has been verified locally, almost no risk. > > SendaoYan has updated the pull request incrementally with two additional commits since the last revision: > > - add ECHO=echo when call generated configure script > - Revert "8359181: Error messages generated by configure --help after 8301197" > > This reverts commit ffbd770f099030f72870c096eb9694d16cc2f34f. This looks like the proper solution. Thanks for finding and fixing. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25740#pullrequestreview-2916878473 From syan at openjdk.org Thu Jun 12 08:13:35 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 12 Jun 2025 08:13:35 GMT Subject: RFR: 8359181: Error messages generated by configure --help after 8301197 [v2] In-Reply-To: References: <1iLLJh2klGKVaCncFQ5toeqxxpRchB8-G-o762jXIBw=.c42228af-cbaf-4805-a273-bbb8a6c4cc24@github.com> Message-ID: <_8hC5qfxhR0vfxIKeImo1osPqtIkGG9W7BBM-kXU-lY=.950db29f-7295-46a0-bcaa-0bc067621f80@github.com> On Wed, 11 Jun 2025 12:11:03 GMT, Magnus Ihse Bursie wrote: >> SendaoYan has updated the pull request incrementally with two additional commits since the last revision: >> >> - add ECHO=echo when call generated configure script >> - Revert "8359181: Error messages generated by configure --help after 8301197" >> >> This reverts commit ffbd770f099030f72870c096eb9694d16cc2f34f. > > This looks like the proper solution. > > Thanks for finding and fixing. Thanks @magicus @erikj79 for the reviews and suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25740#issuecomment-2965579047 From syan at openjdk.org Thu Jun 12 08:13:35 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 12 Jun 2025 08:13:35 GMT Subject: Integrated: 8359181: Error messages generated by configure --help after 8301197 In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 03:21:06 GMT, SendaoYan wrote: > Hi all, > > The macro `HELP_PRINT_ADDITIONAL_HELP_AND_EXIT` is only called directly from make/autoconf/configure. In JDK-8301197, most uses of `printf` was changed to `echo`, but this explicit call wasn't updated to also set ` ECHO=echo`, this PR add ` ECHO=echo` when call this macro. > > Change has been verified locally, almost no risk. This pull request has now been integrated. Changeset: 7b7136b4 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/7b7136b4eca15693cfcd46ae63d644efc8a88d2c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8359181: Error messages generated by configure --help after 8301197 Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/jdk/pull/25740 From duke at openjdk.org Thu Jun 12 15:56:43 2025 From: duke at openjdk.org (Luigi Montoya) Date: Thu, 12 Jun 2025 15:56:43 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation Message-ID: Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries ------------- Commit messages: - Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh Changes: https://git.openjdk.org/jdk/pull/25259/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25259&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357079 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25259/head:pull/25259 PR: https://git.openjdk.org/jdk/pull/25259 From erikj at openjdk.org Fri Jun 13 06:45:31 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 13 Jun 2025 06:45:31 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: Message-ID: On Thu, 15 May 2025 22:16:34 GMT, Luigi Montoya wrote: > Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh > > The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries I think this is ok for now, but ideally we should either make a single devkit that can cross and native compile on both host archs, or explicitly create two different ones, one for each host arch. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25259#pullrequestreview-2923584391 From syan at openjdk.org Fri Jun 13 12:15:13 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 13 Jun 2025 12:15:13 GMT Subject: [jdk25] RFR: 8359181: Error messages generated by configure --help after 8301197 Message-ID: Hi all, This pull request contains a backport of commit [7b7136b4](https://github.com/openjdk/jdk/commit/7b7136b4eca15693cfcd46ae63d644efc8a88d2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by SendaoYan on 12 Jun 2025 and was reviewed by Erik Joelsson and Magnus Ihse Bursie. Thanks! ------------- Commit messages: - Backport 7b7136b4eca15693cfcd46ae63d644efc8a88d2c Changes: https://git.openjdk.org/jdk/pull/25800/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25800&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359181 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25800.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25800/head:pull/25800 PR: https://git.openjdk.org/jdk/pull/25800 From ihse at openjdk.org Fri Jun 13 13:04:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 13 Jun 2025 13:04:56 GMT Subject: [jdk25] RFR: 8359181: Error messages generated by configure --help after 8301197 In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 12:09:53 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [7b7136b4](https://github.com/openjdk/jdk/commit/7b7136b4eca15693cfcd46ae63d644efc8a88d2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 12 Jun 2025 and was reviewed by Erik Joelsson and Magnus Ihse Bursie. > > Thanks! Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25800#pullrequestreview-2924730867 From ihse at openjdk.org Fri Jun 13 14:01:43 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 13 Jun 2025 14:01:43 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: Message-ID: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> On Thu, 15 May 2025 22:16:34 GMT, Luigi Montoya wrote: > Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh > > The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries make/devkit/createWindowsDevkit.sh line 163: > 161: else > 162: cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/ > 163: fi It seems to make sense to have a single devkit since there seem to be a lot of overlap and not much additional code added to a cross-compiling devkit to also have native binaries. In fact, I could that not just be done as easily with something like: Suggestion: if [ -d "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" ]; then cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" $DEVKIT_ROOT/VC/bin/ fi if [ -d "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" ]; then cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/ fi Then of course we need to pick up the right set of compilers from the devkit, but I guess that would sort itself out if we know the build platform and are given the target platform as configure argument..? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2145165316 From duke at openjdk.org Fri Jun 13 19:29:41 2025 From: duke at openjdk.org (Luigi Montoya) Date: Fri, 13 Jun 2025 19:29:41 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: On Fri, 13 Jun 2025 13:58:48 GMT, Magnus Ihse Bursie wrote: >> Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh >> >> The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries > > make/devkit/createWindowsDevkit.sh line 163: > >> 161: else >> 162: cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/ >> 163: fi > > It seems to make sense to have a single devkit since there seem to be a lot of overlap and not much additional code added to a cross-compiling devkit to also have native binaries. > > In fact, I could that not just be done as easily with something like: > > > Suggestion: > > if [ -d "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" ]; then > cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" $DEVKIT_ROOT/VC/bin/ > fi > if [ -d "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" ]; then > cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/ > fi > > > Then of course we need to pick up the right set of compilers from the devkit, but I guess that would sort itself out if we know the build platform and are given the target platform as configure argument..? I was thinking we could create the devkit based on the platform where the script is being run. For example, running `createWindowsDevkit.sh` on: - Windows x64 would produce: - Native x86 libraries - Native x64 libraries - Cross-compiled aarch64 libraries - Windows aarch64 would produce: - Native x86 libraries - Native x64 libraries - Native aarch64 libraries >From my analysis of your code suggestion, it looks like it might override the native aarch64 libraries and always set the cross-compiled ones. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2145929505 From syan at openjdk.org Sat Jun 14 11:10:46 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 14 Jun 2025 11:10:46 GMT Subject: RFR: 8339355: Test build/AbsPathsInImage.java fails configure with --enable-ccache Message-ID: Hi all, The debuginfo file will not ship to customers generally, so I think it's not necessary to check the debuginfo files contains absolutive path or not. And I can't find why the debuginfo file always contains workspace path info with --enable-ccache configure option. ------------- Commit messages: - 8339355: Test build/AbsPathsInImage.java fails configure with --enable-ccache Changes: https://git.openjdk.org/jdk/pull/25811/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25811&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339355 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25811.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25811/head:pull/25811 PR: https://git.openjdk.org/jdk/pull/25811 From ihse at openjdk.org Sat Jun 14 12:02:31 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sat, 14 Jun 2025 12:02:31 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: On Fri, 13 Jun 2025 19:27:20 GMT, Luigi Montoya wrote: >> make/devkit/createWindowsDevkit.sh line 163: >> >>> 161: else >>> 162: cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/ >>> 163: fi >> >> It seems to make sense to have a single devkit since there seem to be a lot of overlap and not much additional code added to a cross-compiling devkit to also have native binaries. >> >> In fact, I could that not just be done as easily with something like: >> >> >> Suggestion: >> >> if [ -d "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" ]; then >> cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" $DEVKIT_ROOT/VC/bin/ >> fi >> if [ -d "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" ]; then >> cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/ >> fi >> >> >> Then of course we need to pick up the right set of compilers from the devkit, but I guess that would sort itself out if we know the build platform and are given the target platform as configure argument..? > > I was thinking we could create the devkit based on the platform where the script is being run. For example, running `createWindowsDevkit.sh` on: > > - Windows x64 would produce: > - Native x86 libraries > - Native x64 libraries > - Cross-compiled aarch64 libraries > - Windows aarch64 would produce: > - Native x86 libraries > - Native x64 libraries > - Native aarch64 libraries > > From my analysis of your code suggestion, it looks like it might override the native aarch64 libraries and always set the cross-compiled ones. What do you think? I agree with your general premise, that the devkit should be created for the platform the devkit script is run on. When you say that you should produce "native" x64 libraries on aarch64, do you mean that they should be run using x64 emulation? Otherwise you can't really have native x64 on aarch64... And even if that works, would it not be better to have pure native aarch64 cross-compiling to x64 (given that Microsoft in fact ships such compilers). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2146881036 From duke at openjdk.org Sun Jun 15 04:53:39 2025 From: duke at openjdk.org (Luigi Montoya) Date: Sun, 15 Jun 2025 04:53:39 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: On Sat, 14 Jun 2025 11:59:32 GMT, Magnus Ihse Bursie wrote: >> I was thinking we could create the devkit based on the platform where the script is being run. For example, running `createWindowsDevkit.sh` on: >> >> - Windows x64 would produce: >> - Native x86 libraries >> - Native x64 libraries >> - Cross-compiled aarch64 libraries >> - Windows aarch64 would produce: >> - Native x86 libraries >> - Native x64 libraries >> - Native aarch64 libraries >> >> From my analysis of your code suggestion, it looks like it might override the native aarch64 libraries and always set the cross-compiled ones. What do you think? > > I agree with your general premise, that the devkit should be created for the platform the devkit script is run on. > > When you say that you should produce "native" x64 libraries on aarch64, do you mean that they should be run using x64 emulation? Otherwise you can't really have native x64 on aarch64... And even if that works, would it not be better to have pure native aarch64 cross-compiling to x64 (given that Microsoft in fact ships such compilers). When you download the Visual Studio Build Tools on an ARM64 machine, it downloads the native binaries for the `x64` architecture under `Hostx64` and the native binaries for `arm64` under `Hostarm64`. This devkit script does not generate any binaries; it simply copies the Build Tools from Visual Studio. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2147426849 From kbarrett at openjdk.org Sun Jun 15 05:21:29 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 15 Jun 2025 05:21:29 GMT Subject: RFR: 8319242: HotSpot Style Guide should discourage non-local variables with non-trivial initialization or destruction Message-ID: Please review this change to the HotSpot Style Guide to add discussion of how we prefer to handle initialization and destruction of non-local variables. I propose this is an editorial change, as it just documents current practice rather than suggesting a change to current practice. As such, the normal HotSpot PR process applies. The updated .html file was generated using make update-build-docs. ------------- Commit messages: - static variable inits Changes: https://git.openjdk.org/jdk/pull/25812/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25812&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319242 Stats: 39 lines in 2 files changed: 39 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25812.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25812/head:pull/25812 PR: https://git.openjdk.org/jdk/pull/25812 From syan at openjdk.org Sun Jun 15 12:27:31 2025 From: syan at openjdk.org (SendaoYan) Date: Sun, 15 Jun 2025 12:27:31 GMT Subject: [jdk25] RFR: 8359181: Error messages generated by configure --help after 8301197 In-Reply-To: References: Message-ID: <1OHIaxSIJYr9ew162DmW9uMC9un7sA1ZxXT-szoDJpo=.3f6ce960-a80b-4f79-8d33-19d348614c5f@github.com> On Fri, 13 Jun 2025 12:09:53 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [7b7136b4](https://github.com/openjdk/jdk/commit/7b7136b4eca15693cfcd46ae63d644efc8a88d2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 12 Jun 2025 and was reviewed by Erik Joelsson and Magnus Ihse Bursie. > > Thanks! Thanks for the approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25800#issuecomment-2973756258 From syan at openjdk.org Sun Jun 15 12:27:32 2025 From: syan at openjdk.org (SendaoYan) Date: Sun, 15 Jun 2025 12:27:32 GMT Subject: [jdk25] Integrated: 8359181: Error messages generated by configure --help after 8301197 In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 12:09:53 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [7b7136b4](https://github.com/openjdk/jdk/commit/7b7136b4eca15693cfcd46ae63d644efc8a88d2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 12 Jun 2025 and was reviewed by Erik Joelsson and Magnus Ihse Bursie. > > Thanks! This pull request has now been integrated. Changeset: 3877746e Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/3877746eb9c5f96b60fdc14fc7be5a4a71152718 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8359181: Error messages generated by configure --help after 8301197 Reviewed-by: ihse Backport-of: 7b7136b4eca15693cfcd46ae63d644efc8a88d2c ------------- PR: https://git.openjdk.org/jdk/pull/25800 From erikj at openjdk.org Mon Jun 16 07:00:30 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 16 Jun 2025 07:00:30 GMT Subject: RFR: 8339355: Test build/AbsPathsInImage.java fails configure with --enable-ccache In-Reply-To: References: Message-ID: On Sat, 14 Jun 2025 03:51:28 GMT, SendaoYan wrote: > Hi all, > > The debuginfo file will not ship to customers generally, so I think it's not necessary to check the debuginfo files contains absolutive path or not. And I can't find why the debuginfo file always contains workspace path info with --enable-ccache configure option. We do expect the debuginfo files to be reproducible and hence free of absolute paths. This was implemented in https://bugs.openjdk.org/browse/JDK-8284437, where `-fdebug-prefix-map` was one of the mitigations applied. I would start my investigation with trying to understand why that option isn't working, or being applied, when you build with `--enable-ccache`. ------------- Changes requested by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25811#pullrequestreview-2930845917 From syan at openjdk.org Mon Jun 16 08:59:30 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 16 Jun 2025 08:59:30 GMT Subject: RFR: 8339355: Test build/AbsPathsInImage.java fails configure with --enable-ccache In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 06:57:35 GMT, Erik Joelsson wrote: > We do expect the debuginfo files to be reproducible and hence free of absolute paths. This was implemented in https://bugs.openjdk.org/browse/JDK-8284437, where `-fdebug-prefix-map` was one of the mitigations applied. I would start my investigation with trying to understand why that option isn't working, or being applied, when you build with `--enable-ccache`. Thanks @erikj79 I can not find the root cause how does the debuginfo files contains the absolute paths. Take java.debuginfo example, this file generate by `objcopy --only-keep-debug build/ccache/support/modules_cmds/java.base/java build/ccache/support/modules_cmds/java.base/java.debuginfo`, the source file `build/ccache/support/modules_cmds/java.base/java` contains absolute path string `DW_AT_comp_dir /hygonjdk/yansendao/git/jdk` shows as below: > dwarfdump build/ccache/support/modules_cmds/java.base/java | grep DW_AT_comp_dir DW_AT_comp_dir /hygonjdk/yansendao/git/jdk DW_AT_comp_dir /hygonjdk/yansendao/git/jdk The file `build/ccache/support/modules_cmds/java.base/java` linked from libjli.so and main.o, and the main.o already contains `DW_AT_comp_dir` absolute path when enable ccache. I can't find the difference between with ccache and without ccache when generate main.o ------------- PR Comment: https://git.openjdk.org/jdk/pull/25811#issuecomment-2975666685 From erikj at openjdk.org Mon Jun 16 09:06:29 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 16 Jun 2025 09:06:29 GMT Subject: RFR: 8339355: Test build/AbsPathsInImage.java fails configure with --enable-ccache In-Reply-To: References: Message-ID: On Sat, 14 Jun 2025 03:51:28 GMT, SendaoYan wrote: > Hi all, > > The debuginfo file will not ship to customers generally, so I think it's not necessary to check the debuginfo files contains absolutive path or not. And I can't find why the debuginfo file always contains workspace path info with --enable-ccache configure option. In a bug comment you said that adding `-fdebug-prefix-map` worked around most of them, but in the example you added the option using `--with-extra-cflags`. This option is supposed to be added automatically anyway, so you observing a difference when explicitly adding the flag leads me to believe there is some difference in options when you enable ccache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25811#issuecomment-2975689358 From ihse at openjdk.org Mon Jun 16 13:41:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Jun 2025 13:41:32 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: On Sun, 15 Jun 2025 04:50:40 GMT, Luigi Montoya wrote: >> I agree with your general premise, that the devkit should be created for the platform the devkit script is run on. >> >> When you say that you should produce "native" x64 libraries on aarch64, do you mean that they should be run using x64 emulation? Otherwise you can't really have native x64 on aarch64... And even if that works, would it not be better to have pure native aarch64 cross-compiling to x64 (given that Microsoft in fact ships such compilers). > > When you download the Visual Studio Build Tools on an ARM64 machine, it downloads the native binaries for the `x64` architecture under `Hostx64` and the native binaries for `arm64` under `Hostarm64`. This devkit script does not generate any binaries; it simply copies the Build Tools from Visual Studio. I find this confusing, but that's probably since I don't understand what Microsoft is shipping and where. There are 4 relevant compilers: 1) A compiler that runs on x64 and generates x64 code (x64 native compilation) 2) A compiler that runs on x64 and generates aarch64 code (aarch64 cross-compilation on x64) 3) A compiler that runs on aarch64 and generates aarch64 code (aarch64 native compilation) 4) A compiler that runs on aarch64 and generates x64 code (x64 cross-compilation on aarch64) For a devkit targeting x64, 1) and 2) should be included. For a devkit targeting aarch64, 3) (and ideally 4) as well) should be included. Are you saying that if you download VS on aarch64, you will get all four compilers installed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2150037490 From duke at openjdk.org Mon Jun 16 17:31:32 2025 From: duke at openjdk.org (Luigi Montoya) Date: Mon, 16 Jun 2025 17:31:32 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: On Mon, 16 Jun 2025 13:38:34 GMT, Magnus Ihse Bursie wrote: >> When you download the Visual Studio Build Tools on an ARM64 machine, it downloads the native binaries for the `x64` architecture under `Hostx64` and the native binaries for `arm64` under `Hostarm64`. This devkit script does not generate any binaries; it simply copies the Build Tools from Visual Studio. > > I find this confusing, but that's probably since I don't understand what Microsoft is shipping and where. > > There are 4 relevant compilers: > 1) A compiler that runs on x64 and generates x64 code (x64 native compilation) > 2) A compiler that runs on x64 and generates aarch64 code (aarch64 cross-compilation on x64) > 3) A compiler that runs on aarch64 and generates aarch64 code (aarch64 native compilation) > 4) A compiler that runs on aarch64 and generates x64 code (x64 cross-compilation on aarch64) > > For a devkit targeting x64, 1) and 2) should be included. For a devkit targeting aarch64, 3) (and ideally 4) as well) should be included. > > Are you saying that if you download VS on aarch64, you will get all four compilers installed? Yes, if I download VS on aarch64 I get the four compilers installed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2150506976 From ihse at openjdk.org Tue Jun 17 14:13:33 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 17 Jun 2025 14:13:33 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: On Mon, 16 Jun 2025 17:29:04 GMT, Luigi Montoya wrote: >> I find this confusing, but that's probably since I don't understand what Microsoft is shipping and where. >> >> There are 4 relevant compilers: >> 1) A compiler that runs on x64 and generates x64 code (x64 native compilation) >> 2) A compiler that runs on x64 and generates aarch64 code (aarch64 cross-compilation on x64) >> 3) A compiler that runs on aarch64 and generates aarch64 code (aarch64 native compilation) >> 4) A compiler that runs on aarch64 and generates x64 code (x64 cross-compilation on aarch64) >> >> For a devkit targeting x64, 1) and 2) should be included. For a devkit targeting aarch64, 3) (and ideally 4) as well) should be included. >> >> Are you saying that if you download VS on aarch64, you will get all four compilers installed? > > Yes, if I download VS on aarch64 I get the four compilers installed. Is this the case when downloading VS on x64 as well, that you get a binary that can only be run on aarch64 bundled too? Or is the x64 installation just a subset of the aarch64 installation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2152384048 From duke at openjdk.org Tue Jun 17 17:59:32 2025 From: duke at openjdk.org (Luigi Montoya) Date: Tue, 17 Jun 2025 17:59:32 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: On Tue, 17 Jun 2025 14:10:29 GMT, Magnus Ihse Bursie wrote: >> Yes, if I download VS on aarch64 I get the four compilers installed. > > Is this the case when downloading VS on x64 as well, that you get a binary that can only be run on aarch64 bundled too? Or is the x64 installation just a subset of the aarch64 installation? When you download VS on x64 you just get cross-compilers for aarch64 (I don't know why). The `Hostarm64` directory is not created in x64 machines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2152853051 From duke at openjdk.org Wed Jun 18 09:41:35 2025 From: duke at openjdk.org (duke) Date: Wed, 18 Jun 2025 09:41:35 GMT Subject: Withdrawn: 8352693: Use a simpler console reader instead of JLine for System.console() In-Reply-To: References: Message-ID: <2x0dTfpcu1MdxTVpRSizOlN_dEsobjFzk2uXRNu3-D0=.06f77c08-90d1-4b0c-8aab-603eb1d530bb@github.com> On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24242 From lucy at openjdk.org Wed Jun 18 16:12:35 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 18 Jun 2025 16:12:35 GMT Subject: RFR: 8351440: Link with -reproducible on macOS In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt wrote: > Background (from JBS): > > Recent versions of Xcode, most likely starting with Xcode 15, do not produce deterministic binaries/libraries out of the box. In particular, the UUID data in the LC_UUID load command is not stable. > > After spending some significant time trying to understand why, it turns out that the linker has started including the last modified time stamp of the object files in the (debug?) data and that time stamp data is included in the computed UUID "hash". So even if the rest of the data is the same between two builds, the build time (or, more accurately, the time when the object file gets written to the file system) now affects the UUID and therefore the data of the resulting .dylib files. > > It seems (unconfirmed) like this may be an artifact of Xcode 15 using a new linker ("ld-prime") which may or may not be why the behavior has changed. > > After spending even more time trying to understand what to do about it I noticed this in the ld man page: > > -reproducible > By default output content will be deterministic, but small changes in input files such as a compilation time might affect certain data structures in the linked binary. This option instructs ld to create a reproducible output binary by ignoring certain input properties or using alternative algorithms. > > And, adding that flag (-Wl,-reproducible to clang) does indeed seem to solve the issue. > > Testing: > > * Manual verification with both Xcode14.3.1 and Xcode 15.4 > * tier1,builds-tier[2-5] This change breaks the build with Xcode13. I have opened JDK-8359946 to track the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23949#issuecomment-2984868570 From ihse at openjdk.org Thu Jun 19 14:12:45 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 19 Jun 2025 14:12:45 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> Message-ID: <0mCnksS2nmtnnKep-zopcjupHj0w_9m2JDDBvy6MElY=.80bc277f-bba3-4a81-93a6-6dfe836b3deb@github.com> On Tue, 17 Jun 2025 17:57:06 GMT, Luigi Montoya wrote: >> Is this the case when downloading VS on x64 as well, that you get a binary that can only be run on aarch64 bundled too? Or is the x64 installation just a subset of the aarch64 installation? > > When you download VS on x64 you just get cross-compilers for aarch64 (I don't know why). The `Hostarm64` directory is not created in x64 machines. So if we run the devkit script on an aarch64 machine, we can create a devkit that will work on both x64 and aarch64? But if we run it on x64, the devkit that we create will only work on x64? Have I got this right? If so, I think the script should support this, and make it clear what it does. That is, if you run it on aarch64, you get a multi-platform devkit, but on x64 you get a x64-only devkit. I think the devkit script should mention this, ideally in an `echo` statement, but a comment in the source code is acceptable. Like: `You are generating a devkit for x64 only. To include aarch64 as well, run the script on windows/aarch64` and `Generating devkit for x64 and aarch64`, respectively. Or something like that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2157119798 From magnus.ihse.bursie at oracle.com Thu Jun 19 15:06:59 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 19 Jun 2025 17:06:59 +0200 Subject: clang Memory sanitizer (msan) and OpenJDK In-Reply-To: References: <2f767360-8c81-48f0-8374-344e47865748@oracle.com> Message-ID: <24794f68-a6d6-40ab-86d3-ecf38928d153@oracle.com> Hi Matthias, Getting back to this far too late... Sorry. On 2025-04-30 15:28, Baesken, Matthias wrote: > I installed the llvm package to get the ??/usr/bin/llvm-symbolizer?? > (this seems to be needed to get? meaningful stacks) . > > Brought back the visibility=hidden settings, seems they do no harm? to > msan? .?? However the removal ?of -Wl,--exclude-libs,ALL????? is needed. > I think there might be ways around that to tell the linker to actually keep the symbols we need. If you want to pursue integrating msan into the JDK build properly, we can explore that. If so, we should also check for the presence of llvm-symbolizer in configure and warn if it is missing (though I guess the real question is if it is present at runtime...). > Seems msan is unhappy about the thread != nullptr?? in line 81? of > jfrThreadLocal.cpp > > ? Thread* thread = Thread::current_or_null(); > > ? _parent_trace_id = thread != nullptr ? jvm_thread_id(thread) : > (traceid)0; > > Not sure why this is reported as? uninitialized ? > I have no idea. Did you pursue this any further, or did you give up? /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jun 19 23:52:29 2025 From: duke at openjdk.org (Luigi Montoya) Date: Thu, 19 Jun 2025 23:52:29 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: <0mCnksS2nmtnnKep-zopcjupHj0w_9m2JDDBvy6MElY=.80bc277f-bba3-4a81-93a6-6dfe836b3deb@github.com> References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> <0mCnksS2nmtnnKep-zopcjupHj0w_9m2JDDBvy6MElY=.80bc277f-bba3-4a81-93a6-6dfe836b3deb@github.com> Message-ID: On Thu, 19 Jun 2025 14:09:47 GMT, Magnus Ihse Bursie wrote: >> When you download VS on x64 you just get cross-compilers for aarch64 (I don't know why). The `Hostarm64` directory is not created in x64 machines. > > So if we run the devkit script on an aarch64 machine, we can create a devkit that will work on both x64 and aarch64? But if we run it on x64, the devkit that we create will only work on x64? Have I got this right? > > If so, I think the script should support this, and make it clear what it does. That is, if you run it on aarch64, you get a multi-platform devkit, but on x64 you get a x64-only devkit. I think the devkit script should mention this, ideally in an `echo` statement, but a comment in the source code is acceptable. Like: > `You are generating a devkit for x64 only. To include aarch64 as well, run the script on windows/aarch64` and `Generating devkit for x64 and aarch64`, respectively. Or something like that. I was planning adding something like this: # Detect host architecture to determine devkit platform support # Note: The devkit always includes x86, x64, and aarch64 libraries and tools # The difference is in toolchain capabilities: # - On x64|AMD64 hosts: aarch64 tools are cross-compilation tools (Hostx64/arm64) # - On aarch64|ARMv8 hosts: aarch64 tools are native tools (Hostarm64/arm64) HOST_ARCH=`echo $PROCESSOR_IDENTIFIER` case $HOST_ARCH in AMD64) echo "Running on x64 host - generating devkit with native x86/x64 tools and cross-compiled aarch64 tools." echo "For native aarch64 compilation tools, run this script on a Windows/aarch64 machine." SUPPORTED_PLATFORMS="x86, x64 (native) and aarch64 (cross-compiled)" ;; ARMv8) echo "Running on aarch64 host - generating devkit with native tools for all platforms (x86, x64, aarch64)." SUPPORTED_PLATFORMS="x86, x64, and aarch64 (all native)" ;; *) echo "Unknown host architecture: $HOST_ARCH" echo "Proceeding with devkit generation - toolchain capabilities may vary." SUPPORTED_PLATFORMS="x86, x64, and aarch64" ;; esac ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2157794144 From matthias.baesken at sap.com Fri Jun 20 05:46:18 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 20 Jun 2025 05:46:18 +0000 Subject: clang Memory sanitizer (msan) and OpenJDK In-Reply-To: <24794f68-a6d6-40ab-86d3-ecf38928d153@oracle.com> References: <2f767360-8c81-48f0-8374-344e47865748@oracle.com> <24794f68-a6d6-40ab-86d3-ecf38928d153@oracle.com> Message-ID: Hi Magnus, > I think there might be ways around that to tell the linker to actually keep the symbols we need. If you want to pursue integrating msan into the JDK build properly, we can explore that. I am still a bit unsure about integrating the msan support , because with just the msan support in the m4+makefiles , but still msan-related runtime issues showing up in the build, It would not be very helpful for the developers. (on the other hand, ubsan in OpenJDK was some months ago also only supported in the m4+makefiles but needed ?repair? regarding source adjustments because issues already showed up in the build ) >>Seems msan is unhappy about the thread != nullptr in line 81 of jfrThreadLocal.cpp >I have no idea. Did you pursue this any further, or did you give up? I updated to a higher version of clang (17) and then the issue was gone ; but unfortunately there are more msan ? related issues reported in Hotspot already in the build process . And different to ubsan/asan , for me the msan issues are harder to understand (but maybe I am just not used to the reports yet ) . Maybe , let?s see what comes out of this one https://bugs.openjdk.org/browse/JDK-8356285 . (sometimes the HS codebase seem to does things that are not liked by MSAN ; maybe the JDK native libs are easier to support for MSAN ) Best regards, Matthias From: Magnus Ihse Bursie Sent: Thursday, 19 June 2025 17:07 To: Baesken, Matthias ; build-dev at openjdk.org Subject: Re: clang Memory sanitizer (msan) and OpenJDK Hi Matthias, Getting back to this far too late... Sorry. On 2025-04-30 15:28, Baesken, Matthias wrote: I installed the llvm package to get the /usr/bin/llvm-symbolizer (this seems to be needed to get meaningful stacks) . Brought back the visibility=hidden settings, seems they do no harm to msan . However the removal of -Wl,--exclude-libs,ALL is needed. I think there might be ways around that to tell the linker to actually keep the symbols we need. If you want to pursue integrating msan into the JDK build properly, we can explore that. If so, we should also check for the presence of llvm-symbolizer in configure and warn if it is missing (though I guess the real question is if it is present at runtime...). Seems msan is unhappy about the thread != nullptr in line 81 of jfrThreadLocal.cpp Thread* thread = Thread::current_or_null(); _parent_trace_id = thread != nullptr ? jvm_thread_id(thread) : (traceid)0; Not sure why this is reported as uninitialized ? I have no idea. Did you pursue this any further, or did you give up? /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Fri Jun 20 09:06:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 20 Jun 2025 09:06:46 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 Message-ID: See the bug for extended details about this little mess. ------------- Commit messages: - Try 14.44 Changes: https://git.openjdk.org/jdk/pull/25912/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25912&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360042 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25912/head:pull/25912 PR: https://git.openjdk.org/jdk/pull/25912 From shade at openjdk.org Fri Jun 20 09:06:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 20 Jun 2025 09:06:46 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: <1BdD0UA-xKY7ghDrquZ1c4abeXoQOdVxWTVe69s5wGw=.d4fccffa-eaf6-461a-b8f5-e80e3a1e6a61@github.com> On Fri, 20 Jun 2025 08:36:30 GMT, Aleksey Shipilev wrote: > See the bug for extended details about this little mess. Great, I can see that new runner image does _not_ like `14.43`. So we are in weird spot at the moment: - Old runner image works with `14.43`, fails with `14.44` - New runner image fails with `14.43`, works with `14.44` - Old -> new runner image is currently deploying. About 1/4 of jobs I have seen still get the old runner image at the moment of writing. Given that new runner image would eventually deploy everywhere, this IMO leaves us with no choice but to do the `14.44` switch now. On the up-side, compared to `14.43`, `14.44` is actually claimed to be available by runner docs. With `14.43`, we are playing with fire anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25912#issuecomment-2990360772 From duke at openjdk.org Fri Jun 20 11:19:29 2025 From: duke at openjdk.org (Antonio Vieiro) Date: Fri, 20 Jun 2025 11:19:29 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 08:36:30 GMT, Aleksey Shipilev wrote: > See the bug for extended details about this little mess. Looks like [it cannot find a C compiler](https://github.com/openjdk/jdk/blob/8f121a173ca2534c706682f6c68fbbb0b94ec057/make/autoconf/toolchain.m4#L469) on `windows-x64`... [...] 2025-06-20T08:34:28.2275609Z configure: Using default toolchain microsoft (Microsoft Visual Studio) 2025-06-20T08:34:28.4899994Z configure: Found Visual Studio installation at /c/progra~1/micros~2/2022/Enterprise using well-known name 2025-06-20T08:34:28.5299183Z configure: Found Microsoft Visual Studio 2022 2025-06-20T08:34:28.5300257Z configure: Trying to extract Visual Studio environment variables for x86_64 2025-06-20T08:34:28.5301467Z configure: using /c/progra~1/micros~2/2022/Enterprise/vc/auxiliary/build/vcvars64.bat 2025-06-20T08:34:30.0458930Z configure: Setting extracted environment variables for x86_64 2025-06-20T08:34:30.3769850Z fixpath: warning: Path '/usr/local/bin' does not exist 2025-06-20T08:34:32.5499412Z fixpath: warning: Path '/usr/local/bin' does not exist 2025-06-20T08:34:35.7021325Z checking that Visual Studio variables have been correctly extracted... ok 2025-06-20T08:34:35.7345790Z checking for cl... [not found] 2025-06-20T08:34:35.7347978Z configure: error: Could not find a C compiler. 2025-06-20T08:34:36.0019320Z configure exiting with result code 1 [...] FWIW, `14.43` seems [to be working fine](https://productionresultssa3.blob.core.windows.net/actions-results/ee259f6d-c52b-49ab-b70e-5c3ac1fd3f15/workflow-job-run-233d989f-1ab3-5306-842b-9e6af22e8bbf/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-06-20T11%3A21%3A25Z&sig=GvC8FxjOUXDvI%2FOVhxP27xGILFgIpepFQOKXzJ%2BXztI%3D&ske=2025-06-20T21%3A09%3A02Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-06-20T09%3A09%3A02Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-05-05&sp=r&spr=https&sr=b&st=2025-06-20T11%3A11%3A20Z&sv=2025-05-05) for JDK11 with the `windows-2022` / `14.43` combo: 2025-06-19T09:38:02.7046848Z configure: Using default toolchain microsoft (Microsoft Visual Studio) 2025-06-19T09:38:04.0725116Z configure: Found Visual Studio installation at /c/progra~1/micros~2/2022/Enterprise using well-known name 2025-06-19T09:38:04.1167106Z configure: Found Microsoft Visual Studio 2022 2025-06-19T09:38:04.1168531Z configure: Trying to extract Visual Studio environment variables for x86_64 2025-06-19T09:38:04.1170307Z configure: using /c/progra~1/micros~2/2022/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat 2025-06-19T09:38:05.5593722Z configure: Setting extracted environment variables for x86_64 2025-06-19T09:38:11.3981042Z checking that Visual Studio variables have been correctly extracted... ok 2025-06-19T09:38:11.7820392Z checking for cl... $FIXPATH /c/progra~1/micros~2/2022/enterp~1/vc/tools/msvc/1443~1.348/bin/hostx86/x64/cl.exe 2025-06-19T09:38:11.7830069Z checking resolved symbolic links for CC... no symlink 2025-06-19T09:38:12.0841912Z configure: Using microsoft C compiler version 19.43.34808 [Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34808 for x64] 2025-06-19T09:38:20.8009463Z checking whether the C compiler works... yes 2025-06-19T09:38:20.8010308Z checking for C compiler default output file name... conftest.exe 2025-06-19T09:38:21.0792832Z checking for suffix of executables... .exe ------------- PR Comment: https://git.openjdk.org/jdk/pull/25912#issuecomment-2991059210 From shade at openjdk.org Fri Jun 20 11:59:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 20 Jun 2025 11:59:28 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 11:16:52 GMT, Antonio Vieiro wrote: >> See the bug for extended details about this little mess. > > Looks like [it cannot find a C compiler](https://github.com/openjdk/jdk/blob/8f121a173ca2534c706682f6c68fbbb0b94ec057/make/autoconf/toolchain.m4#L469) on `windows-x64`... > > > [...] > 2025-06-20T08:34:28.2275609Z configure: Using default toolchain microsoft (Microsoft Visual Studio) > 2025-06-20T08:34:28.4899994Z configure: Found Visual Studio installation at /c/progra~1/micros~2/2022/Enterprise using well-known name > 2025-06-20T08:34:28.5299183Z configure: Found Microsoft Visual Studio 2022 > 2025-06-20T08:34:28.5300257Z configure: Trying to extract Visual Studio environment variables for x86_64 > 2025-06-20T08:34:28.5301467Z configure: using /c/progra~1/micros~2/2022/Enterprise/vc/auxiliary/build/vcvars64.bat > 2025-06-20T08:34:30.0458930Z configure: Setting extracted environment variables for x86_64 > 2025-06-20T08:34:30.3769850Z fixpath: warning: Path '/usr/local/bin' does not exist > 2025-06-20T08:34:32.5499412Z fixpath: warning: Path '/usr/local/bin' does not exist > 2025-06-20T08:34:35.7021325Z checking that Visual Studio variables have been correctly extracted... ok > 2025-06-20T08:34:35.7345790Z checking for cl... [not found] > 2025-06-20T08:34:35.7347978Z configure: error: Could not find a C compiler. > 2025-06-20T08:34:36.0019320Z configure exiting with result code 1 > [...] > > > FWIW, `14.43` seems [to be working fine](https://productionresultssa3.blob.core.windows.net/actions-results/ee259f6d-c52b-49ab-b70e-5c3ac1fd3f15/workflow-job-run-233d989f-1ab3-5306-842b-9e6af22e8bbf/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-06-20T11%3A21%3A25Z&sig=GvC8FxjOUXDvI%2FOVhxP27xGILFgIpepFQOKXzJ%2BXztI%3D&ske=2025-06-20T21%3A09%3A02Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-06-20T09%3A09%3A02Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-05-05&sp=r&spr=https&sr=b&st=2025-06-20T11%3A11%3A20Z&sv=2025-05-05) for JDK11 with the `windows-2022` / `14.43` combo: > > > 2025-06-19T09:38:02.7046848Z configure: Using default toolchain microsoft (Microsoft Visual Studio) > 2025-06-19T09:38:04.0725116Z configure: Found Visual Studio installation at /c/progra~1/micros~2/2022/Enterprise using well-known name > 2025-06-19T09:38:04.1167106Z configure: Found Microsoft Visual Studio 2022 > 2025-06-19T09:38:04.1168531Z configure: Trying to extract Visual Studio environment variables for x86_64 > 2025-06-19T09:38:04.1170307Z configure: using /c/progra~1/micros~2/2022/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat > 2025-06-19T09:38:05.5593722Z configure: Setting extracted environment vari... @vieiro, please read this comment: https://github.com/openjdk/jdk/pull/25912#issuecomment-2990360772 -- we are in transient state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25912#issuecomment-2991234994 From shade at openjdk.org Mon Jun 23 08:09:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 23 Jun 2025 08:09:14 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 [v2] In-Reply-To: References: Message-ID: > See the bug for extended details about this little mess. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Try 14.44 ------------- Changes: https://git.openjdk.org/jdk/pull/25912/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25912&range=01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25912/head:pull/25912 PR: https://git.openjdk.org/jdk/pull/25912 From shade at openjdk.org Mon Jun 23 08:09:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 23 Jun 2025 08:09:14 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 08:36:30 GMT, Aleksey Shipilev wrote: > See the bug for extended details about this little mess. Looks like `20250617.1.0` runner image have been deployed. We can go in with this PR now. Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25912#issuecomment-2995376969 From erikj at openjdk.org Mon Jun 23 08:59:30 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 23 Jun 2025 08:59:30 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 08:09:14 GMT, Aleksey Shipilev wrote: >> See the bug for extended details about this little mess. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > Try 14.44 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25912#pullrequestreview-2949244492 From ihse at openjdk.org Mon Jun 23 09:23:30 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 23 Jun 2025 09:23:30 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 08:09:14 GMT, Aleksey Shipilev wrote: >> See the bug for extended details about this little mess. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > Try 14.44 As you say, it probably can't get worse. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25912#pullrequestreview-2949321421 From shade at openjdk.org Mon Jun 23 12:49:35 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 23 Jun 2025 12:49:35 GMT Subject: RFR: 8360042: GHA: Bump MSVC to 14.44 [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 08:09:14 GMT, Aleksey Shipilev wrote: >> See the bug for extended details about this little mess. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > Try 14.44 2x GHA run is clean. > As you say, it probably can't get worse. We shall see about that! :) _To err is human, to propagate an error to thousands of computers is DevOps._ ------------- PR Comment: https://git.openjdk.org/jdk/pull/25912#issuecomment-2996358717 From shade at openjdk.org Mon Jun 23 12:49:35 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 23 Jun 2025 12:49:35 GMT Subject: Integrated: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 08:36:30 GMT, Aleksey Shipilev wrote: > See the bug for extended details about this little mess. This pull request has now been integrated. Changeset: 72679c94 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/72679c94ee00c87b9b51233938e5ffa97ef825b1 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8360042: GHA: Bump MSVC to 14.44 Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/jdk/pull/25912 From ihse at openjdk.org Mon Jun 23 14:31:30 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 23 Jun 2025 14:31:30 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: <76gnn0ePeyAu1iHrq4s8tj5wiaBJTjhzl1NsqIOAV8Y=.d7108738-8eae-42dc-bae9-b532fa4980e1@github.com> <0mCnksS2nmtnnKep-zopcjupHj0w_9m2JDDBvy6MElY=.80bc277f-bba3-4a81-93a6-6dfe836b3deb@github.com> Message-ID: <9HnKVxOrhxVD2NNmhOD4B3PyrGWbV66ksQQIo8VOIbk=.d5597822-7059-41ed-83ab-b2c3c320ae5e@github.com> On Thu, 19 Jun 2025 23:49:24 GMT, Luigi Montoya wrote: >> So if we run the devkit script on an aarch64 machine, we can create a devkit that will work on both x64 and aarch64? But if we run it on x64, the devkit that we create will only work on x64? Have I got this right? >> >> If so, I think the script should support this, and make it clear what it does. That is, if you run it on aarch64, you get a multi-platform devkit, but on x64 you get a x64-only devkit. I think the devkit script should mention this, ideally in an `echo` statement, but a comment in the source code is acceptable. Like: >> `You are generating a devkit for x64 only. To include aarch64 as well, run the script on windows/aarch64` and `Generating devkit for x64 and aarch64`, respectively. Or something like that. > > I was planning adding something like this: > > # Detect host architecture to determine devkit platform support > # Note: The devkit always includes x86, x64, and aarch64 libraries and tools > # The difference is in toolchain capabilities: > # - On x64|AMD64 hosts: aarch64 tools are cross-compilation tools (Hostx64/arm64) > # - On aarch64|ARMv8 hosts: aarch64 tools are native tools (Hostarm64/arm64) > HOST_ARCH=`echo $PROCESSOR_IDENTIFIER` > case $HOST_ARCH in > AMD64) > echo "Running on x64 host - generating devkit with native x86/x64 tools and cross-compiled aarch64 tools." > echo "For native aarch64 compilation tools, run this script on a Windows/aarch64 machine." > SUPPORTED_PLATFORMS="x86, x64 (native) and aarch64 (cross-compiled)" > ;; > ARMv8) > echo "Running on aarch64 host - generating devkit with native tools for all platforms (x86, x64, aarch64)." > SUPPORTED_PLATFORMS="x86, x64, and aarch64 (all native)" > ;; > *) > echo "Unknown host architecture: $HOST_ARCH" > echo "Proceeding with devkit generation - toolchain capabilities may vary." > SUPPORTED_PLATFORMS="x86, x64, and aarch64" > ;; > esac That looks good, I think! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25259#discussion_r2161775116 From shade at openjdk.org Mon Jun 23 16:48:44 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 23 Jun 2025 16:48:44 GMT Subject: [jdk25] RFR: 8360042: GHA: Bump MSVC to 14.44 Message-ID: Fixes GHA for jdk25 branch as well, following the switch to windows-2025 runners in late JDK 25. Additional testing: - [ ] GHA ------------- Commit messages: - Backport 72679c94ee00c87b9b51233938e5ffa97ef825b1 Changes: https://git.openjdk.org/jdk/pull/25939/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25939&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360042 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25939.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25939/head:pull/25939 PR: https://git.openjdk.org/jdk/pull/25939 From duke at openjdk.org Mon Jun 23 18:54:10 2025 From: duke at openjdk.org (Luigi Montoya) Date: Mon, 23 Jun 2025 18:54:10 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation [v2] In-Reply-To: References: Message-ID: > Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh > > The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries Luigi Montoya has updated the pull request incrementally with one additional commit since the last revision: Add documentation of what devkit will be created ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25259/files - new: https://git.openjdk.org/jdk/pull/25259/files/305540ce..1da82324 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25259&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25259&range=00-01 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25259/head:pull/25259 PR: https://git.openjdk.org/jdk/pull/25259 From ihse at openjdk.org Mon Jun 23 22:31:29 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 23 Jun 2025 22:31:29 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 18:54:10 GMT, Luigi Montoya wrote: >> Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh >> >> The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries > > Luigi Montoya has updated the pull request incrementally with one additional commit since the last revision: > > Add documentation of what devkit will be created It looks good to me now. Let's see if @erikj79 has some additional input. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25259#pullrequestreview-2951680336 From serb at openjdk.org Mon Jun 23 22:57:27 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 23 Jun 2025 22:57:27 GMT Subject: [jdk25] RFR: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: <-SalhmnjExiRg7qr55JqJ1cm6aNf--yZAw9lbJjzl8Y=.525c2796-7852-4506-903f-3638f2d071b5@github.com> On Mon, 23 Jun 2025 16:43:47 GMT, Aleksey Shipilev wrote: > Fixes GHA for jdk25 branch as well, following the switch to windows-2025 runners in late JDK 25. > > Additional testing: > - [ ] GHA Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25939#pullrequestreview-2951723195 From shade at openjdk.org Tue Jun 24 05:50:32 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 24 Jun 2025 05:50:32 GMT Subject: [jdk25] RFR: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 16:43:47 GMT, Aleksey Shipilev wrote: > Fixes GHA for jdk25 branch as well, following the switch to windows-2025 runners in late JDK 25. > > Additional testing: > - [ ] GHA Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25939#issuecomment-2998903555 From shade at openjdk.org Tue Jun 24 05:50:33 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 24 Jun 2025 05:50:33 GMT Subject: [jdk25] Integrated: 8360042: GHA: Bump MSVC to 14.44 In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 16:43:47 GMT, Aleksey Shipilev wrote: > Fixes GHA for jdk25 branch as well, following the switch to windows-2025 runners in late JDK 25. > > Additional testing: > - [ ] GHA This pull request has now been integrated. Changeset: 7cc1f82b Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/7cc1f82b842982d7c95492df5f817f411b5594fa Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8360042: GHA: Bump MSVC to 14.44 Reviewed-by: serb Backport-of: 72679c94ee00c87b9b51233938e5ffa97ef825b1 ------------- PR: https://git.openjdk.org/jdk/pull/25939 From erikj at openjdk.org Tue Jun 24 07:46:32 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Jun 2025 07:46:32 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 18:54:10 GMT, Luigi Montoya wrote: >> Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh >> >> The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries > > Luigi Montoya has updated the pull request incrementally with one additional commit since the last revision: > > Add documentation of what devkit will be created This looks great, thanks! ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25259#pullrequestreview-2952544790 From mbaesken at openjdk.org Wed Jun 25 12:56:06 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 25 Jun 2025 12:56:06 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured Message-ID: There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. Examples : runtime/signal/TestSigalrm.java runtime/signal/TestSigbus.java They run into errors like this stdout: []; stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. One option would be to avoid running those tests when asan is enabled. Another option is to avoid the so called 'link order check' . https://github.com/google/sanitizers/wiki/addresssanitizerflags verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) ------------- Commit messages: - JDK-8360478 Changes: https://git.openjdk.org/jdk/pull/25978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360478 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25978/head:pull/25978 PR: https://git.openjdk.org/jdk/pull/25978 From mbaesken at openjdk.org Wed Jun 25 12:56:06 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 25 Jun 2025 12:56:06 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured In-Reply-To: References: Message-ID: <_fTVHRFhHb-jxK-NT-rVMwgQF3FJJjfTS76HFl2knLw=.b4d664c0-24e6-4fd7-b249-aebc313b799d@github.com> On Wed, 25 Jun 2025 12:49:54 GMT, Matthias Baesken wrote: > There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. > > Examples : > runtime/signal/TestSigalrm.java > runtime/signal/TestSigbus.java > > They run into errors like this > > > stdout: []; > stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. > > > One option would be to avoid running those tests when asan is enabled. > Another option is to avoid the so called 'link order check' . > https://github.com/google/sanitizers/wiki/addresssanitizerflags > > verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) With this change, all HS :tier3 jtreg tests pass on my Linux ppc64le test machine . ------------- PR Comment: https://git.openjdk.org/jdk/pull/25978#issuecomment-3004664490 From dholmes at openjdk.org Thu Jun 26 01:24:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 26 Jun 2025 01:24:29 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured In-Reply-To: References: Message-ID: <-5vazCLbwrTs_okR2Qjt8-o2yeAstEynjP0mTeIfoBw=.c5d6cdf6-0720-4905-8581-0f90cef0d748@github.com> On Wed, 25 Jun 2025 12:49:54 GMT, Matthias Baesken wrote: > There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. > > Examples : > runtime/signal/TestSigalrm.java > runtime/signal/TestSigbus.java > > They run into errors like this > > > stdout: []; > stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. > > > One option would be to avoid running those tests when asan is enabled. > Another option is to avoid the so called 'link order check' . > https://github.com/google/sanitizers/wiki/addresssanitizerflags > > verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) If this fixes the problem then it seems fine. I don't know why ASAN cares about the library order or the implications thereof. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25978#pullrequestreview-2960135466 From syan at openjdk.org Thu Jun 26 01:44:35 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 26 Jun 2025 01:44:35 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 12:49:54 GMT, Matthias Baesken wrote: > There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. > > Examples : > runtime/signal/TestSigalrm.java > runtime/signal/TestSigbus.java > > They run into errors like this > > > stdout: []; > stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. > > > One option would be to avoid running those tests when asan is enabled. > Another option is to avoid the so called 'link order check' . > https://github.com/google/sanitizers/wiki/addresssanitizerflags > > verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) make/data/asan/asan_default_options.c line 70: > 68: "print_suppressions=0," > 69: "handle_segv=0," > 70: // A lot of libjsig related tests fail because of the link order check; so better avoid it Do we need update the copyrighy year. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25978#discussion_r2167921691 From mbaesken at openjdk.org Thu Jun 26 06:33:11 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 26 Jun 2025 06:33:11 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v2] In-Reply-To: References: Message-ID: > There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. > > Examples : > runtime/signal/TestSigalrm.java > runtime/signal/TestSigbus.java > > They run into errors like this > > > stdout: []; > stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. > > > One option would be to avoid running those tests when asan is enabled. > Another option is to avoid the so called 'link order check' . > https://github.com/google/sanitizers/wiki/addresssanitizerflags > > verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust COPYRIGHT year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25978/files - new: https://git.openjdk.org/jdk/pull/25978/files/099a2c58..06efab18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25978&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25978&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25978/head:pull/25978 PR: https://git.openjdk.org/jdk/pull/25978 From mbaesken at openjdk.org Thu Jun 26 06:33:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 26 Jun 2025 06:33:12 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 01:41:26 GMT, SendaoYan wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust COPYRIGHT year > > make/data/asan/asan_default_options.c line 70: > >> 68: "print_suppressions=0," >> 69: "handle_segv=0," >> 70: // A lot of libjsig related tests fail because of the link order check; so better avoid it > > Do we need update the copyrighy year. Yes I think so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25978#discussion_r2168255359 From mbaesken at openjdk.org Thu Jun 26 06:39:32 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 26 Jun 2025 06:39:32 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 06:33:11 GMT, Matthias Baesken wrote: >> There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. >> >> Examples : >> runtime/signal/TestSigalrm.java >> runtime/signal/TestSigbus.java >> >> They run into errors like this >> >> >> stdout: []; >> stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. >> >> >> One option would be to avoid running those tests when asan is enabled. >> Another option is to avoid the so called 'link order check' . >> https://github.com/google/sanitizers/wiki/addresssanitizerflags >> >> verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust COPYRIGHT year Could maybe someone with MSVC give it a try? My MSVC installation does not like ASAN (in theory it should work there). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25978#issuecomment-3007317450 From dholmes at openjdk.org Thu Jun 26 07:50:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 26 Jun 2025 07:50:28 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 06:33:11 GMT, Matthias Baesken wrote: >> There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. >> >> Examples : >> runtime/signal/TestSigalrm.java >> runtime/signal/TestSigbus.java >> >> They run into errors like this >> >> >> stdout: []; >> stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. >> >> >> One option would be to avoid running those tests when asan is enabled. >> Another option is to avoid the so called 'link order check' . >> https://github.com/google/sanitizers/wiki/addresssanitizerflags >> >> verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust COPYRIGHT year make/data/asan/asan_default_options.c line 2: > 1: /* > 2: * Copyright (c) 2023, 2025, Google and/or its affiliates. All rights reserved. @MBaesken unless you work for Google, or someone from Google requests that you update their copyright notice (as we do for Oracle copyright) then you should not modify other people's copyright notices. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25978#discussion_r2168423004 From mbaesken at openjdk.org Thu Jun 26 08:06:29 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 26 Jun 2025 08:06:29 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 07:48:00 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust COPYRIGHT year > > make/data/asan/asan_default_options.c line 2: > >> 1: /* >> 2: * Copyright (c) 2023, 2025, Google and/or its affiliates. All rights reserved. > > @MBaesken unless you work for Google, or someone from Google requests that you update their copyright notice (as we do for Oracle copyright) then you should not modify other people's copyright notices. Maybe someone from Google can comment what they want/prefer for the headers? (or was there a statement that they do not want changes to the year info) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25978#discussion_r2168454471 From duke at openjdk.org Thu Jun 26 23:36:47 2025 From: duke at openjdk.org (duke) Date: Thu, 26 Jun 2025 23:36:47 GMT Subject: RFR: 8357079: Fix Windows AArch64 DevKit Creation [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 18:54:10 GMT, Luigi Montoya wrote: >> Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh >> >> The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries > > Luigi Montoya has updated the pull request incrementally with one additional commit since the last revision: > > Add documentation of what devkit will be created @Luigi96 Your change (at version 1da82324e0588c70c34ebaba347bdab05de29d05) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25259#issuecomment-3010627315 From duke at openjdk.org Fri Jun 27 06:14:52 2025 From: duke at openjdk.org (Luigi Montoya) Date: Fri, 27 Jun 2025 06:14:52 GMT Subject: Integrated: 8357079: Fix Windows AArch64 DevKit Creation In-Reply-To: References: Message-ID: On Thu, 15 May 2025 22:16:34 GMT, Luigi Montoya wrote: > Fix path for Visual Studio arm64 binaries in createWindowsDevkit.sh > > The DevKit currently created on a Windows AArch64 machine uses the x64 compiler binaries (e.g. cl.exe). This can be inspected by running "dumpbin /headers /out:cl.txt cl.exe" on the compiler in the generated DevKit and inspecting the machine architecture line. It should instead use the native Windows AArch64 compiler binaries This pull request has now been integrated. Changeset: 6d05a1d3 Author: Luigi Montoya Committer: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/6d05a1d3f492b6f06b603ae2bb0d03dfb6c8b8f2 Stats: 30 lines in 1 file changed: 29 ins; 0 del; 1 mod 8357079: Fix Windows AArch64 DevKit Creation Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/jdk/pull/25259 From mbaesken at openjdk.org Fri Jun 27 07:13:26 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 07:13:26 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v3] In-Reply-To: References: Message-ID: > There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. > > Examples : > runtime/signal/TestSigalrm.java > runtime/signal/TestSigbus.java > > They run into errors like this > > > stdout: []; > stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. > > > One option would be to avoid running those tests when asan is enabled. > Another option is to avoid the so called 'link order check' . > https://github.com/google/sanitizers/wiki/addresssanitizerflags > > verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Readjust COPYRIGHT year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25978/files - new: https://git.openjdk.org/jdk/pull/25978/files/06efab18..e72b4791 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25978&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25978&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25978/head:pull/25978 PR: https://git.openjdk.org/jdk/pull/25978 From mbaesken at openjdk.org Fri Jun 27 09:36:27 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 09:36:27 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang Message-ID: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs. However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX). The mentioned tests generate a SIGSEGV. Some other tests generate a SIGBUS, e.g. runtime/memory/ReserveMemory.java runtime/memory/ReadFromNoaccessArea.java and this leads to similar issues with ubsan-enabled binaries. We should adjust the signal handling with the sanitizer options, how to do this is documented here : https://github.com/google/sanitizers/wiki/SanitizerCommonFlags ------------- Commit messages: - JDK-8360791 Changes: https://git.openjdk.org/jdk/pull/26015/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26015&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360791 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26015/head:pull/26015 PR: https://git.openjdk.org/jdk/pull/26015 From kbarrett at openjdk.org Fri Jun 27 16:00:34 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 27 Jun 2025 16:00:34 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang In-Reply-To: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> Message-ID: <9-MCBfqk_Nt4Y3hYtW7ws3Wcossjo6AgIsPheX8J_X8=.d749c187-92cc-49e3-a4a4-e9d880d50508@github.com> On Fri, 27 Jun 2025 09:30:19 GMT, Matthias Baesken wrote: > A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs. > However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX). > The mentioned tests generate a SIGSEGV. > > Some other tests generate a SIGBUS, e.g. > > runtime/memory/ReserveMemory.java > runtime/memory/ReadFromNoaccessArea.java > > and this leads to similar issues with ubsan-enabled binaries. > > We should adjust the signal handling with the sanitizer options, how to do this is documented here : > https://github.com/google/sanitizers/wiki/SanitizerCommonFlags make/data/ubsan/ubsan_default_options.c line 69: > 67: "handle_segv=0," > 68: "handle_sigbus=0," > 69: #endif I wonder if this should be unconditional, rather than conditional on `__clang__`. And maybe we should similarly disable all of the other UBSAN signal handlers, to avoid interfering with those installed by the JVM. UBSAN has potential handlers for SIGSEGV, SIGBUS, SIGILL, and SIGFPE. The JVM installs handlers for all of those: https://github.com/openjdk/jdk/blob/12196baf6700d00c244747cfa22767e532a4a963/src/hotspot/os/posix/signals_posix.cpp#L1316-L1320 https://github.com/openjdk/jdk/blob/12196baf6700d00c244747cfa22767e532a4a963/src/hotspot/os/posix/jvm_posix.cpp#L46-L56 Also, the SanitizerCommonFlags documentation has a bug in the description of these handle_XXX options. They are described as having values of 0, 1, or 2, but the given defaults are true or false. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26015#discussion_r2172316093 From ihse at openjdk.org Fri Jun 27 16:01:25 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:01:25 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 07:13:26 GMT, Matthias Baesken wrote: >> There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. >> >> Examples : >> runtime/signal/TestSigalrm.java >> runtime/signal/TestSigbus.java >> >> They run into errors like this >> >> >> stdout: []; >> stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. >> >> >> One option would be to avoid running those tests when asan is enabled. >> Another option is to avoid the so called 'link order check' . >> https://github.com/google/sanitizers/wiki/addresssanitizerflags >> >> verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Readjust COPYRIGHT year Looks fine to me. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25978#pullrequestreview-2967084884 From ihse at openjdk.org Fri Jun 27 16:00:35 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:00:35 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang In-Reply-To: <9-MCBfqk_Nt4Y3hYtW7ws3Wcossjo6AgIsPheX8J_X8=.d749c187-92cc-49e3-a4a4-e9d880d50508@github.com> References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> <9-MCBfqk_Nt4Y3hYtW7ws3Wcossjo6AgIsPheX8J_X8=.d749c187-92cc-49e3-a4a4-e9d880d50508@github.com> Message-ID: <9bO-iUx1am0I9RDgjjOL98o2niReVKvPPRDYoqMlkas=.0cc17436-5f74-4627-b7c1-fb948ecb2ab8@github.com> On Fri, 27 Jun 2025 15:45:22 GMT, Kim Barrett wrote: >> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs. >> However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX). >> The mentioned tests generate a SIGSEGV. >> >> Some other tests generate a SIGBUS, e.g. >> >> runtime/memory/ReserveMemory.java >> runtime/memory/ReadFromNoaccessArea.java >> >> and this leads to similar issues with ubsan-enabled binaries. >> >> We should adjust the signal handling with the sanitizer options, how to do this is documented here : >> https://github.com/google/sanitizers/wiki/SanitizerCommonFlags > > make/data/ubsan/ubsan_default_options.c line 69: > >> 67: "handle_segv=0," >> 68: "handle_sigbus=0," >> 69: #endif > > I wonder if this should be unconditional, rather than conditional on `__clang__`. > > And maybe we should similarly disable all of the other UBSAN signal handlers, > to avoid interfering with those installed by the JVM. UBSAN has potential > handlers for SIGSEGV, SIGBUS, SIGILL, and SIGFPE. The JVM installs handlers > for all of those: > > https://github.com/openjdk/jdk/blob/12196baf6700d00c244747cfa22767e532a4a963/src/hotspot/os/posix/signals_posix.cpp#L1316-L1320 > > https://github.com/openjdk/jdk/blob/12196baf6700d00c244747cfa22767e532a4a963/src/hotspot/os/posix/jvm_posix.cpp#L46-L56 > > Also, the SanitizerCommonFlags documentation has a bug in the description of > these handle_XXX options. They are described as having values of 0, 1, or 2, > but the given defaults are true or false. I agree, this does not seem to be limited to clang, unless the signal handling stuff differs in ubsan in different compilers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26015#discussion_r2172334545 From ihse at openjdk.org Fri Jun 27 16:01:25 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:01:25 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v3] In-Reply-To: <-5vazCLbwrTs_okR2Qjt8-o2yeAstEynjP0mTeIfoBw=.c5d6cdf6-0720-4905-8581-0f90cef0d748@github.com> References: <-5vazCLbwrTs_okR2Qjt8-o2yeAstEynjP0mTeIfoBw=.c5d6cdf6-0720-4905-8581-0f90cef0d748@github.com> Message-ID: On Thu, 26 Jun 2025 01:22:09 GMT, David Holmes wrote: > I don't know why ASAN cares about the library order or the implications thereof. My understanding is that it wants to be injected first, and if you do LD_PRELOAD then another library might interfere with asan, and thus they want to warn for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25978#issuecomment-3013540491 From ihse at openjdk.org Fri Jun 27 16:10:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:10:58 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v2] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into static-relaunchers - Improve windows runtime lib copying - Fix linux launcher to allow relaunching - Copy Windows runtime libs - Merge branch 'master' into static-relaunchers - Merge branch 'master' into static-relaunchers - Add cast for Windows - Merge branch 'master' into static-relaunchers - Specify how to build jexec - Revert "8352766: Problemlist hotspot tier1 tests requiring tools that are not included in static JDK" This reverts commit 53926742c02480def6a42683fcaf284b99bcb0a1. - ... and 3 more: https://git.openjdk.org/jdk/compare/12196baf...11352678 ------------- Changes: https://git.openjdk.org/jdk/pull/24380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=01 Stats: 713 lines in 11 files changed: 567 ins; 115 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From alanb at openjdk.org Fri Jun 27 16:10:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 27 Jun 2025 16:10:58 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie wrote: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2775924490 From ihse at openjdk.org Fri Jun 27 16:10:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:10:58 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie wrote: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. The way I see it is that we need to be able to produce a generic static JDK image, to be able to test it and keep it from bit-rotting. In actual practice, though, a static JDK is of limited (or rather no) use by itself, and the static build will only serve to produce component that are consumed by downstream setups, where these static libraries are incorporated more tightly into a product. So while we continue to hammer out how to improve this, I think it is important to be able to test static builds in mainline, or they will break. I think we are going to have to keep these relaunchers around for as long as we want to test the static build, even if no downstream consumer really cares. If that is going to be kept in the "static-jdk" image, or in another deliverable, I can't say. Possibly the entire "static-jdk" will go away when we are done with proper jlink/jmod integration, or maybe not. For now, I think this works fine. There were a lot of tricky details to get right in this one. I think I nailed it now. I have done manual adhoc testing of running `build/images/static-jdk/bin/java -XshowSettings -version` to make sure I did not break anything. (I did discover that the Windows launcher did not work since it was missing runtime libs; I guess I copied them manually before and then forgot about it.) I then run `build/images/static-jdk/bin/jar -J-XshowSettings --help`. I initially forgot about passing arguments to the underlying java launcher using the `-J` prefix; it took some fiddling to get that right. I've tested this on linux, macos and windows. I am also currently running the complete set of build tests on Oracle's CI ("builds-infra") + tier1 testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2775969348 PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3013561037 From ihse at openjdk.org Fri Jun 27 16:10:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:10:58 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: <5nxDIPkVmUPtAYpVMecjzXf07fn6s8PXx1mdbm1q3JQ=.48306efa-eb60-4f38-9f7b-9b45cf8cbe57@github.com> On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: > As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. I must admit that I am not very well versed in Windows programming. What is the difference? I thought it was just about the encoding of the function argument. If we change to use CreateProcessW, does not all argument processing have to be changed as well, to be able to propagate command line options? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2775976532 From jiangli at openjdk.org Fri Jun 27 16:10:59 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 27 Jun 2025 16:10:59 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: > Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. @AlanBateman Related to the topic, I just submitted https://github.com/openjdk/leyden/commit/56a9e591d2afcdee7c4f29861486c49f70ef104d with experimental change for jlinking hermetic image using a pre-linked static launcher executable (when @slowhog's https://github.com/openjdk/leyden/pull/46 is in place, I'll experiment with collecting the static libs from .jmod and performing native linking). The experimental change currently still writes out a complete jdk image but only the `lib/modules` (the hermetic executable) is needed for runtime execution (e.g. for running simple HelloWorld). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2776759591 From jiangli at openjdk.org Fri Jun 27 16:10:59 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 27 Jun 2025 16:10:59 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 14:24:18 GMT, Magnus Ihse Bursie wrote: > So while we continue to hammer out how to improve this, I think it is important to be able to test static builds in mainline, or they will break. Agree with @magicus on the importance of being able to test static builds in mainline. It would be good to include teir1 testing for the static builds on linux-x64 in GHA. Currently, we do static build on linux-x64 in GHA without running any tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2776905187 From ihse at openjdk.org Fri Jun 27 16:15:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:15:57 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v3] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove problemlisting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24380/files - new: https://git.openjdk.org/jdk/pull/24380/files/11352678..f2ef1c9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=01-02 Stats: 104 lines in 3 files changed: 61 ins; 28 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From ihse at openjdk.org Fri Jun 27 16:25:40 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 16:25:40 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove problemlisting I thought it would be helpful to keep the `ProblemList-StaticJdk.txt` infrastructure around for the time being. It might have to be used again, since the static JDK is seeing a lot of changes. At some point we should probably remove it, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3013619982 From mbaesken at openjdk.org Fri Jun 27 19:12:45 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 19:12:45 GMT Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is configured [v3] In-Reply-To: References: Message-ID: <1DUfpa7vp8N5s2kd8fPSAX1HZg-K1NrjoHH_OikqGjs=.4bbf6f2b-0e97-4f65-b189-9c0109d81459@github.com> On Fri, 27 Jun 2025 07:13:26 GMT, Matthias Baesken wrote: >> There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. >> >> Examples : >> runtime/signal/TestSigalrm.java >> runtime/signal/TestSigbus.java >> >> They run into errors like this >> >> >> stdout: []; >> stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. >> >> >> One option would be to avoid running those tests when asan is enabled. >> Another option is to avoid the so called 'link order check' . >> https://github.com/google/sanitizers/wiki/addresssanitizerflags >> >> verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Readjust COPYRIGHT year Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25978#issuecomment-3014114220 From mbaesken at openjdk.org Fri Jun 27 19:12:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 19:12:46 GMT Subject: Integrated: 8360478: libjsig related tier3 jtreg tests fail when asan is configured In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 12:49:54 GMT, Matthias Baesken wrote: > There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured. > > Examples : > runtime/signal/TestSigalrm.java > runtime/signal/TestSigbus.java > > They run into errors like this > > > stdout: []; > stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. > > > One option would be to avoid running those tests when asan is enabled. > Another option is to avoid the so called 'link order check' . > https://github.com/google/sanitizers/wiki/addresssanitizerflags > > verify_asan_link_order - Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide) This pull request has now been integrated. Changeset: a23de2ec Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a23de2ec090628b52532ee5d9bd4364a97499f5b Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8360478: libjsig related tier3 jtreg tests fail when asan is configured Reviewed-by: dholmes, ihse ------------- PR: https://git.openjdk.org/jdk/pull/25978 From mbaesken at openjdk.org Fri Jun 27 19:14:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 19:14:38 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang In-Reply-To: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> Message-ID: On Fri, 27 Jun 2025 09:30:19 GMT, Matthias Baesken wrote: > A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs. > However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX). > The mentioned tests generate a SIGSEGV. > > Some other tests generate a SIGBUS, e.g. > > runtime/memory/ReserveMemory.java > runtime/memory/ReadFromNoaccessArea.java > > and this leads to similar issues with ubsan-enabled binaries. > > We should adjust the signal handling with the sanitizer options, how to do this is documented here : > https://github.com/google/sanitizers/wiki/SanitizerCommonFlags > I wonder if this should be unconditional, rather than conditional on __clang__. At least it did not do harm on Linux x86_64/gcc when making it unconditional. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26015#issuecomment-3014119542 From mbaesken at openjdk.org Fri Jun 27 19:14:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 19:14:39 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang In-Reply-To: <9bO-iUx1am0I9RDgjjOL98o2niReVKvPPRDYoqMlkas=.0cc17436-5f74-4627-b7c1-fb948ecb2ab8@github.com> References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> <9-MCBfqk_Nt4Y3hYtW7ws3Wcossjo6AgIsPheX8J_X8=.d749c187-92cc-49e3-a4a4-e9d880d50508@github.com> <9bO-iUx1am0I9RDgjjOL98o2niReVKvPPRDYoqMlkas=.0cc17436-5f74-4627-b7c1-fb948ecb2ab8@github.com> Message-ID: On Fri, 27 Jun 2025 15:56:32 GMT, Magnus Ihse Bursie wrote: > I agree, this does not seem to be limited to clang, unless the signal handling stuff differs in ubsan in different compilers. I only see issues with clang (on macOS and AIX) ; the Linux platforms using gcc are fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26015#discussion_r2172701786 From naoto at openjdk.org Fri Jun 27 20:50:26 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 27 Jun 2025 20:50:26 GMT Subject: RFR: 8360774: Use text representation of normalization data files Message-ID: The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/26027/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26027&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360774 Stats: 92 lines in 8 files changed: 91 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26027/head:pull/26027 PR: https://git.openjdk.org/jdk/pull/26027 From ihse at openjdk.org Fri Jun 27 21:22:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 21:22:21 GMT Subject: RFR: 8360774: Use text representation of normalization data files In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote: > The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process What is the point of this change? If the files were changed to some kind of readable text format, I would think it was a good change. Also, if this is the representation that we get from upstream, then I can understand it as well (but then a comment about it would be good). Just converting a binary file to base64 does not accomplish anything of value. It is true that we try to avoid binary files, but if what we need actually *is* a binary file, then we better store it as such, rather than to taking a detour over base64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26027#issuecomment-3014373091 From ihse at openjdk.org Fri Jun 27 21:22:23 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 27 Jun 2025 21:22:23 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang In-Reply-To: References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> <9-MCBfqk_Nt4Y3hYtW7ws3Wcossjo6AgIsPheX8J_X8=.d749c187-92cc-49e3-a4a4-e9d880d50508@github.com> <9bO-iUx1am0I9RDgjjOL98o2niReVKvPPRDYoqMlkas=.0cc17436-5f74-4627-b7c1-fb948ecb2ab8@github.com> Message-ID: On Fri, 27 Jun 2025 19:11:28 GMT, Matthias Baesken wrote: >> I agree, this does not seem to be limited to clang, unless the signal handling stuff differs in ubsan in different compilers. > >> I agree, this does not seem to be limited to clang, unless the signal handling stuff differs in ubsan in different compilers. > > I only see issues with clang (on macOS and AIX) ; the Linux platforms using gcc are fine. This does not seem to be something related to compiler. I guess there might be other environmental factors determining if you encounter this as a problem or not. Given that we know that we do these things with signals, on all unix platforms, then it makes sense to tell ubsan about it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26015#discussion_r2172882228 From naoto at openjdk.org Fri Jun 27 21:34:37 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 27 Jun 2025 21:34:37 GMT Subject: RFR: 8360774: Use text representation of normalization data files In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote: > The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process > Just converting a binary file to base64 does not accomplish anything of value. It is true that we try to avoid binary files, but if what we need actually _is_ a binary file, then we better store it as such, rather than to taking a detour over base64. It is merely to avoid checking binary files in the repository. If we are OK continuing to do so, I am fine with it ------------- PR Comment: https://git.openjdk.org/jdk/pull/26027#issuecomment-3014393670 From kbarrett at openjdk.org Sat Jun 28 03:58:47 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 28 Jun 2025 03:58:47 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang In-Reply-To: References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> <9-MCBfqk_Nt4Y3hYtW7ws3Wcossjo6AgIsPheX8J_X8=.d749c187-92cc-49e3-a4a4-e9d880d50508@github.com> <9bO-iUx1am0I9RDgjjOL98o2niReVKvPPRDYoqMlkas=.0cc17436-5f74-4627-b7c1-fb948ecb2ab8@github.com> Message-ID: <3jyobUN5VqAMVDbMEfwClRfMR9mt2WcgY_0Sg3PRnOA=.aef77888-6a70-4449-9e61-c6facacf31b7@github.com> On Fri, 27 Jun 2025 21:13:32 GMT, Magnus Ihse Bursie wrote: >>> I agree, this does not seem to be limited to clang, unless the signal handling stuff differs in ubsan in different compilers. >> >> I only see issues with clang (on macOS and AIX) ; the Linux platforms using gcc are fine. > > This does not seem to be something related to compiler. I guess there might be other environmental factors determining if you encounter this as a problem or not. Given that we know that we do these things with signals, on all unix platforms, then it makes sense to tell ubsan about it. Does the same problem arise when building with clang on linux? I tried it, but ran into some linking errors that I don't understand, and I've not done much with ubsan before. ld.lld: error: non-exported symbol '__ubsan_handle_type_mismatch_v1' in '/usr/bin/../lib/clang/19/lib/aarch64-redhat-linux-gnu/libclang_rt.ubsan_standalone.a(ubsan_handlers.cpp.o)' is referenced by DSO '/home/kab/gitsb/ubsan-vs-signals/fastdebug/hotspot/variant-server/libjvm/gtest/libjvm.so' and similarly for a bunch of other ubsan functions. I expect these are some configuration issue on my end, but I'm not going to try digging into it right now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26015#discussion_r2173110905 From mbaesken at openjdk.org Sat Jun 28 16:35:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Sat, 28 Jun 2025 16:35:39 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang In-Reply-To: <3jyobUN5VqAMVDbMEfwClRfMR9mt2WcgY_0Sg3PRnOA=.aef77888-6a70-4449-9e61-c6facacf31b7@github.com> References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> <9-MCBfqk_Nt4Y3hYtW7ws3Wcossjo6AgIsPheX8J_X8=.d749c187-92cc-49e3-a4a4-e9d880d50508@github.com> <9bO-iUx1am0I9RDgjjOL98o2niReVKvPPRDYoqMlkas=.0cc17436-5f74-4627-b7c1-fb948ecb2ab8@github.com> <3jyobUN5VqAMVDbMEfwClRfMR9mt2WcgY_0Sg3PRnOA=.aef77888-6a70-4449-9e61-c6facacf31b7@github.com> Message-ID: On Sat, 28 Jun 2025 03:55:44 GMT, Kim Barrett wrote: > Does the same problem arise when building with clang on linux? I tried it, but ran into some linking errors that I don't understand, and I've not done much with ubsan before. > > ``` > ld.lld: error: non-exported symbol '__ubsan_handle_type_mismatch_v1' in '/usr/bin/../lib/clang/19/lib/aarch64-redhat-linux-gnu/libclang_rt.ubsan_standalone.a(ubsan_handlers.cpp.o)' is referenced by DSO '/home/kab/gitsb/ubsan-vs-signals/fastdebug/hotspot/variant-server/libjvm/gtest/libjvm.so' > ``` > > and similarly for a bunch of other ubsan functions. I expect these are some configuration issue on my end, but I'm not going to try digging into it right now. I see this on SUSE Linux too https://bugs.openjdk.org/browse/JDK-8355597 8355597: Build failure on Linux with ubsan and toolchain clang but we use mostly gcc on Linux so I did not look much into this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26015#discussion_r2173411914 From ihse at openjdk.org Sun Jun 29 21:39:37 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sun, 29 Jun 2025 21:39:37 GMT Subject: RFR: 8360774: Use text representation of normalization data files In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote: > The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process I don't see any benefit of checking in base64-encoded files that are inherently binary. If anyone else have a different opinion, let's hear it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26027#issuecomment-3017150314 From duke at openjdk.org Sun Jun 29 22:24:15 2025 From: duke at openjdk.org (David Beaumont) Date: Sun, 29 Jun 2025 22:24:15 GMT Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark ImageReader Message-ID: Added jimage and jrtfs exports. ------------- Commit messages: - Hacking build file for benchmark Changes: https://git.openjdk.org/jdk/pull/26035/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361013 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26035.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26035/head:pull/26035 PR: https://git.openjdk.org/jdk/pull/26035 From liach at openjdk.org Mon Jun 30 05:25:39 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 30 Jun 2025 05:25:39 GMT Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark ImageReader In-Reply-To: References: Message-ID: <4GTRMySmZVwyTAg8rgyKbU2oySIlcPdTRQe3ufEYIbw=.32d67eb0-d7b2-487d-a64f-2aff56491906@github.com> On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont wrote: > Added jimage and jrtfs exports. Looks reasonable. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26035#pullrequestreview-2969934108 From alanb at openjdk.org Mon Jun 30 05:25:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 30 Jun 2025 05:25:39 GMT Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark ImageReader In-Reply-To: References: Message-ID: <8YJmTFVGCZrjgRAiF40HcGD4DFjpybs-FIzwhkTQY5M=.d19a6577-7c79-435a-843b-b303a3dc8331@github.com> On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont wrote: > Added jimage and jrtfs exports. Is there a reason to do this on its own? Usually the exports are expanded as benchmarks are added that use internal APIs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26035#issuecomment-3017841768 From mbaesken at openjdk.org Mon Jun 30 07:02:31 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 30 Jun 2025 07:02:31 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang [v2] In-Reply-To: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> Message-ID: > A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs. > However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX). > The mentioned tests generate a SIGSEGV. > > Some other tests generate a SIGBUS, e.g. > > runtime/memory/ReserveMemory.java > runtime/memory/ReadFromNoaccessArea.java > > and this leads to similar issues with ubsan-enabled binaries. > > We should adjust the signal handling with the sanitizer options, how to do this is documented here : > https://github.com/google/sanitizers/wiki/SanitizerCommonFlags Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Remove the clang check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26015/files - new: https://git.openjdk.org/jdk/pull/26015/files/8fedbca0..cd68ac5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26015&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26015&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26015/head:pull/26015 PR: https://git.openjdk.org/jdk/pull/26015 From mbaesken at openjdk.org Mon Jun 30 07:06:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 30 Jun 2025 07:06:38 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling when using clang [v2] In-Reply-To: References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> Message-ID: <31ztW4pC-asRJ-K8vSJp_rfjm27vJ8Qm-cn6OYvRpYQ=.25841e30-31f4-4fe6-84ce-16d98b03a37d@github.com> On Mon, 30 Jun 2025 07:02:31 GMT, Matthias Baesken wrote: >> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs. >> However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX). >> The mentioned tests generate a SIGSEGV. >> >> Some other tests generate a SIGBUS, e.g. >> >> runtime/memory/ReserveMemory.java >> runtime/memory/ReadFromNoaccessArea.java >> >> and this leads to similar issues with ubsan-enabled binaries. >> >> We should adjust the signal handling with the sanitizer options, how to do this is documented here : >> https://github.com/google/sanitizers/wiki/SanitizerCommonFlags > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove the clang check > > I wonder if this should be unconditional, rather than conditional on **clang**. > > At least it did not do harm on Linux x86_64/gcc when making it unconditional. I removed the clang check and made the addition unconditional. Regarding other signals than SIGBUS and SIGSEGV I did not see issues with those in the jtreg tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26015#issuecomment-3018033591 From duke at openjdk.org Mon Jun 30 08:45:38 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 08:45:38 GMT Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark ImageReader In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont wrote: > Added jimage and jrtfs exports. Doing it on its own means not having to find someone who can approve both the makefile change and the benchmark at the same time. People say that things should be split up into independent things, so I did. I mean I can combine things into one, but why not get this out of the way first? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26035#issuecomment-3018303213 From ihse at openjdk.org Mon Jun 30 08:59:41 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 30 Jun 2025 08:59:41 GMT Subject: RFR: 8360791: [ubsan] Adjust signal handling [v2] In-Reply-To: References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com> Message-ID: On Mon, 30 Jun 2025 07:02:31 GMT, Matthias Baesken wrote: >> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs. >> However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX). >> The mentioned tests generate a SIGSEGV. >> >> Some other tests generate a SIGBUS, e.g. >> >> runtime/memory/ReserveMemory.java >> runtime/memory/ReadFromNoaccessArea.java >> >> and this leads to similar issues with ubsan-enabled binaries. >> >> We should adjust the signal handling with the sanitizer options, how to do this is documented here : >> https://github.com/google/sanitizers/wiki/SanitizerCommonFlags > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove the clang check Looks good. Let's exclude the other signals if we can actually show it is a problem. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26015#pullrequestreview-2970443722 From alanb at openjdk.org Mon Jun 30 09:30:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 30 Jun 2025 09:30:38 GMT Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark ImageReader In-Reply-To: References: Message-ID: <0A3oMNSxFiR8m_TihEtagwBpiH3yWw_p2Mm1bYTyqOQ=.d4cc04ed-a451-4269-af8a-b44e2841f76d@github.com> On Mon, 30 Jun 2025 08:43:16 GMT, David Beaumont wrote: > Doing it on its own means not having to find someone who can approve both the makefile change and the benchmark at the same time. People say that things should be split up into independent things, so I did. I mean I can combine things into one, but why not get this out of the way first? The first benchmark to make to make use of these JDK internal APIs would be the time to add the --add-exports. I don't object to adding it advance, just an unusual way to do this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26035#issuecomment-3018441785 From redestad at openjdk.org Mon Jun 30 10:22:39 2025 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 30 Jun 2025 10:22:39 GMT Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark ImageReader In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont wrote: > Added jimage and jrtfs exports. Approving tentatively, though I think it would be best to rescind this PR and fold it into a follow-up PR that actually adds a benchmark that needs these exports. FWIW I think these changes to the makefiles are routine enough at this point that we don't _need_ to involve someone from the build team, but they can be approved by any reviewer. ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26035#pullrequestreview-2970693925 PR Comment: https://git.openjdk.org/jdk/pull/26035#issuecomment-3018598818 From duke at openjdk.org Mon Jun 30 11:20:42 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 11:20:42 GMT Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark ImageReader In-Reply-To: References: Message-ID: <-axXKxjJkXHZaL5JpW8OCUPdF-Gp2zvrKg9mfbKXtYk=.59b01c3f-0953-473a-ad32-a38868ac4a60@github.com> On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont wrote: > Added jimage and jrtfs exports. Will add with the benchmark. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26035#issuecomment-3018765679 From duke at openjdk.org Mon Jun 30 11:20:43 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 11:20:43 GMT Subject: Withdrawn: 8361013: JMH does not export sufficient modules to benchmark ImageReader In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont wrote: > Added jimage and jrtfs exports. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26035 From duke at openjdk.org Mon Jun 30 12:31:52 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 12:31:52 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes Message-ID: Initial benchmark to capture at least some comparative measures of ImageReader performance. Current results on my laptop: Benchmark Mode Cnt Score Error Units NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op The upcoming changes to ImageReader should show significant improvements to these results. ------------- Commit messages: - ImageReader benchmark Changes: https://git.openjdk.org/jdk/pull/26044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26044&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361076 Stats: 1061 lines in 2 files changed: 1061 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26044/head:pull/26044 PR: https://git.openjdk.org/jdk/pull/26044 From duke at openjdk.org Mon Jun 30 12:31:52 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 12:31:52 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 12:27:40 GMT, David Beaumont wrote: > Initial benchmark to capture at least some comparative measures of ImageReader performance. > > Current results on my laptop: > > Benchmark Mode Cnt Score Error Units > NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op > NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op > NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op > NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op > > The upcoming changes to ImageReader should show significant improvements to these results. I removed a JrtFS related benchmark because it tracked the other one closely enough to not be worth it (hence only 1 additional module export needed). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3018968314 From duke at openjdk.org Mon Jun 30 13:21:06 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 13:21:06 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes [v2] In-Reply-To: References: Message-ID: <_nMz94swcJW3xR9GxQWxTrSZM27MhIR8upcrQYRiCQQ=.8b8820d1-f93f-422b-8892-327db9844760@github.com> > Initial benchmark to capture at least some comparative measures of ImageReader performance. > > Current results on my laptop: > > Benchmark Mode Cnt Score Error Units > NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op > NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op > NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op > NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op > > The upcoming changes to ImageReader should show significant improvements to these results. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Renaming class. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26044/files - new: https://git.openjdk.org/jdk/pull/26044/files/c9fbbffe..489d720a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26044&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26044&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26044/head:pull/26044 PR: https://git.openjdk.org/jdk/pull/26044 From duke at openjdk.org Mon Jun 30 13:21:06 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 13:21:06 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 12:27:40 GMT, David Beaumont wrote: > Initial benchmark to capture at least some comparative measures of ImageReader performance. > > Current results on my laptop: > > Benchmark Mode Cnt Score Error Units > NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op > NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op > NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op > NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op > > The upcoming changes to ImageReader should show significant improvements to these results. Apologies. I realized the name for this class was still completely daft. After spending so much time looking at the details, I didn't spot the obvious. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3019125999 From duke at openjdk.org Mon Jun 30 13:21:06 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 13:21:06 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes [v2] In-Reply-To: <_nMz94swcJW3xR9GxQWxTrSZM27MhIR8upcrQYRiCQQ=.8b8820d1-f93f-422b-8892-327db9844760@github.com> References: <_nMz94swcJW3xR9GxQWxTrSZM27MhIR8upcrQYRiCQQ=.8b8820d1-f93f-422b-8892-327db9844760@github.com> Message-ID: On Mon, 30 Jun 2025 13:18:19 GMT, David Beaumont wrote: >> Initial benchmark to capture at least some comparative measures of ImageReader performance. >> >> Current results on my laptop: >> >> Benchmark Mode Cnt Score Error Units >> NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op >> NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op >> NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op >> NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op >> >> The upcoming changes to ImageReader should show significant improvements to these results. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Renaming class. test/micro/org/openjdk/bench/jdk/internal/jrtfs/NewImageBenchmark.java line 71: > 69: } > 70: > 71: /// NOT a @State since that causes setUp()/tearDown() to be shared, but we This comment might have been before I applied `Scope.Benchmark` to the states below. I'll double check if it's still an issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2175050289 From duke at openjdk.org Mon Jun 30 15:08:25 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 30 Jun 2025 15:08:25 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes [v3] In-Reply-To: References: Message-ID: > Initial benchmark to capture at least some comparative measures of ImageReader performance. > > Current results on my laptop: > > Benchmark Mode Cnt Score Error Units > NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op > NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op > NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op > NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op > > The upcoming changes to ImageReader should show significant improvements to these results. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Some tidying up relating to the state objects. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26044/files - new: https://git.openjdk.org/jdk/pull/26044/files/489d720a..089b68e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26044&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26044&range=01-02 Stats: 26 lines in 1 file changed: 17 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26044/head:pull/26044 PR: https://git.openjdk.org/jdk/pull/26044