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 asmehra at openjdk.org Mon Jun 2 14:15:58 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 2 Jun 2025 14:15:58 GMT Subject: RFR: Update nmethod caching and clean up unused/duplicate methods Message-ID: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> This PR updates nmethod caching to be based on caching of CodeBlob. It also cleans up some dead code and duplicate methods. ------------- Commit messages: - More cleanup - Fix compile failures - Refactor nmethod caching - Replace apply_relocations with fix_relocations Changes: https://git.openjdk.org/leyden/pull/71/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=71&range=00 Stats: 685 lines in 7 files changed: 102 ins; 459 del; 124 mod Patch: https://git.openjdk.org/leyden/pull/71.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/71/head:pull/71 PR: https://git.openjdk.org/leyden/pull/71 From asmehra at openjdk.org Mon Jun 2 14:15:58 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 2 Jun 2025 14:15:58 GMT Subject: RFR: Update nmethod caching and clean up unused/duplicate methods In-Reply-To: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> References: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> Message-ID: On Mon, 2 Jun 2025 14:10:41 GMT, Ashutosh Mehra wrote: > This PR updates nmethod caching to be based on caching of CodeBlob. It also cleans up some dead code and duplicate methods. @vnkozlov @adinn please review. ------------- PR Comment: https://git.openjdk.org/leyden/pull/71#issuecomment-2930929481 From asmehra at openjdk.org Mon Jun 2 14:37:00 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 2 Jun 2025 14:37:00 GMT Subject: RFR: Update nmethod caching and clean up unused/duplicate methods [v2] In-Reply-To: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> References: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> Message-ID: > This PR updates nmethod caching to be based on caching of CodeBlob. It also cleans up some dead code and duplicate methods. Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Remove redundant call to clear() Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/leyden/pull/71/files - new: https://git.openjdk.org/leyden/pull/71/files/6bab593a..b9346a62 Webrevs: - full: https://webrevs.openjdk.org/?repo=leyden&pr=71&range=01 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=71&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/leyden/pull/71.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/71/head:pull/71 PR: https://git.openjdk.org/leyden/pull/71 From asmehra at openjdk.org Mon Jun 2 14:51:47 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 2 Jun 2025 14:51:47 GMT Subject: RFR: Update nmethod caching and clean up unused/duplicate methods [v3] In-Reply-To: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> References: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> Message-ID: > This PR updates nmethod caching to be based on caching of CodeBlob. It also cleans up some dead code and duplicate methods. Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Remove CodeBuffer::clear_strings() as the relevant destructors clear the strings Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/leyden/pull/71/files - new: https://git.openjdk.org/leyden/pull/71/files/b9346a62..646769d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=leyden&pr=71&range=02 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=71&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/leyden/pull/71.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/71/head:pull/71 PR: https://git.openjdk.org/leyden/pull/71 From shade at openjdk.org Mon Jun 2 20:16:21 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 20:16:21 GMT Subject: RFR: Fix recent merge errors Message-ID: I skipped through current premain-vs-mainline webrev, and noticed a few merge errors. `metaspaceShared.cpp` hunks are obvious duplications. I removed the lines that are actually different from mainline. `compilationPolicy.hpp` hunk is a leftover from AOT Profiling. I remember pointing this out to @veresov during mainline review, and we went into mainline without that extra `notify_all`. We should ditch it in premain too. Additional testing: - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/leyden/pull/72/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=72&range=00 Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/leyden/pull/72.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/72/head:pull/72 PR: https://git.openjdk.org/leyden/pull/72 From duke at openjdk.org Mon Jun 2 20:28:22 2025 From: duke at openjdk.org (duke) Date: Mon, 2 Jun 2025 20:28:22 GMT Subject: git: openjdk/leyden: hermetic-java-runtime: 128 new changesets Message-ID: Changeset: c1f066e1 Branch: hermetic-java-runtime Author: Brian Burkhalter Date: 2025-05-27 17:11:24 +0000 URL: https://git.openjdk.org/leyden/commit/c1f066e17eacf7649df4042e2fb985da9724ef40 8356888: (fs) FileSystems.newFileSystem that take an env must specify IllegalArgumentException Reviewed-by: lancea, alanb, jpai ! src/java.base/share/classes/java/nio/file/FileSystems.java Changeset: d4b923d1 Branch: hermetic-java-runtime Author: Per Minborg Date: 2025-05-27 19:11:12 +0000 URL: https://git.openjdk.org/leyden/commit/d4b923d175b07e39ee8ee2c79f04457ea1cfbdd0 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() Reviewed-by: alanb, valeriep ! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/java.base/share/classes/sun/nio/ch/IOUtil.java ! src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Digest.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyWrapCipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java Changeset: da228e06 Branch: hermetic-java-runtime Author: Per Minborg Date: 2025-05-27 19:15:40 +0000 URL: https://git.openjdk.org/leyden/commit/da228e069359bbab0e5c54f8cb2e20d67693b87c 8357145: CRC/Inflater/Deflater/Adler32 methods that take a ByteBuffer throw UOE if backed by shared memory segment Reviewed-by: alanb ! src/java.base/share/classes/java/util/zip/Adler32.java ! src/java.base/share/classes/java/util/zip/CRC32.java ! src/java.base/share/classes/java/util/zip/CRC32C.java ! src/java.base/share/classes/java/util/zip/Deflater.java ! src/java.base/share/classes/java/util/zip/Inflater.java ! test/jdk/java/util/zip/ChecksumBase.java ! test/jdk/java/util/zip/DeInflate.java Changeset: 4755276f Branch: hermetic-java-runtime Author: Brian Burkhalter Date: 2025-05-27 19:47:56 +0000 URL: https://git.openjdk.org/leyden/commit/4755276f36ccc989d9171fc9f92f8e886d4d99b9 8357912: (fs) Remove @since tag from java.nio.file.FileSystems.newFileSystem(Path,ClassLoader) Reviewed-by: lancea, alanb ! src/java.base/share/classes/java/nio/file/FileSystems.java Changeset: 11ad1733 Branch: hermetic-java-runtime Author: Andrey Turbanov Date: 2025-05-27 20:43:09 +0000 URL: https://git.openjdk.org/leyden/commit/11ad1733f8db3d8e868383fc9826963b9ffd620f 8354944: Remove unnecessary PartiallyOrderedSet.nodes Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/javax/imageio/spi/PartiallyOrderedSet.java Changeset: 2e8b195a Branch: hermetic-java-runtime Author: William Kemper Date: 2025-05-27 21:40:27 +0000 URL: https://git.openjdk.org/leyden/commit/2e8b195a96e3b2a4ca27c64a923adc4334073128 8354078: Implement JEP 521: Generational Shenandoah Reviewed-by: ysr ! src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.hpp ! test/hotspot/jtreg/gc/shenandoah/options/TestModeUnlock.java Changeset: f25f4a3e Branch: hermetic-java-runtime Author: Magnus Ihse Bursie Date: 2025-05-27 22:41:39 +0000 URL: https://git.openjdk.org/leyden/commit/f25f4a3eb2f3ebba4af30471de9d35778c120d50 8349665: Make clean removes module-deps.gmk Reviewed-by: erikj ! make/Init.gmk ! make/Main.gmk ! make/PreInitSupport.gmk Changeset: c110623d Branch: hermetic-java-runtime Author: Alex Menkov Date: 2025-05-27 23:23:26 +0000 URL: https://git.openjdk.org/leyden/commit/c110623d38806c5170fbff640e77933dcef8981b 8357282: Test vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java fails after ClassNotFoundException Reviewed-by: lmesnik, sspitsyn ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/vmTestbase/nsk/share/aod/AODRunnerArgParser.java Changeset: 4cad4379 Branch: hermetic-java-runtime Author: Steffen Nie?ing Committer: SendaoYan Date: 2025-05-28 01:54:48 +0000 URL: https://git.openjdk.org/leyden/commit/4cad437956ff75a377adba8a760e19dc6cf7dc8d 8357597: Proxy.getInvocationHandler throws NullPointerException instead of IllegalArgumentException for null Reviewed-by: rriggs, jpai, liach ! src/java.base/share/classes/java/lang/reflect/Proxy.java Changeset: 96fb31e2 Branch: hermetic-java-runtime Author: Dingli Zhang Committer: Feilong Jiang Date: 2025-05-28 02:27:06 +0000 URL: https://git.openjdk.org/leyden/commit/96fb31e2dbc16875c6c8183096cd03f30d0632ee 8357695: RISC-V: Move vector intrinsic condition checks into match_rule_supported_vector Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: 72b9aafd Branch: hermetic-java-runtime Author: Ioi Lam Date: 2025-05-28 02:39:59 +0000 URL: https://git.openjdk.org/leyden/commit/72b9aafd5a0dfb379a979f554fa99a767eef3e50 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception Reviewed-by: kvn, jrose ! src/hotspot/share/cds/metaspaceShared.cpp Changeset: 670ef8cc Branch: hermetic-java-runtime Author: Matthias Baesken Date: 2025-05-28 05:54:10 +0000 URL: https://git.openjdk.org/leyden/commit/670ef8cc52e6eb068ca6968142629abc1c424571 8357561: BootstrapLoggerTest does not work on Ubuntu 24 with LANG de_DE.UTF-8 Reviewed-by: dfuchs ! test/jdk/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/jdk/java/util/logging/LocalizedLevelName.java ! test/jdk/java/util/logging/SimpleFormatterFormat.java ! test/jdk/sun/util/logging/SourceClassName.java Changeset: db515566 Branch: hermetic-java-runtime Author: Thomas Schatzl Date: 2025-05-28 06:55:20 +0000 URL: https://git.openjdk.org/leyden/commit/db515566875b92bd4aff08cccc80d80b85f01514 8354428: [ubsan] g1BiasedArray.hpp: pointer overflow in address calculation Reviewed-by: ayang, kbarrett, mbaesken ! src/hotspot/share/gc/g1/g1BiasedArray.cpp ! src/hotspot/share/gc/g1/g1BiasedArray.hpp ! src/hotspot/share/gc/g1/vmStructs_g1.hpp ! test/hotspot/gtest/gc/g1/test_g1BiasedArray.cpp Changeset: 1d57ff8a Branch: hermetic-java-runtime Author: Marc Chevalier Date: 2025-05-28 07:52:17 +0000 URL: https://git.openjdk.org/leyden/commit/1d57ff8ad4938bc9ca9b1996eb200c1b51bdf300 8357781: Deep recursion in PhaseCFG::set_next_call leads to stack overflow Reviewed-by: thartmann, kvn, mhaessig ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/lcm.cpp + test/hotspot/jtreg/compiler/c2/StackOverflowInSetNextCall.java Changeset: efeb050e Branch: hermetic-java-runtime Author: Raffaello Giulietti Date: 2025-05-28 08:13:02 +0000 URL: https://git.openjdk.org/leyden/commit/efeb050e00145da18f979fe17c22da2f736dbd41 8357808: Add a command line option for specifying a counter in TestRandomFloatingDecimal Reviewed-by: liach ! test/jdk/jdk/internal/math/FloatingDecimal/TestRandomFloatingDecimal.java Changeset: f74fbfe5 Branch: hermetic-java-runtime Author: Axel Boldt-Christmas Date: 2025-05-28 08:20:48 +0000 URL: https://git.openjdk.org/leyden/commit/f74fbfe5de9dc5b90652956935642670c085938c 8357449: ZGC: Multiple medium page sizes Reviewed-by: stefank, jsikstro ! src/hotspot/share/gc/z/vmStructs_z.hpp ! src/hotspot/share/gc/z/zAllocationFlags.hpp ! src/hotspot/share/gc/z/zArguments.cpp ! src/hotspot/share/gc/z/zGlobals.cpp ! src/hotspot/share/gc/z/zGlobals.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/gc/z/zMappedCache.cpp ! src/hotspot/share/gc/z/zMappedCache.hpp ! src/hotspot/share/gc/z/zObjectAllocator.cpp ! src/hotspot/share/gc/z/zPage.cpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zRelocationSetSelector.cpp ! src/hotspot/share/gc/z/zRelocationSetSelector.hpp ! src/hotspot/share/gc/z/zRelocationSetSelector.inline.hpp ! src/hotspot/share/gc/z/zStat.cpp ! src/hotspot/share/gc/z/z_globals.hpp + test/hotspot/jtreg/gc/z/TestZMediumPageSizes.java Changeset: 1e0caedb Branch: hermetic-java-runtime Author: Albert Mingkun Yang Date: 2025-05-28 08:47:36 +0000 URL: https://git.openjdk.org/leyden/commit/1e0caedb9ab1c56e3986764ce260b94e423d4948 8357854: Parallel: Inline args of PSOldGen::initialize_performance_counters Reviewed-by: tschatzl, jsikstro ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/parallel/psOldGen.hpp Changeset: f02190bc Branch: hermetic-java-runtime Author: Markus Gr?nlund Date: 2025-05-28 08:57:04 +0000 URL: https://git.openjdk.org/leyden/commit/f02190bc30bf3d203a5012140a72023622fc2d77 8357829: Commented out sample limit in JfrSamplerThread::task_stacktrace Reviewed-by: shade ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp Changeset: 4e1878ca Branch: hermetic-java-runtime Author: Andrew Haley Date: 2025-05-28 09:41:37 +0000 URL: https://git.openjdk.org/leyden/commit/4e1878ca452d1e781eb61610a94064c0c4798073 8355022: Implement JEP 506: Scoped Values Reviewed-by: liach, alanb ! src/java.base/share/classes/java/lang/ScopedValue.java ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java ! test/jdk/java/lang/ScopedValue/ManyBindings.java ! test/jdk/java/lang/ScopedValue/ScopedValueAPI.java ! test/jdk/java/lang/ScopedValue/UnboundValueAfterOOME.java Changeset: 39714b60 Branch: hermetic-java-runtime Author: Hannes Walln?fer Date: 2025-05-28 09:46:49 +0000 URL: https://git.openjdk.org/leyden/commit/39714b603040f1619f5e0e2a13ea8a90bb993c27 8357869: Remove PreviewNote taglet in its current form Reviewed-by: erikj ! make/Docs.gmk - make/jdk/src/classes/build/tools/taglet/PreviewNote.java Changeset: 627ef344 Branch: hermetic-java-runtime Author: Mikhail Yankelevich Committer: Michael McMahon Date: 2025-05-28 10:34:50 +0000 URL: https://git.openjdk.org/leyden/commit/627ef34498c31b5d16f9da423cfe0a5fe46a3562 8304065: HttpServer.stop should terminate immediately if no exchanges are in progress Co-authored-by: Eirik Bj?rsn?s Reviewed-by: dfuchs, michaelm ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/Event.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLengthOutputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/UndefLengthOutputStream.java - src/jdk.httpserver/share/classes/sun/net/httpserver/WriteFinishedEvent.java + test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java Changeset: 0671309d Branch: hermetic-java-runtime Author: Per Minborg Date: 2025-05-28 10:57:57 +0000 URL: https://git.openjdk.org/leyden/commit/0671309de530822cc261e8251fc425c8aa3cc487 8357919: Arena::allocate returns segments with address zero if the segment length is zero after JDK-8345687 Reviewed-by: mcimadamore ! src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java ! test/jdk/java/foreign/TestSegments.java Changeset: f30e1541 Branch: hermetic-java-runtime Author: Serguei Spitsyn Date: 2025-05-28 11:38:20 +0000 URL: https://git.openjdk.org/leyden/commit/f30e15411f5c0fc90565dac19203fdc1ab43fd88 8357673: remove test serviceability/jvmti/vthread/TestPinCaseWithCFLH Reviewed-by: amenkov, lmesnik - test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java Changeset: 6ebae6cd Branch: hermetic-java-runtime Author: Casper Norrbin Committer: Albert Mingkun Yang Date: 2025-05-28 12:00:15 +0000 URL: https://git.openjdk.org/leyden/commit/6ebae6cded49f9b0b0d42899af3303647eca7848 8241678: Remove PerfData sampling via StatSampler Reviewed-by: jsjolen, ayang ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/gc/parallel/spaceCounters.cpp ! src/hotspot/share/gc/parallel/spaceCounters.hpp ! src/hotspot/share/gc/serial/cSpaceCounters.cpp ! src/hotspot/share/gc/serial/cSpaceCounters.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/perfData.cpp ! src/hotspot/share/runtime/perfData.hpp ! src/hotspot/share/runtime/perfDataTypes.hpp ! src/hotspot/share/runtime/perfMemory.cpp - src/hotspot/share/runtime/statSampler.cpp - src/hotspot/share/runtime/statSampler.hpp ! src/hotspot/share/runtime/threads.cpp ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionExecuter.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionResolver.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java + src/jdk.jcmd/share/classes/sun/tools/jstat/Timestamp.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options Changeset: c9e6c4d0 Branch: hermetic-java-runtime Author: Fabio Romano Committer: Raffaello Giulietti Date: 2025-05-28 12:48:47 +0000 URL: https://git.openjdk.org/leyden/commit/c9e6c4d0171ff6f419344f9341747c71416d4ec9 8356891: Some code simplifications in BigInteger Reviewed-by: rgiulietti ! src/java.base/share/classes/java/math/BigInteger.java Changeset: 4b9290af Branch: hermetic-java-runtime Author: Marc Chevalier Date: 2025-05-28 13:26:15 +0000 URL: https://git.openjdk.org/leyden/commit/4b9290af0a46bdf662735c24d00732a4c1601102 8356647: C2: Excessively strict assert in PhaseIdealLoop::do_unroll Reviewed-by: chagedorn, epeter, dlong ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/UnrollWideLoopHitsTooStrictAssert.java Changeset: 016cc4f3 Branch: hermetic-java-runtime Author: Markus Gr?nlund Date: 2025-05-28 13:51:24 +0000 URL: https://git.openjdk.org/leyden/commit/016cc4f333d1a59a7cd534cb7ee4c373087efd10 8357830: JfrVframeStream::_cont_entry shadows super-class field Reviewed-by: egahlin - src/hotspot/share/jfr/recorder/stacktrace/jfrVframeStream.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrVframeStream.hpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrVframeStream.inline.hpp Changeset: 1a65719a Branch: hermetic-java-runtime Author: Markus Gr?nlund Date: 2025-05-28 13:51:40 +0000 URL: https://git.openjdk.org/leyden/commit/1a65719ab336336f94777df85bafeeef2c4d5b56 8357911: JFR: Fix subtle xor method tagging bug Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp Changeset: 18285fc1 Branch: hermetic-java-runtime Author: Viktor Klang Date: 2025-05-28 14:23:23 +0000 URL: https://git.openjdk.org/leyden/commit/18285fc136e1a892ab54a705c1fa82e91325b06a 8356553: Incorrect uses of {@link} in AbstractQueuedLongSynchronizer and AbstractQueuedSynchronizer Reviewed-by: alanb ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: 7bd8375f Branch: hermetic-java-runtime Author: Magnus Ihse Bursie Date: 2025-05-28 14:25:12 +0000 URL: https://git.openjdk.org/leyden/commit/7bd8375fe49eedecae7b2a1c75e7efb5ab06b22d 8357920: Add .rej and .orig to .gitignore Reviewed-by: syan, erikj ! .gitignore Changeset: a4f870df Branch: hermetic-java-runtime Author: Magnus Ihse Bursie Date: 2025-05-28 14:42:21 +0000 URL: https://git.openjdk.org/leyden/commit/a4f870df553e4d7669edf6e454e147526ff2fae7 8357510: [REDO] RunTest variables should always be assigned Reviewed-by: erikj ! make/RunTests.gmk Changeset: 63d0e7ff Branch: hermetic-java-runtime Author: Magnus Ihse Bursie Date: 2025-05-28 14:42:35 +0000 URL: https://git.openjdk.org/leyden/commit/63d0e7ff117537bf4768b88c43a0231a14ed1512 8355725: SPEC_FILTER stopped working Reviewed-by: erikj ! make/Docs.gmk Changeset: e3f85c96 Branch: hermetic-java-runtime Author: Igor Veresov Date: 2025-05-28 15:15:03 +0000 URL: https://git.openjdk.org/leyden/commit/e3f85c961b4c1e5e01aedf3a0f4e1b0e6ff457fd 8355003: Implement JEP 515: Ahead-of-Time Method Profiling Co-authored-by: John R Rose Co-authored-by: Vladimir Ivanov Co-authored-by: Ioi Lam Co-authored-by: Vladimir Kozlov Co-authored-by: Aleksey Shipilev Reviewed-by: kvn, ihse, cjplummer, iklam ! make/hotspot/lib/JvmFeatures.gmk ! src/hotspot/share/cds/aotArtifactFinder.cpp ! src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp ! src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/cds/cppVtables.cpp ! src/hotspot/share/cds/dumpAllocStats.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/runTimeClassInfo.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciObjectFactory.hpp ! src/hotspot/share/classfile/compactHashtable.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/memory/metadataFactory.hpp ! src/hotspot/share/memory/metaspaceClosure.hpp ! src/hotspot/share/oops/array.hpp ! src/hotspot/share/oops/array.inline.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceKlassFlags.hpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/klass.inline.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/oops/methodData.hpp + src/hotspot/share/oops/trainingData.cpp + src/hotspot/share/oops/trainingData.hpp ! src/hotspot/share/runtime/init.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java + test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java Changeset: 4ced4e73 Branch: hermetic-java-runtime Author: gauthamkrishnanibm Committer: Roger Riggs Date: 2025-05-28 15:38:00 +0000 URL: https://git.openjdk.org/leyden/commit/4ced4e73fc0a517df826860839681004bb67e624 8334742: Change java.time month/day field types to 'byte' Reviewed-by: rriggs ! src/java.base/share/classes/java/time/LocalDate.java ! src/java.base/share/classes/java/time/MonthDay.java ! src/java.base/share/classes/java/time/YearMonth.java ! src/java.base/share/classes/java/time/chrono/HijrahDate.java Changeset: 2e6838a2 Branch: hermetic-java-runtime Author: Thomas Schatzl Date: 2025-05-28 15:49:34 +0000 URL: https://git.openjdk.org/leyden/commit/2e6838a20d52e9fa0a3b7322f2cb548e034b5d83 8357307: VM GC operations should have a public gc_succeeded() Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1VMOperations.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/gcVMOperations.hpp Changeset: e579cca6 Branch: hermetic-java-runtime Author: PAWAN CHAWDHARY Committer: Leonid Mesnik Date: 2025-05-28 15:59:37 +0000 URL: https://git.openjdk.org/leyden/commit/e579cca619147aa51563dc00f374e02db49e1238 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 Reviewed-by: lmesnik, mseledtsov ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java Changeset: 8949c074 Branch: hermetic-java-runtime Author: Alexey Semenyuk Date: 2025-05-28 16:18:46 +0000 URL: https://git.openjdk.org/leyden/commit/8949c07484bd2ea0ab1e5207d45e6ef3694b7428 8357930: Amendment for JDK-8333664 Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageFileExtras.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ApplicationBuilder.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/FileAssociationGroup.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherData.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherStartupInfoBuilder.java + src/jdk.jpackage/share/classes/jdk/jpackage/internal/ModuleInfo.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java - src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/ApplicationWriter.java + src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundleCreator.java = src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundleSpec.java + src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundlingEnvironment.java + src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundlingOperation.java + src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/ExternalApplication.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/LauncherModularStartupInfoMixin.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Package.java - src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/PackageWriter.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CollectionUtils.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java ! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java Changeset: b2a61a99 Branch: hermetic-java-runtime Author: Naoto Sato Date: 2025-05-28 16:24:04 +0000 URL: https://git.openjdk.org/leyden/commit/b2a61a9972493d67d0f1a9f3f529c11e45838d5b 8356985: Use "stdin.encoding" in Console's read*() methods Reviewed-by: jlu, smarks, alanb, vyazici ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java ! src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java ! test/jdk/java/io/Console/CharsetTest.java + test/jdk/java/io/Console/StdinEncodingTest.java = test/jdk/java/io/Console/csp/module-info.java + test/jdk/java/io/Console/csp/provider/UppercasingCharsetProvider.java ! test/jdk/java/io/Console/script.exp + test/jdk/java/io/Console/stdinEncoding.exp Changeset: cd052c72 Branch: hermetic-java-runtime Author: Henry Jen Date: 2025-05-28 17:22:41 +0000 URL: https://git.openjdk.org/leyden/commit/cd052c72cdb62186e66c1d2ecf9216f3df61b242 8345431: Improve jar --validate to detect duplicate or invalid entries Reviewed-by: lancea, jpai ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jartool/share/man/jar.md + test/jdk/tools/jar/ValidatorTest.java Changeset: 28f50931 Branch: hermetic-java-runtime Author: Gerard Ziemski Date: 2025-05-28 19:14:36 +0000 URL: https://git.openjdk.org/leyden/commit/28f509317d477c5f4076658f9ae9995aa6c53631 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() Reviewed-by: jsjolen, dholmes ! src/hotspot/share/nmt/virtualMemoryTracker.cpp Changeset: bb2c80c0 Branch: hermetic-java-runtime Author: Anthony Scarpino Date: 2025-05-28 19:52:18 +0000 URL: https://git.openjdk.org/leyden/commit/bb2c80c0e9923385e0b6243c0ebff9afef208470 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) Reviewed-by: weijun, mr, mullan, jnimeh ! src/java.base/share/classes/java/security/AsymmetricKey.java + src/java.base/share/classes/java/security/DEREncodable.java ! src/java.base/share/classes/java/security/KeyPair.java + src/java.base/share/classes/java/security/PEMDecoder.java + src/java.base/share/classes/java/security/PEMEncoder.java + src/java.base/share/classes/java/security/PEMRecord.java ! src/java.base/share/classes/java/security/cert/X509CRL.java ! src/java.base/share/classes/java/security/cert/X509Certificate.java ! src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java ! src/java.base/share/classes/java/security/spec/X509EncodedKeySpec.java ! src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java ! src/java.base/share/classes/sun/security/ec/ECKeyFactory.java ! src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/ec/XDHKeyFactory.java ! src/java.base/share/classes/sun/security/ec/XDHPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/ec/ed/EdDSAKeyFactory.java ! src/java.base/share/classes/sun/security/ec/ed/EdDSAPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java ! src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java ! src/java.base/share/classes/sun/security/provider/DSAPrivateKey.java ! src/java.base/share/classes/sun/security/provider/KeyProtector.java ! src/java.base/share/classes/sun/security/provider/X509Factory.java ! src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/java.base/share/classes/sun/security/util/DerValue.java ! src/java.base/share/classes/sun/security/util/KeyUtil.java ! src/java.base/share/classes/sun/security/util/Pem.java ! src/java.base/share/classes/sun/security/x509/X509Key.java ! src/java.base/share/conf/security/java.security ! test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java + test/jdk/java/security/PEM/PEMData.java + test/jdk/java/security/PEM/PEMDecoderTest.java + test/jdk/java/security/PEM/PEMEncoderTest.java + test/jdk/javax/crypto/EncryptedPrivateKeyInfo/EncryptKey.java + test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetKey.java ! test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java Changeset: b7f0f480 Branch: hermetic-java-runtime Author: Shaojin Wen Date: 2025-05-28 20:36:44 +0000 URL: https://git.openjdk.org/leyden/commit/b7f0f480cefb7295bbd5f8830458b69baf2eaff6 8357681: Fixed the DigitList::toString method causing incorrect results during debugging Reviewed-by: jlu, naoto ! src/java.base/share/classes/java/text/DigitList.java Changeset: dede3532 Branch: hermetic-java-runtime Author: Ioi Lam Date: 2025-05-28 22:12:14 +0000 URL: https://git.openjdk.org/leyden/commit/dede3532f7238d527fb89be41f1b8050bde02ee3 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics Reviewed-by: erikj, kvn, asmehra ! doc/testing.html ! doc/testing.md ! make/RunTests.gmk ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/cdsConfig.hpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/java.base/share/classes/jdk/internal/misc/CDS.java ! src/java.base/share/man/java.md ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java - test/hotspot/jtreg/runtime/cds/appcds/UseAppCDS_Test.java + test/hotspot/jtreg/runtime/cds/appcds/aotCache/SpecialCacheNames.java ! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/MethodHandleTest.java ! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/WeakReferenceTest.java ! test/hotspot/jtreg/runtime/cds/appcds/aotCode/AOTCodeFlags.java + test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java + test/hotspot/jtreg/runtime/cds/appcds/aotFlags/FileNameSubstitution.java + test/hotspot/jtreg/runtime/cds/appcds/aotFlags/JDK_AOT_VM_OPTIONS.java ! test/lib/jdk/test/lib/cds/CDSAppTester.java ! test/setup_aot/TestSetupAOT.java Changeset: 2ec6ab34 Branch: hermetic-java-runtime Author: Ioi Lam Date: 2025-05-28 22:58:34 +0000 URL: https://git.openjdk.org/leyden/commit/2ec6ab347a18f454e33a3a281daf1d50a1fd5e27 8357525: Default CDS archive becomes non-deterministic after JDK-8305895 Reviewed-by: shade, coleenp ! src/hotspot/share/oops/klass.cpp Changeset: 83a28048 Branch: hermetic-java-runtime Author: Lei Zhu Committer: SendaoYan Date: 2025-05-29 05:40:36 +0000 URL: https://git.openjdk.org/leyden/commit/83a280485889573d5709b2bb59185d11ab6a38da 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless Reviewed-by: shade, syan, lmesnik ! test/hotspot/jtreg/runtime/interpreter/CountBytecodesTest.java Changeset: 04e0fe00 Branch: hermetic-java-runtime Author: Phil Race Date: 2025-05-29 05:52:12 +0000 URL: https://git.openjdk.org/leyden/commit/04e0fe00abcf1d7919a50e0c9dd44ce2856984ea 8356049: Need a simple way to play back a sound clip Reviewed-by: serb, aivanov, kizune ! src/java.desktop/share/classes/com/sun/media/sound/DataPusher.java ! src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java + src/java.desktop/share/classes/javax/sound/SoundClip.java + src/java.desktop/share/classes/javax/sound/package-info.java ! src/java.desktop/share/classes/module-info.java + test/jdk/javax/sound/SoundClip/LoopExitTest.java + test/jdk/javax/sound/SoundClip/SoundClipTest.java + test/jdk/javax/sound/SoundClip/badsound.wav + test/jdk/javax/sound/SoundClip/javasound.wav Changeset: d43f588d Branch: hermetic-java-runtime Author: Adam Sotona Date: 2025-05-29 07:03:26 +0000 URL: https://git.openjdk.org/leyden/commit/d43f588db1b39724da2823b73fe09f8609fd8e48 8357955: java.lang.classfile.Signature.ArrayTypeSig.of IAE not thrown for dims > 255 Reviewed-by: jlahoda ! src/java.base/share/classes/java/lang/classfile/Signature.java ! test/jdk/jdk/classfile/SignaturesTest.java Changeset: 07f5b762 Branch: hermetic-java-runtime Author: Erik Gahlin Date: 2025-05-29 08:31:17 +0000 URL: https://git.openjdk.org/leyden/commit/07f5b762a09e4fe9f7ba71368593f6dfa0ff8f6e 8352738: Implement JEP 520: JFR Method Timing and Tracing Co-authored-by: Markus Gr?nlund Reviewed-by: shade, mgronlun ! src/hotspot/share/classfile/modules.hpp + src/hotspot/share/jfr/instrumentation/jfrClassTransformer.cpp + src/hotspot/share/jfr/instrumentation/jfrClassTransformer.hpp ! src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp ! src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp ! src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp ! src/hotspot/share/jfr/jfr.cpp ! src/hotspot/share/jfr/jfr.hpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.hpp ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp ! src/hotspot/share/jfr/jni/jfrUpcalls.cpp ! src/hotspot/share/jfr/jni/jfrUpcalls.hpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp + src/hotspot/share/jfr/support/jfrAnnotationElementIterator.cpp + src/hotspot/share/jfr/support/jfrAnnotationElementIterator.hpp + src/hotspot/share/jfr/support/jfrAnnotationIterator.cpp + src/hotspot/share/jfr/support/jfrAnnotationIterator.hpp ! src/hotspot/share/jfr/support/jfrKlassExtension.hpp + src/hotspot/share/jfr/support/methodtracer/jfrClassFilterClosure.cpp + src/hotspot/share/jfr/support/methodtracer/jfrClassFilterClosure.hpp + src/hotspot/share/jfr/support/methodtracer/jfrFilter.cpp + src/hotspot/share/jfr/support/methodtracer/jfrFilter.hpp + src/hotspot/share/jfr/support/methodtracer/jfrFilterManager.cpp + src/hotspot/share/jfr/support/methodtracer/jfrFilterManager.hpp + src/hotspot/share/jfr/support/methodtracer/jfrInstrumentedClass.hpp + src/hotspot/share/jfr/support/methodtracer/jfrMethodProcessor.cpp + src/hotspot/share/jfr/support/methodtracer/jfrMethodProcessor.hpp + src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp + src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.hpp + src/hotspot/share/jfr/support/methodtracer/jfrTraceTagging.cpp + src/hotspot/share/jfr/support/methodtracer/jfrTraceTagging.hpp + src/hotspot/share/jfr/support/methodtracer/jfrTracedMethod.cpp + src/hotspot/share/jfr/support/methodtracer/jfrTracedMethod.hpp ! src/hotspot/share/jfr/utilities/jfrLogTagSets.hpp ! src/hotspot/share/jfr/utilities/jfrRelation.hpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp + src/jdk.jfr/share/classes/jdk/jfr/events/MethodTimingEvent.java + src/jdk.jfr/share/classes/jdk/jfr/events/MethodTraceEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/LogTag.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/ShutdownHook.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/Field.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/FieldFormatter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini + src/jdk.jfr/share/classes/jdk/jfr/internal/settings/FilterSetting.java + src/jdk.jfr/share/classes/jdk/jfr/internal/settings/MethodSetting.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/ExcludeList.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Filter.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Instrumentation.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Method.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Modification.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/TimedClass.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/TimedMethod.java + src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Transform.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Bytecode.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java ! src/jdk.jfr/share/classes/jdk/jfr/package-info.java + src/jdk.jfr/share/classes/jdk/jfr/tracing/MethodTracer.java ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc ! test/jdk/jdk/jfr/api/settings/TestSettingControl.java + test/jdk/jdk/jfr/event/tracing/Apple.java + test/jdk/jdk/jfr/event/tracing/Banana.java + test/jdk/jdk/jfr/event/tracing/Car.java + test/jdk/jdk/jfr/event/tracing/StaticInitializer.java + test/jdk/jdk/jfr/event/tracing/TestClinit.java + test/jdk/jdk/jfr/event/tracing/TestCombinedFilters.java + test/jdk/jdk/jfr/event/tracing/TestFilterClass.java + test/jdk/jdk/jfr/event/tracing/TestFilterClassAnnotation.java + test/jdk/jdk/jfr/event/tracing/TestFilterMethod.java + test/jdk/jdk/jfr/event/tracing/TestFilterMethodAnnotation.java + test/jdk/jdk/jfr/event/tracing/TestInstrumentation.java + test/jdk/jdk/jfr/event/tracing/TestMethodTiming.java + test/jdk/jdk/jfr/event/tracing/TestMethodTrace.java + test/jdk/jdk/jfr/event/tracing/TestMultipleRecordings.java + test/jdk/jdk/jfr/event/tracing/TestMultipleThreads.java + test/jdk/jdk/jfr/event/tracing/TestRestrictedClasses.java + test/jdk/jdk/jfr/event/tracing/TestRetransformFalse.java + test/jdk/jdk/jfr/event/tracing/TestWithClassLoaders.java + test/jdk/jdk/jfr/event/tracing/TestWithModules.java ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/jdk/test/lib/jfr/Events.java Changeset: a2743bab Branch: hermetic-java-runtime Author: Hannes Walln?fer Date: 2025-05-29 09:19:02 +0000 URL: https://git.openjdk.org/leyden/commit/a2743bab4fd203b0791cf47e617c1a95b05ab3cc 8357458: Missing Highlight.js license file Reviewed-by: jlahoda ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java + src/jdk.javadoc/share/legal/highlightjs.md ! test/langtools/jdk/javadoc/doclet/checkLibraryVersions/CheckLibraryVersions.java ! test/langtools/jdk/javadoc/doclet/testLegalNotices/TestLegalNotices.java Changeset: 4cf729cf Branch: hermetic-java-runtime Author: Thomas Stuefe Date: 2025-05-29 10:42:50 +0000 URL: https://git.openjdk.org/leyden/commit/4cf729cfac57c9aec692a52c1f3f95f2403e7958 8323497: On x64, use 32-bit immediate moves for narrow klass base if possible Reviewed-by: shade, kvn, rkennke ! src/hotspot/cpu/x86/compressedKlass_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/oops/compressedKlass.cpp ! src/hotspot/share/oops/compressedKlass.hpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java Changeset: d8a78302 Branch: hermetic-java-runtime Author: Aleksey Shipilev Date: 2025-05-29 15:06:51 +0000 URL: https://git.openjdk.org/leyden/commit/d8a783020d247d2c01834db14b44d239ad1f2bf4 8357999: SA: FileMapInfo.metadataTypeArray initialization issue after JDK-8355003 Reviewed-by: ayang, iklam, kvn, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java Changeset: 79aff26c Branch: hermetic-java-runtime Author: Brian Burkhalter Date: 2025-05-29 15:20:39 +0000 URL: https://git.openjdk.org/leyden/commit/79aff26c2880922b92863911d8a5a035ba9a1e75 8354724: Methods in java.io.Reader to read all characters and all lines Reviewed-by: rriggs, smarks, jpai, alanb ! src/java.base/share/classes/java/io/Reader.java + test/jdk/java/io/Reader/ReadAll.java Changeset: f3188682 Branch: hermetic-java-runtime Author: Justin Lu Date: 2025-05-29 17:01:28 +0000 URL: https://git.openjdk.org/leyden/commit/f318868268f32934a2f0c4e26a6c75360d8e74b1 8348328: Update IANA Language Subtag Registry to Version 2025-05-15 Reviewed-by: iris, naoto ! src/java.base/share/data/lsrdata/language-subtag-registry.txt ! test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java Changeset: e3063678 Branch: hermetic-java-runtime Author: Ioi Lam Date: 2025-05-29 17:06:42 +0000 URL: https://git.openjdk.org/leyden/commit/e306367813db7c8a3ecac5e46740600b7ab04f9d 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages Reviewed-by: kvn, shade ! src/hotspot/share/cds/filemap.cpp Changeset: e509997f Branch: hermetic-java-runtime Author: Justin Lu Date: 2025-05-29 17:39:08 +0000 URL: https://git.openjdk.org/leyden/commit/e509997fe87a09513b8f79d303cc69392d2cb7b0 8357275: Locale.Builder.setLanguageTag should mention conversions made on language tag Reviewed-by: naoto ! src/java.base/share/classes/java/util/Locale.java Changeset: d922e318 Branch: hermetic-java-runtime Author: Shaojin Wen Date: 2025-05-29 20:09:01 +0000 URL: https://git.openjdk.org/leyden/commit/d922e318bc2104d69c46403bceb609d538f3259a 8349400: Improve startup speed via eliminating nested classes Reviewed-by: valeriep, rriggs ! src/java.base/share/classes/sun/security/util/KnownOIDs.java Changeset: 727412d1 Branch: hermetic-java-runtime Author: Shaojin Wen Date: 2025-05-29 20:09:58 +0000 URL: https://git.openjdk.org/leyden/commit/727412d1b5f0764363ebd2ff600d4b7f0c99bb9b 8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes Reviewed-by: naoto ! make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java ! src/java.base/share/classes/java/lang/CharacterData.java ! src/java.base/share/classes/java/lang/CharacterData00.java.template ! src/java.base/share/classes/java/lang/CharacterData01.java.template ! src/java.base/share/classes/java/lang/CharacterData02.java.template ! src/java.base/share/classes/java/lang/CharacterData03.java.template ! src/java.base/share/classes/java/lang/CharacterData0E.java.template ! src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template ! src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java ! src/java.base/share/classes/java/lang/CharacterDataUndefined.java Changeset: cb8eea4e Branch: hermetic-java-runtime Author: Boris Ulasevich Date: 2025-05-29 21:29:35 +0000 URL: https://git.openjdk.org/leyden/commit/cb8eea4ecd12669e361baac8bb6e71cde7937812 8356095: AArch64: Obsolete -XX:+NearCPool option Reviewed-by: aph ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 648c337b Branch: hermetic-java-runtime Author: Dean Long Date: 2025-05-29 21:41:49 +0000 URL: https://git.openjdk.org/leyden/commit/648c337bea5ec65908cab02eaf232243ccf2d4bf 8356648: runtime/Thread/AsyncExceptionTest.java fails with +StressCompiledExceptionHandlers Reviewed-by: thartmann, kvn ! src/hotspot/share/c1/c1_Runtime1.cpp ! test/hotspot/jtreg/runtime/Thread/AsyncExceptionTest.java Changeset: a05f9dea Branch: hermetic-java-runtime Author: Alexey Semenyuk Date: 2025-05-29 21:44:47 +0000 URL: https://git.openjdk.org/leyden/commit/a05f9dea18ec812abad1dbe0084c0c58384a9076 8358017: Various enhancements of jpackage test helpers Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/AnnotationsTest.java ! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JUnitAdapter.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/FileAssociations.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSignVerify.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/RunnablePackageTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestBuilder.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestInstance.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestMethodSupplier.java Changeset: 64503c78 Branch: hermetic-java-runtime Author: Prasanta Sadhukhan Date: 2025-05-30 02:06:56 +0000 URL: https://git.openjdk.org/leyden/commit/64503c784bbddc638ce0098f5c6ef0cb81cbf938 8357299: Graphics copyArea doesn't copy any pixels when there is overflow Reviewed-by: achung, kizune, prr ! src/java.desktop/share/native/libawt/java2d/loops/Blit.c + test/jdk/java/awt/Graphics/BrokenBoundsClip.java Changeset: fd51b039 Branch: hermetic-java-runtime Author: Alexander Matveev Date: 2025-05-30 03:07:04 +0000 URL: https://git.openjdk.org/leyden/commit/fd51b03910ba90ca1c46a4204b8940421338e22e 8351369: [macos] Use --install-dir option with DMG packaging Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/DMGsetup.scpt ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! test/jdk/tools/jpackage/share/InstallDirTest.java Changeset: 20005511 Branch: hermetic-java-runtime Author: Amit Kumar Date: 2025-05-30 03:50:43 +0000 URL: https://git.openjdk.org/leyden/commit/20005511e3612d6a5f12fa83066f02c88c628e8b 8353500: [s390x] Intrinsify Unsafe::setMemory Reviewed-by: lucy, mdoerr ! src/hotspot/cpu/s390/stubGenerator_s390.cpp Changeset: 6f9e1175 Branch: hermetic-java-runtime Author: Daniel Skantz Date: 2025-05-30 06:23:11 +0000 URL: https://git.openjdk.org/leyden/commit/6f9e1175a983c735c1beed755ec5b14b476858d7 8356246: C2: Compilation fails with "assert(bol->is_Bool()) failed: unexpected if shape" in StringConcat::eliminate_unneeded_control Reviewed-by: rcastanedalo, kvn ! src/hotspot/share/opto/stringopts.cpp + test/hotspot/jtreg/compiler/stringopts/TestStackedConcatsSharedTest.java Changeset: e33eeeea Branch: hermetic-java-runtime Author: Abhishek Kumar Date: 2025-05-30 06:25:08 +0000 URL: https://git.openjdk.org/leyden/commit/e33eeeea04fc7899bf66b0a2fdaccc30060854b4 8341311: [Accessibility,macOS,VoiceOver] VoiceOver announces incorrect number of items in submenu of JPopupMenu Reviewed-by: asemenov, kizune ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m + test/jdk/javax/accessibility/TestPopupMenuChildCount.java Changeset: 566e3b21 Branch: hermetic-java-runtime Author: nibjen Committer: Sean Coffey Date: 2025-05-30 09:22:16 +0000 URL: https://git.openjdk.org/leyden/commit/566e3b21ed14748cb0d9117b6bd58b4bfcf625c6 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir Reviewed-by: coffeys ! test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java Changeset: a0eb1900 Branch: hermetic-java-runtime Author: Qizheng Xing Committer: Joel Sikstr?m Date: 2025-05-30 09:41:08 +0000 URL: https://git.openjdk.org/leyden/commit/a0eb1900c91531db26d1086a3b251bce0cf7c141 8358104: Fix ZGC compilation error on GCC 10.2 Reviewed-by: kbarrett, jsikstro ! src/hotspot/share/gc/z/zMappedCache.cpp Changeset: acd64ba2 Branch: hermetic-java-runtime Author: Anjian Wen Committer: Feilong Jiang Date: 2025-05-30 10:56:37 +0000 URL: https://git.openjdk.org/leyden/commit/acd64ba24afd508689803adaa6714a784946979c 8357626: RISC-V: Tighten up template interpreter method entry code Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp Changeset: 12ee80ca Branch: hermetic-java-runtime Author: Alexey Ivanov Date: 2025-05-30 13:31:35 +0000 URL: https://git.openjdk.org/leyden/commit/12ee80cac754c1a6dd37191a9f80c01de8b659ad 8357675: Amend headless message Reviewed-by: prr, shade ! src/java.desktop/unix/classes/sun/awt/PlatformGraphicsInfo.java Changeset: ae3d96a4 Branch: hermetic-java-runtime Author: Thomas Stuefe Date: 2025-05-30 13:40:25 +0000 URL: https://git.openjdk.org/leyden/commit/ae3d96a4ec87262bc2f01d87fe91daa5d0d3966f 8357683: (process) SIGQUIT still blocked after JDK-8234262 with jdk.lang.Process.launchMechanism=FORK or VFORK Reviewed-by: rriggs ! src/java.base/unix/native/jspawnhelper/jspawnhelper.c ! src/java.base/unix/native/libjava/childproc.c ! test/jdk/java/lang/ProcessBuilder/UnblockSignals.java Changeset: 26275a10 Branch: hermetic-java-runtime Author: Archie Cobbs Date: 2025-05-30 14:42:36 +0000 URL: https://git.openjdk.org/leyden/commit/26275a10b2aa75f0d4ff49248a3309f9d7b19bf3 8355753: @SuppressWarnings("this-escape") not respected for indirect leak via field Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java ! test/langtools/tools/javac/warnings/ThisEscape.java ! test/langtools/tools/javac/warnings/ThisEscape.out Changeset: 99048c3d Branch: hermetic-java-runtime Author: Artur Barashev Date: 2025-05-30 16:03:13 +0000 URL: https://git.openjdk.org/leyden/commit/99048c3d4a66be9bf586949bd08e33cb091fa6bf 8357033: Reduce stateless session ticket size Reviewed-by: wetmore, djelinski, ascarpino ! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java ! test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java ! test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServerStateless.java Changeset: 81464cd1 Branch: hermetic-java-runtime Author: Justin Lu Date: 2025-05-30 17:13:04 +0000 URL: https://git.openjdk.org/leyden/commit/81464cd1141ebdf0cdde22e7388b97224d810f4a 8358089: Remove the GenerateKeyList.java test tool Reviewed-by: naoto - test/jdk/java/util/Locale/GenerateKeyList.java Changeset: eaf7815e Branch: hermetic-java-runtime Author: Naoto Sato Date: 2025-05-30 17:22:51 +0000 URL: https://git.openjdk.org/leyden/commit/eaf7815ea6854de603a1b5c179799a9ef5d37f42 8357886: Remove TimeZoneNames_* of the COMPAT locale data provider Reviewed-by: joehw, jlu - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_en_CA.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_en_GB.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_en_IE.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_es.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_fr.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_hi.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_it.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ja.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ko.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_pt_BR.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_sv.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_CN.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_HK.java - src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_TW.java Changeset: 4fa4f151 Branch: hermetic-java-runtime Author: Naoto Sato Date: 2025-05-30 17:23:52 +0000 URL: https://git.openjdk.org/leyden/commit/4fa4f15122213afea5cb25166c3b36a1c395b06c 8357882: Use UTF-8 encoded data in LocaleDataTest Reviewed-by: jlu, joehw ! test/jdk/sun/text/resources/LocaleData.cldr ! test/jdk/sun/text/resources/LocaleDataTest.java Changeset: 3cc63098 Branch: hermetic-java-runtime Author: Chris Plummer Date: 2025-05-30 17:36:03 +0000 URL: https://git.openjdk.org/leyden/commit/3cc630985d47be6ba4cf991698e999f17dbde203 8353955: nsk/jdi tests should be fixed to not always require includevirtualthreads=y Reviewed-by: sspitsyn, amenkov, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod013/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq005/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq007/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq008/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq009/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocatableEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod010/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod012/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod013/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/SerialExecutionDebugger.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeArgumentHandler.java Changeset: 82807d43 Branch: hermetic-java-runtime Author: Chris Plummer Date: 2025-05-30 17:58:46 +0000 URL: https://git.openjdk.org/leyden/commit/82807d43f8d18b186428be88a80ebe28892517cc 8357184: Test vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008/TestDescription.java fails with unreported exception Reviewed-by: lmesnik, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008.java Changeset: b7ca672d Branch: hermetic-java-runtime Author: Ashutosh Mehra Date: 2025-05-30 18:26:19 +0000 URL: https://git.openjdk.org/leyden/commit/b7ca672d5c5f11f472110154868f08299f6e8796 8357047: [ubsan] AdapterFingerPrint::AdapterFingerPrint runtime error: index 3 out of bounds Reviewed-by: kvn, adinn ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 94039e22 Branch: hermetic-java-runtime Author: Daniel Gredler Committer: Harshitha Onkar Date: 2025-05-30 19:16:17 +0000 URL: https://git.openjdk.org/leyden/commit/94039e22bbe943888e858d8ae278145e2668526a 8353230: Emoji rendering regression after JDK-8208377 Reviewed-by: prr, honkar ! src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java ! src/java.desktop/share/classes/sun/font/CMap.java ! src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java ! src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java ! src/java.desktop/share/classes/sun/font/Font2D.java ! src/java.desktop/share/classes/sun/font/FontUtilities.java ! src/java.desktop/share/classes/sun/font/HBShaper.java ! src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java ! src/java.desktop/share/classes/sun/font/Type1GlyphMapper.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/native/libfontmanager/sunFont.c ! src/java.desktop/unix/classes/sun/font/NativeGlyphMapper.java + test/jdk/java/awt/font/GlyphVector/GlyphVectorGsubTest.java Changeset: c9d6e012 Branch: hermetic-java-runtime Author: Anthony Scarpino Date: 2025-05-30 20:13:00 +0000 URL: https://git.openjdk.org/leyden/commit/c9d6e01233fbc9f3a95a4879feff906748649c54 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE Reviewed-by: weijun ! src/java.base/share/classes/sun/security/ec/ECKeyFactory.java ! src/java.base/share/classes/sun/security/ec/XDHKeyFactory.java ! src/java.base/share/classes/sun/security/ec/ed/EdDSAKeyFactory.java ! src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java Changeset: 14e41ab0 Branch: hermetic-java-runtime Author: Chris Plummer Date: 2025-05-30 20:14:14 +0000 URL: https://git.openjdk.org/leyden/commit/14e41ab055955ffd7cf9e8129cc3269b4e3807b7 8357172: Extend try block in nsk/jdi tests to capture exceptions thrown by Debuggee.classByName() Reviewed-by: lmesnik, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod010.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod014.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod009.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/invokeMethod/invokemethod014.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue005/setvalue005.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes006.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java Changeset: abbffc01 Branch: hermetic-java-runtime Author: Alex Menkov Date: 2025-05-30 21:00:34 +0000 URL: https://git.openjdk.org/leyden/commit/abbffc0103826a2e02fe52ef9b55890a57944933 8358202: ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/ProblemList.txt Changeset: 09301c1d Branch: hermetic-java-runtime Author: Ian Graves Date: 2025-05-30 21:11:38 +0000 URL: https://git.openjdk.org/leyden/commit/09301c1dc03a44e5c56a91303de81ba01dabfe71 8356634: VectorShape#largestShapeFor should have public access Reviewed-by: psandoz ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java ! test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java Changeset: db340e54 Branch: hermetic-java-runtime Author: Alex Menkov Date: 2025-05-30 21:11:58 +0000 URL: https://git.openjdk.org/leyden/commit/db340e54f83cf7bf72abb94c9cf9cdac007ed38a 8356222: Thread.print command reports waiting on the Class initialization monitor for both carrier and virtual threads Reviewed-by: alanb, sspitsyn ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vframe.hpp + test/hotspot/jtreg/serviceability/dcmd/thread/ClassInitMonitorVThread.java Changeset: 0df8c968 Branch: hermetic-java-runtime Author: Mohamed Issa Committer: Sandhya Viswanathan Date: 2025-05-30 21:47:20 +0000 URL: https://git.openjdk.org/leyden/commit/0df8c9684b8782ef830e2bd425217864c3f51784 8353686: Optimize Math.cbrt for x86 64 bit platforms Reviewed-by: sviswanathan, sparasa, jbhateja ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp + src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp ! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/stubDeclarations.hpp ! src/java.base/share/classes/java/lang/Math.java + test/micro/org/openjdk/bench/java/lang/CbrtPerf.java Changeset: 2926435d Branch: hermetic-java-runtime Author: Bradford Wetmore Date: 2025-05-30 23:06:36 +0000 URL: https://git.openjdk.org/leyden/commit/2926435d228f21a227763ff4efcf32e511aa258a 8341346: Add support for exporting TLS Keying Material Reviewed-by: hchao, jnimeh, weijun ! src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java ! src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/java.base/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/ServerHello.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java + test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java Changeset: 5ad02c98 Branch: hermetic-java-runtime Author: Sergey Bylokhov Date: 2025-05-31 00:16:40 +0000 URL: https://git.openjdk.org/leyden/commit/5ad02c98f1d9227bb6abdd37126f2a351d4e1a50 8355004: Apply java.io.Serial annotations in java.compiler Reviewed-by: liach, darcy ! src/java.compiler/share/classes/javax/annotation/processing/FilerException.java ! src/java.compiler/share/classes/javax/lang/model/UnknownEntityException.java ! src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java ! src/java.compiler/share/classes/javax/lang/model/element/UnknownDirectiveException.java ! src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java ! src/java.compiler/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/java.compiler/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java Changeset: d9d00d33 Branch: hermetic-java-runtime Author: Sergey Bylokhov Date: 2025-05-31 00:26:50 +0000 URL: https://git.openjdk.org/leyden/commit/d9d00d33a6a0d540a10e0a58f6df27cae46d2753 8358107: Rollback JDK-8357299 changeset Reviewed-by: psadhukhan ! src/java.desktop/share/native/libawt/java2d/loops/Blit.c - test/jdk/java/awt/Graphics/BrokenBoundsClip.java Changeset: c67fc735 Branch: hermetic-java-runtime Author: Serguei Spitsyn Date: 2025-05-31 00:40:23 +0000 URL: https://git.openjdk.org/leyden/commit/c67fc735959ddd41a8d1116908ca7bae9b966016 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001 memory corruption when using -Xcheck:jni Reviewed-by: lmesnik, amenkov ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001/bi02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t001/bi03t001.cpp ! test/lib/jdk/test/lib/jvmti/jvmti_common.hpp Changeset: c62223a5 Branch: hermetic-java-runtime Author: Ian Graves Date: 2025-05-31 00:41:16 +0000 URL: https://git.openjdk.org/leyden/commit/c62223a5af747bc5cbdd3d970dd994f74aa08834 8358215: ProblemList jdk/incubator/vector/PreferredSpeciesTest.java Reviewed-by: psandoz ! test/jdk/ProblemList.txt Changeset: 061b24d4 Branch: hermetic-java-runtime Author: David Briemann Committer: SendaoYan Date: 2025-05-31 02:47:26 +0000 URL: https://git.openjdk.org/leyden/commit/061b24d4f9d8635944683766532e9252c3ba0152 8357304: [PPC64] C2: Implement MinV, MaxV and Reduction nodes Reviewed-by: mdoerr, varadam ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/ppc.ad ! test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Int.java Changeset: 19360a90 Branch: hermetic-java-runtime Author: Chad Rakoczy Committer: SendaoYan Date: 2025-05-31 02:48:33 +0000 URL: https://git.openjdk.org/leyden/commit/19360a904b180f6608c6dcd574c77f78f1880673 8356949: AArch64: Tighten up template interpreter method entry code Reviewed-by: aph, shade ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp Changeset: 3a3ea7e1 Branch: hermetic-java-runtime Author: Sergey Bylokhov Date: 2025-05-31 07:06:08 +0000 URL: https://git.openjdk.org/leyden/commit/3a3ea7e17fff100e368c956350bb9aaa2261b8a9 8357598: Toolkit.removeAWTEventListener should handle null listener in AWTEventListenerProxy Reviewed-by: aivanov, dnguyen ! src/java.desktop/share/classes/java/awt/Toolkit.java ! test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java Changeset: 84002d12 Branch: hermetic-java-runtime Author: Jaikiran Pai Date: 2025-05-31 13:02:58 +0000 URL: https://git.openjdk.org/leyden/commit/84002d12ed83c8254422fdda349aa647422d0768 8228773: URLClassLoader constructors should include API note warning that the parent should not be null Reviewed-by: alanb, mullan ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/security/SecureClassLoader.java Changeset: a3f9e222 Branch: hermetic-java-runtime Author: Jaikiran Pai Date: 2025-05-31 16:31:24 +0000 URL: https://git.openjdk.org/leyden/commit/a3f9e222632d29982ef1463e6c391d5896524705 8358218: Problemlist jdk/incubator/vector/PreferredSpeciesTest.java#id0 Reviewed-by: psandoz ! test/jdk/ProblemList.txt Changeset: fc3d3d9b Branch: hermetic-java-runtime Author: Srinivas Vamsi Parasa Committer: Sandhya Viswanathan Date: 2025-05-31 23:07:55 +0000 URL: https://git.openjdk.org/leyden/commit/fc3d3d9b303652275599e315b2d7e534d92080ea 8351994: Enable Extended EVEX to REX2/REX demotion when src and dst are the same Reviewed-by: sviswanathan, jbhateja, epeter ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! test/hotspot/gtest/x86/asmtest.out.h ! test/hotspot/gtest/x86/test_assembler_x86.cpp ! test/hotspot/gtest/x86/x86-asmtest.py Changeset: 59dc8499 Branch: hermetic-java-runtime Author: Ashutosh Mehra Date: 2025-06-01 01:04:54 +0000 URL: https://git.openjdk.org/leyden/commit/59dc849909c1edc892c94a27b0340fcf53db3a98 8358230: Incorrect location for the assert for blob != nullptr in CodeBlob::create Reviewed-by: kvn ! src/hotspot/share/code/codeBlob.cpp Changeset: 470ffeed Branch: hermetic-java-runtime Author: Mikhail Yankelevich Committer: Jaikiran Pai Date: 2025-06-01 03:50:39 +0000 URL: https://git.openjdk.org/leyden/commit/470ffeedda45b6f75ce0c794a965428b7859be6f 8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java Reviewed-by: rhalade ! test/jdk/sun/security/pkcs11/Serialize/SerializeProvider.java Changeset: e3eb089d Branch: hermetic-java-runtime Author: Vladimir Kozlov Date: 2025-06-01 03:57:28 +0000 URL: https://git.openjdk.org/leyden/commit/e3eb089d47d62ae6feeba3dc6b3752a025e27bed 8357175: Failure to generate or load AOT code should be handled gracefully Reviewed-by: iveresov, asmehra ! src/hotspot/share/code/aotCodeCache.cpp ! src/hotspot/share/code/aotCodeCache.hpp Changeset: ac9af69e Branch: hermetic-java-runtime Author: Alan Bateman Date: 2025-06-01 06:17:50 +0000 URL: https://git.openjdk.org/leyden/commit/ac9af69eee9636ff98c2b60224964e518aebb421 8357637: Native resources cached in thread locals not released when FJP common pool threads clears thread locals Reviewed-by: vklang ! src/java.base/share/classes/java/lang/InheritableThreadLocal.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/ThreadLocal.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/misc/CarrierThreadLocal.java ! src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java ! src/java.base/share/classes/sun/nio/ch/IOVecWrapper.java ! test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java Changeset: c1b5f62a Branch: hermetic-java-runtime Author: Matthias Baesken Date: 2025-06-01 09:06:04 +0000 URL: https://git.openjdk.org/leyden/commit/c1b5f62a8c30038d3b1a14d184535ba0642d51c9 8358136: Make langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java intermittent Reviewed-by: jpai, nbenalla, syan ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java Changeset: 85e36d79 Branch: hermetic-java-runtime Author: Igor Veresov Date: 2025-06-01 21:21:27 +0000 URL: https://git.openjdk.org/leyden/commit/85e36d79246913abb8b85c2be719670655d619ab 8358236: [AOT] Graal crashes when trying to use persisted MDOs Reviewed-by: kvn ! src/hotspot/share/oops/methodData.cpp Changeset: 3193a28c Branch: hermetic-java-runtime Author: David Holmes Date: 2025-06-01 23:36:25 +0000 URL: https://git.openjdk.org/leyden/commit/3193a28c532d8536d621c99bb661304c49ca13e1 8358259: ProblemList compiler/startup/StartupOutput.java on Windows Reviewed-by: darcy ! test/hotspot/jtreg/ProblemList.txt Changeset: 90d6ad01 Branch: hermetic-java-runtime Author: Prasanta Sadhukhan Date: 2025-06-02 02:06:06 +0000 URL: https://git.openjdk.org/leyden/commit/90d6ad015714b81064dd16d0e64f1b774e68d4f3 8356594: JSplitPane loses divider location when reopened via JOptionPane.createDialog() Reviewed-by: kizune ! src/java.desktop/share/classes/javax/swing/JSplitPane.java + test/jdk/javax/swing/JSplitPane/TestSplitPaneResetDividerLoc.java Changeset: c5a1543e Branch: hermetic-java-runtime Author: Robbin Ehn Date: 2025-06-02 05:43:20 +0000 URL: https://git.openjdk.org/leyden/commit/c5a1543ee3e68775f09ca29fb07efd9aebfdb33e 8357968: RISC-V: Interpreter volatile reference stores with G1 are not sequentially consistent Reviewed-by: eosterlund, fbredberg, shade, fyang ! src/hotspot/cpu/riscv/templateTable_riscv.cpp Changeset: 3f59bfd2 Branch: hermetic-java-runtime Author: Thomas Schatzl Date: 2025-06-02 07:59:10 +0000 URL: https://git.openjdk.org/leyden/commit/3f59bfd2e1b35e10fe736e2fa6886cff74ecd35d 8334759: gc/g1/TestMixedGCLiveThreshold.java fails on Windows with JTREG_TEST_THREAD_FACTORY=Virtual due to extra memory allocation Reviewed-by: ayang, iwalulya ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/gc/g1/TestMixedGCLiveThreshold.java Changeset: 64183062 Branch: hermetic-java-runtime Author: Albert Mingkun Yang Date: 2025-06-02 08:23:06 +0000 URL: https://git.openjdk.org/leyden/commit/6418306211be47063a9b06bad8003dee1d81570c 8357944: Remove unused CollectedHeap::is_maximal_no_gc Reviewed-by: jsikstro, tschatzl ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psOldGen.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp Changeset: 40ce05d4 Branch: hermetic-java-runtime Author: Martin Doerr Date: 2025-06-02 08:28:10 +0000 URL: https://git.openjdk.org/leyden/commit/40ce05d4080a9a2b4876c21f83a184f9b8a580a2 8358231: Template interpreter generator crashes with ShouldNotReachHere on some platforms after 8353686 Reviewed-by: shade, amitkumar, mbaesken, kvn ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp Changeset: ba9f44c9 Branch: hermetic-java-runtime Author: Martin Doerr Date: 2025-06-02 08:31:10 +0000 URL: https://git.openjdk.org/leyden/commit/ba9f44c90fe8da2d97d67b6878ac2c0c14e35bd0 8357793: [PPC64] VM crashes with -XX:-UseSIGTRAP -XX:-ImplicitNullChecks Reviewed-by: shade, dbriemann ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp Changeset: a9e7a74d Branch: hermetic-java-runtime Author: Guoxiong Li Date: 2025-06-02 08:47:36 +0000 URL: https://git.openjdk.org/leyden/commit/a9e7a74d00fe1c8d3179392738bb15d8e3508b3a 8357109: Parallel: Fix typo in YoungedGeneration Reviewed-by: ayang, zgu, tschatzl ! src/hotspot/share/gc/shared/gc_globals.hpp Changeset: eb9badd8 Branch: hermetic-java-runtime Author: Roman Kennke Date: 2025-06-02 08:57:16 +0000 URL: https://git.openjdk.org/leyden/commit/eb9badd8a4ea6dca834525fd49429e2ce771a76c 8358169: Shenandoah/JVMCI: Export GC state constants Reviewed-by: dnsimon, shade ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 612f2c0c Branch: hermetic-java-runtime Author: Martin Doerr Date: 2025-06-02 09:21:31 +0000 URL: https://git.openjdk.org/leyden/commit/612f2c0c0b75466c60d4b54dab6aa793a810c846 8357981: [PPC64] Remove old instructions from VM_Version::determine_features() Reviewed-by: dbriemann, mbaesken ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.hpp Changeset: 83cb0c6d Branch: hermetic-java-runtime Author: Viktor Klang Date: 2025-06-02 09:22:37 +0000 URL: https://git.openjdk.org/leyden/commit/83cb0c6de5988de526545d0926c2c6ef60efc1c7 8358151: Harden JSR166 Test case testShutdownNow_delayedTasks Reviewed-by: alanb, shade ! test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java Changeset: c22af0c2 Branch: hermetic-java-runtime Author: Coleen Phillimore Date: 2025-06-02 11:50:50 +0000 URL: https://git.openjdk.org/leyden/commit/c22af0c29ea89857c5cf57dd127b5c739130b2f1 8358205: Remove unused JFR array allocation code Reviewed-by: kbarrett, mgronlun ! src/hotspot/share/jfr/jni/jfrJavaCall.cpp ! src/hotspot/share/jfr/jni/jfrJavaCall.hpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp ! src/hotspot/share/memory/oopFactory.cpp Changeset: 83b15da2 Branch: hermetic-java-runtime Author: Erik ?sterlund Date: 2025-06-02 12:26:08 +0000 URL: https://git.openjdk.org/leyden/commit/83b15da2eb3cb6c8937f517c9b75eaa9eeece314 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent Reviewed-by: shade, aph, fbredberg ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Changeset: b3594c9e Branch: hermetic-java-runtime Author: Aleksey Shipilev Date: 2025-06-02 13:08:41 +0000 URL: https://git.openjdk.org/leyden/commit/b3594c9e5508101a39d10099830f04b0c09ad41f 8357481: Excessive CompileTask wait/notify monitor creation Reviewed-by: vlivanov, kvn ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: a4eb1519 Branch: hermetic-java-runtime Author: Phil Race Date: 2025-06-02 15:24:09 +0000 URL: https://git.openjdk.org/leyden/commit/a4eb15195ceeadf311fe81e622a54f4733b90df2 8357672: Extreme font sizes can cause font substitution Reviewed-by: dmarkov, jdv ! src/java.desktop/share/classes/sun/font/FileFontStrike.java ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c ! test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java Changeset: daab7b5c Branch: hermetic-java-runtime Author: Hannes Walln?fer Date: 2025-06-02 15:27:14 +0000 URL: https://git.openjdk.org/leyden/commit/daab7b5ceeb12222bda709e35699e620b98cb74d 8357796: Stylesheet adjustments after JDK-8357452 Reviewed-by: rriggs ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css Changeset: 1b6ae205 Branch: hermetic-java-runtime Author: Matias Saavedra Silva Date: 2025-06-02 15:29:30 +0000 URL: https://git.openjdk.org/leyden/commit/1b6ae2059b0475ec78559d2d6612f3b6ec68309f 8357576: FieldInfo::_index is not initialized by the constructor Reviewed-by: coleenp, dholmes ! src/hotspot/share/oops/fieldInfo.hpp Changeset: 99a4b22a Branch: hermetic-java-runtime Author: William Kemper Date: 2025-06-02 16:48:16 +0000 URL: https://git.openjdk.org/leyden/commit/99a4b22ae7dc2755df1780cc7d74c5d6e3cd4cd4 8358102: GenShen: Age tables could be seeded with cumulative values Reviewed-by: ysr ! src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp Changeset: ab5de456 Branch: hermetic-java-runtime Author: Magnus Ihse Bursie Date: 2025-06-02 16:50:10 +0000 URL: https://git.openjdk.org/leyden/commit/ab5de45636f0bf96e52c0ae0dcf080f279d9caee 8357991: make bootcycle-images is broken after JDK-8349665 Reviewed-by: erikj ! make/Main.gmk Changeset: 8b6a11f7 Branch: hermetic-java-runtime Author: Calvin Cheung Date: 2025-06-02 16:51:44 +0000 URL: https://git.openjdk.org/leyden/commit/8b6a11f7e05ee0cece798c5ff6646bddbee04900 8352187: Don't start management agent during AOT cache creation Reviewed-by: shade, iklam, kvn ! src/hotspot/share/runtime/threads.cpp + test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java Changeset: bce2bd24 Branch: hermetic-java-runtime Author: Ioi Lam Date: 2025-06-02 16:52:05 +0000 URL: https://git.openjdk.org/leyden/commit/bce2bd24ef64e71d895bbf4d91693b30a285746b 8356308: Assert with -Xlog:class+path when classpath has an empty element Reviewed-by: dholmes, ccheung ! src/hotspot/share/cds/aotClassLocation.cpp ! src/hotspot/share/cds/aotClassLocation.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/utilities/classpathStream.cpp ! src/hotspot/share/utilities/classpathStream.hpp ! test/hotspot/jtreg/runtime/cds/appcds/PrintSharedArchiveAndExit.java + test/hotspot/jtreg/runtime/cds/appcds/aotCache/ClassPathLogging.java Changeset: a7671e73 Branch: hermetic-java-runtime Author: Magnus Ihse Bursie Date: 2025-06-02 17:06:45 +0000 URL: https://git.openjdk.org/leyden/commit/a7671e7360ce23df9577110266e66a1c1a790196 8358337: JDK-8357991 was committed with incorrect indentation Reviewed-by: shade ! make/Main.gmk Changeset: ec02a87a Branch: hermetic-java-runtime Author: Alex Menkov Date: 2025-06-02 18:13:24 +0000 URL: https://git.openjdk.org/leyden/commit/ec02a87aeef008f6b2f94001fa33bac66bf24627 8345745: Update mode of the Attach API communication pipe. Reviewed-by: sspitsyn, kevinw ! src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c Changeset: 1373ceb7 Branch: hermetic-java-runtime Author: Erik Gahlin Date: 2025-06-02 18:22:35 +0000 URL: https://git.openjdk.org/leyden/commit/1373ceb7f3040a03ae142cfaab0f74894fc6a0a3 8356698: JFR: @Contextual Reviewed-by: mgronlun + src/jdk.jfr/share/classes/jdk/jfr/Contextual.java ! src/jdk.jfr/share/classes/jdk/jfr/events/MethodTraceEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java + test/jdk/jdk/jfr/tool/TestPrintContextual.java Changeset: 5243f385 Branch: hermetic-java-runtime Author: Chris Plummer Date: 2025-06-02 19:07:29 +0000 URL: https://git.openjdk.org/leyden/commit/5243f3851b0345b874ff51ea3a07e82f73741546 8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64 Reviewed-by: syan, dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: 86b40f52 Branch: hermetic-java-runtime Author: Jiangli Zhou Date: 2025-06-02 13:11:58 +0000 URL: https://git.openjdk.org/leyden/commit/86b40f52140e42c09761548b92991d60e8977cd9 Merge branch 'master' into hermetic-java-runtime ! make/Main.gmk ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/threads.cpp ! src/java.base/unix/native/libjava/childproc.c ! make/Main.gmk ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/threads.cpp ! src/java.base/unix/native/libjava/childproc.c From shade at openjdk.org Mon Jun 2 21:20:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 21:20:23 GMT Subject: RFR: Fix recent merge errors [v2] In-Reply-To: References: Message-ID: > I skipped through current premain-vs-mainline webrev, and noticed a few merge errors. > > `metaspaceShared.cpp` hunks are obvious duplications. I removed the lines that are actually different from mainline. > > ~`compilationPolicy.hpp` hunk is a leftover from AOT Profiling. I remember pointing this out to @veresov during mainline review, and we went into mainline without that extra `notify_all`. We should ditch it in premain too.~ Actually, I see test timeouts when that `notify_all` is removed. Filed [JDK-8358343](https://bugs.openjdk.org/browse/JDK-8358343) to figure it out. Yanked the hunk from this PR. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Put notify_all back ------------- Changes: - all: https://git.openjdk.org/leyden/pull/72/files - new: https://git.openjdk.org/leyden/pull/72/files/0262c563..ac9c2a78 Webrevs: - full: https://webrevs.openjdk.org/?repo=leyden&pr=72&range=01 - incr: https://webrevs.openjdk.org/?repo=leyden&pr=72&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/leyden/pull/72.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/72/head:pull/72 PR: https://git.openjdk.org/leyden/pull/72 From iveresov at openjdk.org Mon Jun 2 23:00:14 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 2 Jun 2025 23:00:14 GMT Subject: RFR: Fix recent merge errors [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 21:20:23 GMT, Aleksey Shipilev wrote: >> I skipped through current premain-vs-mainline webrev, and noticed a few merge errors. >> >> `metaspaceShared.cpp` hunks are obvious duplications. I removed the lines that are actually different from mainline. >> >> ~`compilationPolicy.hpp` hunk is a leftover from AOT Profiling. I remember pointing this out to @veresov during mainline review, and we went into mainline without that extra `notify_all`. We should ditch it in premain too.~ Actually, I see test timeouts when that `notify_all` is removed. Filed [JDK-8358343](https://bugs.openjdk.org/browse/JDK-8358343) to figure it out. Yanked the hunk from this PR. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `runtime/cds` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Put notify_all back Marked as reviewed by iveresov (Committer). ------------- PR Review: https://git.openjdk.org/leyden/pull/72#pullrequestreview-2890151659 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 kvn at openjdk.org Mon Jun 2 23:54:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 2 Jun 2025 23:54:14 GMT Subject: RFR: Fix recent merge errors [v2] In-Reply-To: References: Message-ID: <5-j4wDhlYH3CFrpr9ekAv4icDNouWHDvyMb92HJ4_Tw=.eab05923-55ee-4001-a9a8-30d414d82e95@github.com> On Mon, 2 Jun 2025 21:20:23 GMT, Aleksey Shipilev wrote: >> I skipped through current premain-vs-mainline webrev, and noticed a few merge errors. >> >> `metaspaceShared.cpp` hunks are obvious duplications. I removed the lines that are actually different from mainline. >> >> ~`compilationPolicy.hpp` hunk is a leftover from AOT Profiling. I remember pointing this out to @veresov during mainline review, and we went into mainline without that extra `notify_all`. We should ditch it in premain too.~ Actually, I see test timeouts when that `notify_all` is removed. Filed [JDK-8358343](https://bugs.openjdk.org/browse/JDK-8358343) to figure it out. Yanked the hunk from this PR. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `runtime/cds` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Put notify_all back Good. ------------- Marked as reviewed by kvn (Committer). PR Review: https://git.openjdk.org/leyden/pull/72#pullrequestreview-2890216157 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 shade at openjdk.org Tue Jun 3 07:02:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 07:02:16 GMT Subject: git: openjdk/leyden: premain: Fix recent merge errors Message-ID: <75fb4326-e7f8-4a77-af2e-b9a0f6889881@openjdk.org> Changeset: dd845008 Branch: premain Author: Aleksey Shipilev Date: 2025-06-03 07:00:44 +0000 URL: https://git.openjdk.org/leyden/commit/dd845008ac031c070cd2b282572eeeac4ef978f1 Fix recent merge errors Reviewed-by: iveresov, kvn ! src/hotspot/share/cds/metaspaceShared.cpp From shade at openjdk.org Tue Jun 3 07:03:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 07:03:19 GMT Subject: Integrated: Fix recent merge errors In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 20:12:18 GMT, Aleksey Shipilev wrote: > I skipped through current premain-vs-mainline webrev, and noticed a few merge errors. > > `metaspaceShared.cpp` hunks are obvious duplications. I removed the lines that are actually different from mainline. > > ~`compilationPolicy.hpp` hunk is a leftover from AOT Profiling. I remember pointing this out to @veresov during mainline review, and we went into mainline without that extra `notify_all`. We should ditch it in premain too.~ Actually, I see test timeouts when that `notify_all` is removed. Filed [JDK-8358343](https://bugs.openjdk.org/browse/JDK-8358343) to figure it out. Yanked the hunk from this PR. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` This pull request has now been integrated. Changeset: dd845008 Author: Aleksey Shipilev URL: https://git.openjdk.org/leyden/commit/dd845008ac031c070cd2b282572eeeac4ef978f1 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Fix recent merge errors Reviewed-by: iveresov, kvn ------------- PR: https://git.openjdk.org/leyden/pull/72 From shade at openjdk.org Tue Jun 3 07:03:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 07:03:19 GMT Subject: RFR: Fix recent merge errors [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 21:20:23 GMT, Aleksey Shipilev wrote: >> I skipped through current premain-vs-mainline webrev, and noticed a few merge errors. >> >> `metaspaceShared.cpp` hunks are obvious duplications. I removed the lines that are actually different from mainline. >> >> ~`compilationPolicy.hpp` hunk is a leftover from AOT Profiling. I remember pointing this out to @veresov during mainline review, and we went into mainline without that extra `notify_all`. We should ditch it in premain too.~ Actually, I see test timeouts when that `notify_all` is removed. Filed [JDK-8358343](https://bugs.openjdk.org/browse/JDK-8358343) to figure it out. Yanked the hunk from this PR. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `runtime/cds` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Put notify_all back Thanks! ------------- PR Comment: https://git.openjdk.org/leyden/pull/72#issuecomment-2933784463 From shade at openjdk.org Tue Jun 3 08:36:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 08:36:53 GMT Subject: RFR: 8358344: [leyden] Enable UseSecondarySupersTable support Message-ID: `UseSecondarySupersTable` was disabled during the merge last month. It is time to enable it back. We need to record the table and slowpaths for `id_for_address` to work. `SECONDARY_SUPERS_TABLE_SIZE` is realistically at most `64` (matches machine bitness), so I added `+70` to all relevant sizing constants. Additional testing: - [x] Linux x86_64 server fastdebug, `runtime/cds` works (used to fail with just `UseSecondarySupersTable = false` removed) ------------- Commit messages: - Fix Changes: https://git.openjdk.org/leyden/pull/73/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=73&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358344 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.org/leyden/pull/73.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/73/head:pull/73 PR: https://git.openjdk.org/leyden/pull/73 From asmehra at openjdk.org Tue Jun 3 14:10:22 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 3 Jun 2025 14:10:22 GMT Subject: RFR: 8358344: [leyden] Enable UseSecondarySupersTable support In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 08:31:32 GMT, Aleksey Shipilev wrote: > `UseSecondarySupersTable` was disabled during the merge last month. It is time to enable it back. We need to record the table and slowpaths for `id_for_address` to work. `SECONDARY_SUPERS_TABLE_SIZE` is realistically at most `64` (matches machine bitness), so I added `+70` to all relevant sizing constants. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` works (used to fail with just `UseSecondarySupersTable = false` removed) lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/leyden/pull/73#pullrequestreview-2892569933 From kvn at openjdk.org Tue Jun 3 17:07:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 3 Jun 2025 17:07:14 GMT Subject: RFR: 8358344: [leyden] Enable UseSecondarySupersTable support In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 08:31:32 GMT, Aleksey Shipilev wrote: > `UseSecondarySupersTable` was disabled during the merge last month. It is time to enable it back. We need to record the table and slowpaths for `id_for_address` to work. `SECONDARY_SUPERS_TABLE_SIZE` is realistically at most `64` (matches machine bitness), so I added `+70` to all relevant sizing constants. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` works (used to fail with just `UseSecondarySupersTable = false` removed) Looks good. Let me test it. ------------- PR Review: https://git.openjdk.org/leyden/pull/73#pullrequestreview-2893378314 From shade at openjdk.org Tue Jun 3 18:14:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 18:14:52 GMT Subject: RFR: 8358343: [leyden] Drop notify_all in CompilationPolicyUtils::Queue::pop Message-ID: Found this when reading premain-vs-mainline webrev. Mainline does not have `notify_all` in this method: https://github.com/openjdk/jdk/blob/c382da579884c28f2765b2c6ba68c0ad4fdcb2ce/src/hotspot/share/compiler/compilationPolicy.hpp#L85-L92 But if you remove `notify_all()` in `premain`, then tests start to deadlock, see bug for a sample. The culprit is `CompilationPolicy::flush_replay_training_at_init`, which is only present in premain. I fixed it by using timed waits, which obviates the need for extra notifications. We only enter this method with `-XX:+AOTVerifyTrainingData`, so we don't care much about its performance. This is IMO better than doing a questionable `notify_all` followed by `wait` in load-bearing code. Additional testing: - [x] Linux x86_64 server fastdebug, `runtime/cds` (5x, no timeouts yet; still running more iterations) ------------- Commit messages: - Fix Changes: https://git.openjdk.org/leyden/pull/74/files Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=74&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358343 Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/leyden/pull/74.diff Fetch: git fetch https://git.openjdk.org/leyden.git pull/74/head:pull/74 PR: https://git.openjdk.org/leyden/pull/74 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 kvn at openjdk.org Tue Jun 3 19:31:32 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 3 Jun 2025 19:31:32 GMT Subject: RFR: 8358344: [leyden] Enable UseSecondarySupersTable support In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 08:31:32 GMT, Aleksey Shipilev wrote: > `UseSecondarySupersTable` was disabled during the merge last month. It is time to enable it back. We need to record the table and slowpaths for `id_for_address` to work. `SECONDARY_SUPERS_TABLE_SIZE` is realistically at most `64` (matches machine bitness), so I added `+70` to all relevant sizing constants. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` works (used to fail with just `UseSecondarySupersTable = false` removed) My testing passed. ------------- Marked as reviewed by kvn (Committer). PR Review: https://git.openjdk.org/leyden/pull/73#pullrequestreview-2893823432 From shade at openjdk.org Tue Jun 3 19:59:47 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 19:59:47 GMT Subject: git: openjdk/leyden: premain: 8358344: [leyden] Enable UseSecondarySupersTable support Message-ID: <784fe44f-00fd-48d1-aa21-94816fb15698@openjdk.org> Changeset: 1c750fab Branch: premain Author: Aleksey Shipilev Date: 2025-06-03 19:58:41 +0000 URL: https://git.openjdk.org/leyden/commit/1c750fabd45807f648891711576f4bc15185087b 8358344: [leyden] Enable UseSecondarySupersTable support Reviewed-by: asmehra, kvn ! src/hotspot/share/code/aotCodeCache.cpp ! src/hotspot/share/runtime/arguments.cpp From shade at openjdk.org Tue Jun 3 20:00:44 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 20:00:44 GMT Subject: RFR: 8358343: [leyden] Drop notify_all in CompilationPolicyUtils::Queue::pop In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 17:59:51 GMT, Aleksey Shipilev wrote: > Found this when reading premain-vs-mainline webrev. Mainline does not have `notify_all` in this method: > https://github.com/openjdk/jdk/blob/c382da579884c28f2765b2c6ba68c0ad4fdcb2ce/src/hotspot/share/compiler/compilationPolicy.hpp#L85-L92 > > But if you remove `notify_all()` in `premain`, then tests start to deadlock, see bug for a sample. The culprit is `CompilationPolicy::flush_replay_training_at_init`, which is only present in premain. I fixed it by using timed waits, which obviates the need for extra notifications. We only enter this method with `-XX:+AOTVerifyTrainingData`, so we don't care much about its performance. This is IMO better than doing a questionable `notify_all` followed by `wait` in load-bearing code. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` (5x, no timeouts yet; still running more iterations) @veresov @iwanowww ^ ------------- PR Comment: https://git.openjdk.org/leyden/pull/74#issuecomment-2936964207 From shade at openjdk.org Tue Jun 3 20:02:08 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 20:02:08 GMT Subject: Integrated: 8358344: [leyden] Enable UseSecondarySupersTable support In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 08:31:32 GMT, Aleksey Shipilev wrote: > `UseSecondarySupersTable` was disabled during the merge last month. It is time to enable it back. We need to record the table and slowpaths for `id_for_address` to work. `SECONDARY_SUPERS_TABLE_SIZE` is realistically at most `64` (matches machine bitness), so I added `+70` to all relevant sizing constants. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` works (used to fail with just `UseSecondarySupersTable = false` removed) This pull request has now been integrated. Changeset: 1c750fab Author: Aleksey Shipilev URL: https://git.openjdk.org/leyden/commit/1c750fabd45807f648891711576f4bc15185087b Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod 8358344: [leyden] Enable UseSecondarySupersTable support Reviewed-by: asmehra, kvn ------------- PR: https://git.openjdk.org/leyden/pull/73 From shade at openjdk.org Tue Jun 3 20:02:08 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 3 Jun 2025 20:02:08 GMT Subject: RFR: 8358344: [leyden] Enable UseSecondarySupersTable support In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 08:31:32 GMT, Aleksey Shipilev wrote: > `UseSecondarySupersTable` was disabled during the merge last month. It is time to enable it back. We need to record the table and slowpaths for `id_for_address` to work. `SECONDARY_SUPERS_TABLE_SIZE` is realistically at most `64` (matches machine bitness), so I added `+70` to all relevant sizing constants. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` works (used to fail with just `UseSecondarySupersTable = false` removed) Cool, here goes. ------------- PR Comment: https://git.openjdk.org/leyden/pull/73#issuecomment-2936963476 From kvn at openjdk.org Wed Jun 4 00:13:39 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 4 Jun 2025 00:13:39 GMT Subject: RFR: Update nmethod caching and clean up unused/duplicate methods [v3] In-Reply-To: References: <0PPJcYIoaEOrvEmUuBNSrnRpC4CybPhNuNtsHfHCYwE=.2a66d441-7a27-4cef-8c78-d1552757fecc@github.com> Message-ID: On Mon, 2 Jun 2025 14:51:47 GMT, Ashutosh Mehra wrote: >> This PR updates nmethod caching to be based on caching of CodeBlob. It also cleans up some dead code and duplicate methods. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Remove CodeBuffer::clear_strings() as the relevant destructors clear the > strings > > Signed-off-by: Ashutosh Mehra Before I start testing and approve it I think we should wait your fix JDK-8358330 integration (my testing is still running) and then merge from mainline to premain. src/hotspot/share/code/aotCodeCache.hpp line 107: > 105: > 106: uint _blob_offset; // Start of archived blob in the cache > 107: uint _code_offset; // Start of code for an entry of type "Stub" Why you need 2 different fields for offset? ------------- PR Comment: https://git.openjdk.org/leyden/pull/71#issuecomment-2937805951 PR Review Comment: https://git.openjdk.org/leyden/pull/71#discussion_r2125152991 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