From sviswanathan at openjdk.org Sat Mar 1 00:42:53 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Sat, 1 Mar 2025 00:42:53 GMT Subject: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024 In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote: > Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays. test/micro/org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java line 51: > 49: @Setup(Level.Trial) > 50: public void Setup() { > 51: mask = new boolean[size + 64]; Any reason, for this to be "size + 64" instead of "size"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23783#discussion_r1976173627 From vaivanov at openjdk.org Sat Mar 1 00:49:53 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 1 Mar 2025 00:49:53 GMT Subject: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024 In-Reply-To: References: Message-ID: <6XdOo_ZiYQmC1CgsnAhT7FTE_-3CaoAwrDIK7k-1H9M=.7bf47272-2d4f-47b2-95c8-ff8f1254b70c@github.com> On Sat, 1 Mar 2025 00:40:26 GMT, Sandhya Viswanathan wrote: >> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays. > > test/micro/org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java line 51: > >> 49: @Setup(Level.Trial) >> 50: public void Setup() { >> 51: mask = new boolean[size + 64]; > > Any reason, for this to be "size + 64" instead of "size"? This array iterated by steps from 8 to 64. If allocated array less than 64 it throws Exception. Minimal array size is VectorSpecies for byte class. The constant was used instead of calculation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23783#discussion_r1976181678 From joehw at openjdk.org Sat Mar 1 01:19:17 2025 From: joehw at openjdk.org (Joe Wang) Date: Sat, 1 Mar 2025 01:19:17 GMT Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA [v2] In-Reply-To: References: Message-ID: > Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc). Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove commented section ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23847/files - new: https://git.openjdk.org/jdk/pull/23847/files/70fc2ca5..2d4b7653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23847&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23847&range=00-01 Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23847.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23847/head:pull/23847 PR: https://git.openjdk.org/jdk/pull/23847 From joehw at openjdk.org Sat Mar 1 01:19:17 2025 From: joehw at openjdk.org (Joe Wang) Date: Sat, 1 Mar 2025 01:19:17 GMT Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA [v2] In-Reply-To: References: <7zxz6_G_TmXAP2BlpuFRND7wlK6_zAsIszPiZbRIPUg=.001da59a-2818-491a-8e88-36b4e043a807@github.com> Message-ID: <9a8Y2Wi_XILdexh1DvOsv9eVAsTfgn2kp7nKnkVc1nI=.c5b9ce52-aa1c-4326-b3e3-df01cec9db6a@github.com> On Fri, 28 Feb 2025 23:02:28 GMT, Naoto Sato wrote: >> Hi Naoto, >> >> Yes, I did look through that code and bug 5046319. Unfortunately, it happened when JAXP was standalone, the history of the change was lost. >> The variable "buf" seems to be an instance variable that serves to cache the text read. That part had been changed as well. Furthermore, if buf starts with zero length, the call to getTextCharacters would still result in IndexOutOfBoundsException. >> >> Maybe the commented code can be removed, I kept them as is in case they may be useful reference as a history. > > OK, then I'd suggest removing the above comment and commented section altogether, as it only provides confusion. Yeah, agree. The code is stable as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23847#discussion_r1976196910 From mik3hall at gmail.com Sat Mar 1 03:39:40 2025 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 28 Feb 2025 21:39:40 -0600 Subject: RFR: 8350594: Misleading warning about install dir for DMG packaging In-Reply-To: <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com> References: <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com> <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com> <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com> <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com> <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com> <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com> Message-ID: <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com> > On Feb 27, 2025, at 11:43?AM, Alexey Semenyuk wrote: > > Thank you for trying it out! I'll look closer at the issues you reported and get back to you. I put something up on my trying it out if helpful when you get a chance to look at it. MacOS system JRE in JavaVirtualMachines with jpackage http://mikehall.pairserver.com/sysjdk.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Sat Mar 1 07:50:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 1 Mar 2025 07:50:44 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v3] In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: > Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? > > As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. > > The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. > > I'll draft a CSR once we agree on the proposed text. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - change "@implSpec" to "@apiNote" and update their text - add class level documentation - merge latest from master branch - add tests - update DeflaterInputStream and InflaterInputStream - 8066583: DeflaterOutputStream and InflaterOutputStream should explain responsibility for freeing resources ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23655/files - new: https://git.openjdk.org/jdk/pull/23655/files/102b04a4..80af3b35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=01-02 Stats: 18908 lines in 548 files changed: 10633 ins; 6323 del; 1952 mod Patch: https://git.openjdk.org/jdk/pull/23655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655 PR: https://git.openjdk.org/jdk/pull/23655 From jpai at openjdk.org Sat Mar 1 07:57:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 1 Mar 2025 07:57:54 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v3] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: <1k1BcfNeju6coF0ivlUuOCvlbOKPr8tJxz9DoTP77g8=.04270ed5-8311-4174-95f5-17f300220b6e@github.com> On Sat, 1 Mar 2025 07:50:44 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. >> >> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. >> >> I'll draft a CSR once we agree on the proposed text. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - change "@implSpec" to "@apiNote" and update their text > - add class level documentation > - merge latest from master branch > - add tests > - update DeflaterInputStream and InflaterInputStream > - 8066583: DeflaterOutputStream and InflaterOutputStream should explain responsibility for freeing resources Given the inputs from Alan, Eirik and Lance, I have now updated this PR to introduce a class level (linkable) text explaining the differences between these constructors and how/when the Inflater/Deflater is closed. The proposed `@implSpec` on the constructors has been changed to a brief `@apiNote` linking back to this class level text. The javadoc of `close()` methods too is updated to include a brief `@apiNote` linking back to the class level javadoc. Does this look better? > perhaps with an example snippet demonstrating a safe use of the API class I haven't included a snippet in the class level doc, because the class level doc of `Deflater/Inflater` already has the necessary snippet on how to use (and close) a `Deflater/Inflater`. Adding one in these classes would need to take into account the fact that a `Deflater`/`Inflater` that has been passed to these classes need not necessarily be closed by the application after these Input/OutputStream instances have been closed. The application is free to keep using those `Deflater`/`Inflater` instances as long as it wants to and in fact, the application can even invoke `reset()` on those instances to reuse them for additional operations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2692048697 From dl at openjdk.org Sat Mar 1 15:43:17 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 1 Mar 2025 15:43:17 GMT Subject: RFR: 8319447: Improve performance of delayed task handling [v6] In-Reply-To: References: Message-ID: > (Copied from https://bugs.openjdk.org/browse/JDK-8319447) > > The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern. > > We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements. > > A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced. > > Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela... Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Reduce volatile reads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23702/files - new: https://git.openjdk.org/jdk/pull/23702/files/b40513fb..0c5d22a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=04-05 Stats: 50 lines in 1 file changed: 18 ins; 14 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/23702.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702 PR: https://git.openjdk.org/jdk/pull/23702 From duke at openjdk.org Sun Mar 2 03:22:55 2025 From: duke at openjdk.org (Jason Mehrens) Date: Sun, 2 Mar 2025 03:22:55 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v10] In-Reply-To: <7Zm7nh3mSJQ-Qch5mPaPksEivxbZe_zAjm5TBNTpStY=.1d774849-e2b0-4a77-bb61-527d154b2476@github.com> References: <7Zm7nh3mSJQ-Qch5mPaPksEivxbZe_zAjm5TBNTpStY=.1d774849-e2b0-4a77-bb61-527d154b2476@github.com> Message-ID: On Fri, 28 Feb 2025 14:23:49 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. >> 2. Add explanatory comments to various affected methods. >> 3. Add a test to ensure deadlocks no longer occur. >> >> Note that this change does not address issue in MemoryHandler (see JDK-8349208). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Final round of comment tweaks. Marked as reviewed by jmehrens at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2652621993 From duke at openjdk.org Sun Mar 2 03:22:56 2025 From: duke at openjdk.org (Jason Mehrens) Date: Sun, 2 Mar 2025 03:22:56 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v10] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 12:29:04 GMT, David Beaumont wrote: >The former is, in my opinion, a pretty awful user experience... Specifically, I'm referring to this, with awareness of the above described limitations: //String.format is var-arg logger.log(Level.SEVERE, () -> { return String.format("foo=%s bar=%s", arg1, arg2); }); //logger is not var-arg if (logger.isLoggable(lvl)) { //if arg1 and arg2 known to be never null logger.log(lvl, "foo={0} bar={1}", new Object[]{arg1.toString(), arg2.toString()}); } //logger is not var-arg if (logger.isLoggable(lvl)) { //if arg1 and arg2 are nullable logger.log(lvl, "foo={0} bar={1}", new Object[]{Objects.toString(arg1), Objects.toString(arg2)}); } How did you worked around this deadlock issue prior to this patch? That would be awesome information to add to the JIRA ticket for those that would like this patch but are unable to upgrade. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1976531411 From mukulg at apache.org Sun Mar 2 05:21:26 2025 From: mukulg at apache.org (Mukul Gandhi) Date: Sun, 2 Mar 2025 10:51:26 +0530 Subject: adding Xalan's XSL 3 implementation within jdk In-Reply-To: References: Message-ID: Hi Alan, Thanks for your reply. On Thu, 27 Feb, 2025, 13:41 Alan Bateman, wrote: > If you are interested in contributing to the XML implementations in the > java.xml module then this would be welcomed. It's always better to start > small with bug fixes, test improvements and other changes to get used to > working in this project and build up confidence that you are someone that > is interested in maintaining this area in the long term. > I think, I'll find writing Xalan-J XSL 3 specific code changes myself in java.xml module of openjdk useful. Xalan-J XSL 3 code has also required few changes to be made within, Xerces-J code as well (I think to support XPath 3.1 function implementation for fn:deep-equal, specifically for support of collation uris). How should I start modifying openjdk's java.xml code? Do I need to require building openjdk also to verify that nothing has gone wrong, after modifying java.xml's code locally? Is it possible you may point me to correct documentation for building openjdk? Another approach I think may be to have me modify openjdk java.xml's code locally and open a pull request for you all to verify and merge. Any thoughts please? Regards, Mukul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mukulg at apache.org Sun Mar 2 06:19:34 2025 From: mukulg at apache.org (Mukul Gandhi) Date: Sun, 2 Mar 2025 11:49:34 +0530 Subject: adding Xalan's XSL 3 implementation within jdk In-Reply-To: References: Message-ID: Hi Joe, Thanks for nice thoughts. On Fri, 28 Feb, 2025, 00:06 Joe Wang, wrote: > What's your assessment on the readiness for a formal release (or how > much additional work is needed)? What are the conformance test results? > The link here, https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn has a pdf link at bottom of that page which is Xalan-J XSL 3 implementation's latest development status. This link also has documentation about how to run Xalan-J's XSL 3 conformance test suite, which currently has 900+ odd tests supported by Xalan-J covering wide areas of XSLT 3.0 and XPath 3.1 language features. > > Also, do you have data showing how the Xalan-J's XSL 3 implementation is > used in user applications? What are the feedback (or bug reports) from > developers? > I know of few people, particularly https://x.com/XSLT_knowmad?t=ZKJE2bkeVyceZTxTmy1sPg&s=09 and probably others who've been using Xalan-J's XSL 3 implementation. Gary Gregory (Apache Xalan's PMC chair) has also rigorously tested Xalan-J's XSL 3 implementation and reported it to be ok and useful. Many thanks. Regards, Mukul > On 2/26/25 7:59 AM, Mukul Gandhi wrote: > > Hi Alan, > > I've just seen this mail from you. Apologies for a delayed response. > > > > My mail box has had few issues due to the volume of mails that I get > > from mailing lists. > > > > On Sun, Feb 2, 2025 at 9:38?PM Alan Bateman > wrote: > > > >> The stats for that branch suggest 5,845 changed files with 234,372 > additions and 84,058 deletions. I can't easily tell how much of this would > need to come into the jdk repo but this looks like a major update. If only > 10% of this is applicable to the JDK then it still needs seems like a major > update that would require a huge investment to audit and integrate this > code. How much XML is in new applications developed in 2025? Only asking > because it's an area that is surely much lower priority compared to all the > other major investments right now. Maybe there are useful security or > performance changes that would be useful to cherry pick instead? Finally, > does this Xalan update work with the SPIs so that someone really looking > for XSL 3 can just deploy it on the class path and module path? > > Ofcourse, anyone could use Xalan-J's XSL 3 implementation with JDK by > > placing Xalan jars on class path & module path. > > > > Since Xalan-J's XSLT 1.0 & XPath 1.0 implementations are already > > available within JDK, I thought its natural if JDK could pick > > Xalan-J's XSL 3 implementation and include that within JDK. I can > > imagine that this may surely be time consuming for someone from JDK > > team to integrate with JDK. XSLT 1.0's use I think is very less these > > days particularly for new XML projects, due to vast improvements in > > language features offered by XSLT 3.0 and XPath 3.1. > > > > IMHO, I wrote all the XSL 3 implementation code (and solved various > > XSL 3 implementation bugs reported by community on Xalan-J's dev > > forum) within Xalan-J's XSL 3 dev respos branch, enhancing upon > > Xalan-J's XSLT 1.0 implementation. From my point of view, I'll be > > happy if JDK could include Xalan-J's XSL 3 implementation. > > > > I even wrote following two online articles on xml.com about few of XSL > > 3 language features, and how they're implemented within Xalan-J, > > > https://www.xml.com/articles/2024/07/22/string-analysis-with-analyze-string/ > > > https://www.xml.com/articles/2023/12/05/xml-path-language-xpath-higher-order-functions/ > > > > > > Many thanks. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Mar 2 06:55:09 2025 From: duke at openjdk.org (He-Pin (kerr)) Date: Sun, 2 Mar 2025 06:55:09 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v3] In-Reply-To: References: Message-ID: > Motivation: > When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. > > Modification: > Add detail error messages. > > Result: > Helpful messages. He-Pin(kerr) has updated the pull request incrementally with two additional commits since the last revision: - . - . ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23050/files - new: https://git.openjdk.org/jdk/pull/23050/files/dfc2cee7..1e098b28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=01-02 Stats: 85 lines in 2 files changed: 20 ins; 26 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/23050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23050/head:pull/23050 PR: https://git.openjdk.org/jdk/pull/23050 From alan.bateman at oracle.com Sun Mar 2 08:02:03 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sun, 2 Mar 2025 08:02:03 +0000 Subject: adding Xalan's XSL 3 implementation within jdk In-Reply-To: References: Message-ID: <47b467d3-967c-4367-a1f6-f1737012a005@oracle.com> On 02/03/2025 05:21, Mukul Gandhi wrote: > Hi Alan, > ? ? Thanks for your reply. > > On Thu, 27 Feb, 2025, 13:41 Alan Bateman, wrote: > > If you are interested in contributing to the XML implementations > in the java.xml module then this would be welcomed. It's always > better to start small with bug fixes, test improvements and other > changes to get used to working in this project and build up > confidence that you are someone that is interested in maintaining > this area in the long term. > > > I think, I'll find writing Xalan-J XSL 3 specific code changes myself > in java.xml module of openjdk useful. Xalan-J XSL 3 code has also > required few changes to be made within, Xerces-J code as well (I think > to support XPath 3.1 function implementation for fn:deep-equal, > specifically for support of collation uris). > > How should I start modifying openjdk's java.xml code? Do I need to > require building openjdk also to verify that nothing has gone wrong, > after modifying java.xml's code locally? Is it possible you may point > me to correct documentation for building openjdk? > > Another approach I think may be to have me modify openjdk java.xml's > code locally and open a pull request for you all to verify and merge. > > Any thoughts please? > The "Building the JDK" docs [1] has the build instructions, and the Open Developers' Guide [2] has a good section on contributing. Contribution an upgrade to XSL 3 is not a suitable first contribution. That's a potentially JDK Enhancement Proposal (JEP) sized effort and would require a huge amount of work from existing OpenJDK maintainers to establish provenance, review, security audit, and test. I realize you, and the others cc'ed, are experts in the XML field but starting out here will require chopping wood and carrying water before taking on anything significant. There are bugs and issues tracked in the Java Bug System (JBS) in the "xml" component that may be suitable to take on. -Alan [1] https://openjdk.org/groups/build/doc/building.html [2] https://openjdk.org/guide/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vklang at openjdk.org Sun Mar 2 15:52:02 2025 From: vklang at openjdk.org (Viktor Klang) Date: Sun, 2 Mar 2025 15:52:02 GMT Subject: RFR: 8319447: Improve performance of delayed task handling [v6] In-Reply-To: References: Message-ID: On Sat, 1 Mar 2025 15:43:17 GMT, Doug Lea
wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern. >> >> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements. >> >> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced. >> >> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh... > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Reduce volatile reads src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 255: > 253: U.park(false, parkTime); > 254: } > 255: q = pending; Does this "win" over a continue; here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1976658243 From sgehwolf at openjdk.org Sun Mar 2 19:10:06 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Sun, 2 Mar 2025 19:10:06 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v17] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright headers OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2652794986 From schernyshev at openjdk.org Sun Mar 2 21:19:58 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Sun, 2 Mar 2025 21:19:58 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v17] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 19:07:32 GMT, Severin Gehwolf wrote: > OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well. Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2692912180 From xgong at openjdk.org Mon Mar 3 02:26:03 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 3 Mar 2025 02:26:03 GMT Subject: RFR: 8350748: VectorAPI: Method "checkMaskFromIndexSize" should be force inlined In-Reply-To: References: <18Q2Zl2ip_eFS_Y4fflgS8XYBkbwCZ468DIjP3KwhDE=.240f4182-4b02-4fac-97c8-ac659427e4a8@github.com> Message-ID: <5MHf8-aP7o8WftHBIn6o-t2ZuMJfSLrhxnTvi2qGBq8=.7e9c5210-ed9f-4ab1-8d58-80e175ff019e@github.com> On Thu, 27 Feb 2025 23:30:29 GMT, Paul Sandoz wrote: >> Method `checkMaskFromIndexSize` is called by some vector masked APIs like `fromArray/intoArray/fromMemorySegment/...`. It is used to check whether the index of any active lanes in a mask will reach out of the boundary of the given Array/MemorySegment. This function should be force inlined, or a VectorMask object is generated once the function call is not inlined by C2 compiler, which affects the API performance a lot. >> >> This patch changed to call the `VectorMask.checkFromIndexSize` method directly inside of these APIs instead of `checkMaskFromIndexSize`. Since it has added the `@ForceInline` annotation already, it will be inlined and intrinsified by C2. And then the expected vector instructions can be generated. With this change, the unused `checkMaskFromIndexSize` can be removed. >> >> Performance of some JMH benchmarks can improve up to 14x on a NVIDIA Grace CPU (AArch64 SVE2, 128-bit vectors). We can also observe the similar performance improvement on a Intel CPU which supports AVX512. >> >> Following is the performance data on Grace: >> >> >> Benchmark Mode Cnt Units Before After Gain >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE thrpt 30 ops/ms 31544.304 31610.598 1.002 >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE thrpt 30 ops/ms 3896.202 3903.249 1.001 >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE thrpt 30 ops/ms 570.415 7174.320 12.57 >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE thrpt 30 ops/ms 566.694 7193.520 12.69 >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE thrpt 30 ops/ms 3899.269 3878.258 0.994 >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE thrpt 30 ops/ms 1134.301 16053.847 14.15 >> StoreMaskedIOOBEBenchmark.byteStoreArrayMaskIOOBE thrpt 30 ops/ms 26449.558 28699.480 1.085 >> StoreMaskedIOOBEBenchmark.doubleStoreArrayMaskIOOBE thrpt 30 ops/ms 1922.167 5781.077 3.007 >> StoreMaskedIOOBEBenchmark.floatStoreArrayMaskIOOBE thrpt 30 ops/ms 3784.190 11789.276 3.115 >> StoreMaskedIOOBEBenchmark.intStoreArrayMaskIOOBE thrpt 30 ops/ms 3694.082 15633.547 4.232 >> StoreMaskedIOOBEBenchmark.longStoreArrayMaskIOOBE thrpt 30 ops/ms 1966.956 6049.790 3.075 >> StoreMaskedIOOBEBenchmark.shortStoreArrayMaskIOOBE thrpt 30 ops/ms 7647.309 27412.387 3.584 > > Marked as reviewed by psandoz (Reviewer). Thanks a lot for your review @PaulSandoz ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23817#issuecomment-2693122599 From xgong at openjdk.org Mon Mar 3 02:26:04 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 3 Mar 2025 02:26:04 GMT Subject: Integrated: 8350748: VectorAPI: Method "checkMaskFromIndexSize" should be force inlined In-Reply-To: <18Q2Zl2ip_eFS_Y4fflgS8XYBkbwCZ468DIjP3KwhDE=.240f4182-4b02-4fac-97c8-ac659427e4a8@github.com> References: <18Q2Zl2ip_eFS_Y4fflgS8XYBkbwCZ468DIjP3KwhDE=.240f4182-4b02-4fac-97c8-ac659427e4a8@github.com> Message-ID: On Thu, 27 Feb 2025 06:43:19 GMT, Xiaohong Gong wrote: > Method `checkMaskFromIndexSize` is called by some vector masked APIs like `fromArray/intoArray/fromMemorySegment/...`. It is used to check whether the index of any active lanes in a mask will reach out of the boundary of the given Array/MemorySegment. This function should be force inlined, or a VectorMask object is generated once the function call is not inlined by C2 compiler, which affects the API performance a lot. > > This patch changed to call the `VectorMask.checkFromIndexSize` method directly inside of these APIs instead of `checkMaskFromIndexSize`. Since it has added the `@ForceInline` annotation already, it will be inlined and intrinsified by C2. And then the expected vector instructions can be generated. With this change, the unused `checkMaskFromIndexSize` can be removed. > > Performance of some JMH benchmarks can improve up to 14x on a NVIDIA Grace CPU (AArch64 SVE2, 128-bit vectors). We can also observe the similar performance improvement on a Intel CPU which supports AVX512. > > Following is the performance data on Grace: > > > Benchmark Mode Cnt Units Before After Gain > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE thrpt 30 ops/ms 31544.304 31610.598 1.002 > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE thrpt 30 ops/ms 3896.202 3903.249 1.001 > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE thrpt 30 ops/ms 570.415 7174.320 12.57 > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE thrpt 30 ops/ms 566.694 7193.520 12.69 > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE thrpt 30 ops/ms 3899.269 3878.258 0.994 > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE thrpt 30 ops/ms 1134.301 16053.847 14.15 > StoreMaskedIOOBEBenchmark.byteStoreArrayMaskIOOBE thrpt 30 ops/ms 26449.558 28699.480 1.085 > StoreMaskedIOOBEBenchmark.doubleStoreArrayMaskIOOBE thrpt 30 ops/ms 1922.167 5781.077 3.007 > StoreMaskedIOOBEBenchmark.floatStoreArrayMaskIOOBE thrpt 30 ops/ms 3784.190 11789.276 3.115 > StoreMaskedIOOBEBenchmark.intStoreArrayMaskIOOBE thrpt 30 ops/ms 3694.082 15633.547 4.232 > StoreMaskedIOOBEBenchmark.longStoreArrayMaskIOOBE thrpt 30 ops/ms 1966.956 6049.790 3.075 > StoreMaskedIOOBEBenchmark.shortStoreArrayMaskIOOBE thrpt 30 ops/ms 7647.309 27412.387 3.584 This pull request has now been integrated. Changeset: d48ddfe4 Author: Xiaohong Gong URL: https://git.openjdk.org/jdk/commit/d48ddfe49a4e0b07949912d3c91d6f4737658b3e Stats: 213 lines in 7 files changed: 36 ins; 140 del; 37 mod 8350748: VectorAPI: Method "checkMaskFromIndexSize" should be force inlined Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/23817 From dholmes at openjdk.org Mon Mar 3 04:07:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 3 Mar 2025 04:07:34 GMT Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR [v2] In-Reply-To: References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com> Message-ID: On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken wrote: >> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > copyright years Just FTR I don't think we have ever intended to make all the tests runnable with the minimal VM. It is not a primary configuration that we need to support out-of-the-box as such. Anyone wanting to build and test the Minimal VM can quickly put together a custom ProblemList to exclude those that have "missing" requires. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23805#issuecomment-2693227310 From sgehwolf at openjdk.org Mon Mar 3 07:52:59 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 3 Mar 2025 07:52:59 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v17] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev wrote: > > OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well. > > Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch. OK! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2693536580 From tschatzl at openjdk.org Mon Mar 3 08:42:05 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 3 Mar 2025 08:42:05 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix comment (trailing whitespace) * another assert when snapshotting at a safepoint. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/d87935a0..810bf2d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From vyazici at openjdk.org Mon Mar 3 09:16:59 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 3 Mar 2025 09:16:59 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v3] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: <-U06lGc9pYxiuYgEXa_rxC_c5sceU2ODsKljM-uqO_Q=.43154c26-6dd3-41d5-b47f-540400b54731@github.com> On Sat, 1 Mar 2025 07:50:44 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. >> >> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. >> >> I'll draft a CSR once we agree on the proposed text. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - change "@implSpec" to "@apiNote" and update their text > - add class level documentation > - merge latest from master branch > - add tests > - update DeflaterInputStream and InflaterInputStream > - 8066583: DeflaterOutputStream and InflaterOutputStream should explain responsibility for freeing resources src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 40: > 38: *

This class uses a {@link Deflater} for compressing the data. Two forms of constructors > 39: * are available for constructing a {@code DeflaterInputStream} - one which accepts > 40: * a {@code Deflater} and one which doesn't. The constructors that don't accept a {@code Deflater} > `The constructors that don't accept a {@code Deflater}` Regarding the internal `Deflater` that will be created and its life cycle will be managed by the `DIS`... This sounds like an _internal implementation detail_ and `DIS` takes care of this internal resource nicely. IMHO, providing this information brings no benefit to users and sort of hand-cuffs ourselves to this behavior. Shall we remove that part from the docs? (Note that this remark applies to all 4 classes whose JavaDoc is updated.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23655#discussion_r1977130720 From duke at openjdk.org Mon Mar 3 10:10:01 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 3 Mar 2025 10:10:01 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v10] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 03:16:02 GMT, Jason Mehrens wrote: >> I'd have to disagree with the points you make. >> >> The fact is that loggers are never expected to modify the passed parameters. To ask people to "disown" the parameters they pass to a logger requires that your best advice on how to write a log statement with mutable values must look something like: >> >> >> if (logger.isEnabled(level)) { >> // Avoid copying parameters when logging is disabled. >> var arg1Copy = arg1.defensiveCopy(); >> var arg2Copy = arg2.defensiveCopy(); >> logger.log(level, "foo={0}, bar={1}", arg1Copy, arg2Copy); >> } >> >> >> as opposed to: >> >> >> logger.log(level, "foo={0}, bar={1}", arg1, arg2); >> >> >> The former is, in my opinion, a pretty awful user experience, error prone, and (more to the point) something that almost nobody ever does in real code because, reasonably, they trust the internal logger classes not to be malicious. >> >> The comment about the record being owned by the logger means that it can't be cached and reused, or passed to different log statements etc. It doesn't give logging classes any freedom to modify the log statement parameters. >> >> The other issue with "defer processing to another thread", even if you do format in the original thread, is that either: >> >> 1. You format just the arguments to strings -- Now things like `{0,date}` are broken because you turned date/time arguments into strings what are no longer formattable with the original format string. >> 2. You format the entire message -- Now any handlers downstream cannot use the format message (the thing with the placeholders in) as a key to identify the log statements, which is sometimes really important for analysis. >> >> It's just really hard (maybe impossible) to create any general solution where a log record (as opposed to some custom semi-flattened form) can be safely used between threads without this being visible in some way to users. >> >> So my (personal) strong advice for Handler implementations is: >> 1. Never let the log record you are given escape the call to `publish()`. >> 2. You can store metadata from the log record "on the side", but only for non user-supplied arguments. >> >> So, if you wanted to use something like `MemoryHandler`, subclass it and override `publish()` to make new log records to pass into its queue, which contain only flat formatted information (and even then you might break assumptions of a downstream handler). >> >> However, if you are formatting everything in the `publish()` method, you don't reall... > >>The former is, in my opinion, a pretty awful user experience... > > Specifically, I'm referring to this, with awareness of the above described limitations: > > //String.format is var-arg > logger.log(Level.SEVERE, () -> { return String.format("foo=%s bar=%s", arg1, arg2); }); > > //logger is not var-arg > if (logger.isLoggable(lvl)) { //if arg1 and arg2 known to be never null > logger.log(lvl, "foo={0} bar={1}", new Object[]{arg1.toString(), arg2.toString()}); > } > > //logger is not var-arg > if (logger.isLoggable(lvl)) { //if arg1 and arg2 are nullable > logger.log(lvl, "foo={0} bar={1}", new Object[]{Objects.toString(arg1), Objects.toString(arg2)}); > } > > > How did you worked around this deadlock issue prior to this patch? That would be awesome information to add to the JIRA ticket for those that would like this patch but are unable to upgrade. The only workaround is to early format parameters, either at the call site or in the logger/handler. This bug has been around for a very long time, and I suspect that it hasn't been a serious issue for people because, in general, most toString() implementations are non-locking and most log statements are disabled most of the time. It's also a probabilistic deadlock which requires some instance to be being accessed by two threads concurrently. I have however witnessed it causing issues in real production systems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1977228065 From duke at openjdk.org Mon Mar 3 10:15:53 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 3 Mar 2025 10:15:53 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v11] In-Reply-To: References: Message-ID: > 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. > > 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. > 2. Add explanatory comments to various affected methods. > 3. Add a test to ensure deadlocks no longer occur. > > Note that this change does not address issue in MemoryHandler (see JDK-8349208). David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Final round of comment tweaks. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23491/files - new: https://git.openjdk.org/jdk/pull/23491/files/1bf2da42..43c76119 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=09-10 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491 PR: https://git.openjdk.org/jdk/pull/23491 From dfuchs at openjdk.org Mon Mar 3 10:47:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 3 Mar 2025 10:47:56 GMT Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v11] In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 10:15:53 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package. >> 2. Add explanatory comments to various affected methods. >> 3. Add a test to ensure deadlocks no longer occur. >> >> Note that this change does not address issue in MemoryHandler (see JDK-8349208). > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Final round of comment tweaks. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2653752358 From eirbjo at openjdk.org Mon Mar 3 12:10:44 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 3 Mar 2025 12:10:44 GMT Subject: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v3] In-Reply-To: References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com> Message-ID: On Sat, 1 Mar 2025 07:50:44 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`. >> >> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes. >> >> I'll draft a CSR once we agree on the proposed text. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - change "@implSpec" to "@apiNote" and update their text > - add class level documentation > - merge latest from master branch > - add tests > - update DeflaterInputStream and InflaterInputStream > - 8066583: DeflaterOutputStream and InflaterOutputStream should explain responsibility for freeing resources > Given the inputs from Alan, Eirik and Lance, I have now updated this PR [...] > Does this look better? I like the structure this is shaping into, with the affected constructors linking into a note. I like that the note explains that some forms of constructors require special attention to manage resources. As noted by @vy, I find the note perhaps a bit verbose, and I agree that focus should be given to what actually needs attention, which is the constructors which allow passing a `Deflater`. I'm worried that the lengthy "introduction" means we loose readers before they get the message. I also think it could maybe help understanding/importance if we explicitly mention that closing the deflater will release resources used by the deflater. Otherwise, the resource leak concequence of not closing the deflater is not made abundantly clear. I tried rewording this with input from @vy in mind, and came up with this. Take whatever inspiration you find useful: ``` *

Some of the constructors in this class allow passing a {@link Deflater} for * compressing data. When a {@code DeflaterOutputStream} is constructed by passing * it a {@code Deflater}, then closing the stream will not close the passed * {@code Deflater}. In such cases, it is the responsibility of the caller to * to release resources used by the {@code Deflater} by * {@linkplain Deflater#close() closing} it as and when appropriate, * after the {@code DeflaterOutputStream} has been closed. ``` > > perhaps with an example snippet demonstrating a safe use of the API class Yes, I agree there is too much variabilty in the potential uses of Deflater here, the important message is that the caller is responsible for releasing resources by closing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2694136936 From dl at openjdk.org Mon Mar 3 12:37:57 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 3 Mar 2025 12:37:57 GMT Subject: RFR: 8319447: Improve performance of delayed task handling [v6] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 15:49:26 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce volatile reads > > src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 255: > >> 253: U.park(false, parkTime); >> 254: } >> 255: q = pending; > > Does this "win" over a continue; here? A continue might be faster/nicer, but can't use it here because even if no pending, still must check pool shutdown status, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1977446643 From mullan at openjdk.org Mon Mar 3 13:38:04 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 3 Mar 2025 13:38:04 GMT Subject: RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails with --enable-preview Message-ID: Please review this fix to a test that fails when run with --enable-preview. This fix is to add all the necessary utility classes imported by the test to the JAR file, and not just the test classes. ------------- Commit messages: - Initial fix. Changes: https://git.openjdk.org/jdk/pull/23864/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23864&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350685 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23864.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23864/head:pull/23864 PR: https://git.openjdk.org/jdk/pull/23864 From mullan at openjdk.org Mon Mar 3 13:43:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 3 Mar 2025 13:43:52 GMT Subject: RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails with --enable-preview In-Reply-To: References: Message-ID: <5gAR7GJvxAazMCHtC2iafX_-tl7XlHNcBNY-yORuSRw=.6e8e44d0-2da4-4dfc-b703-9fe03c388936@github.com> On Mon, 3 Mar 2025 13:33:05 GMT, Sean Mullan wrote: > Please review this fix to a test that fails when run with --enable-preview. This fix is to add all the necessary utility classes imported by the test to the JAR file, and not just the test classes. test/jdk/java/lang/System/SecurityManagerWarnings.java line 75: > 73: } > 74: > 75: // When -Djava.security.manager is not set, or set to "allow", The comment was incorrect. Setting "allow" now causes the JVM to fail with an error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23864#discussion_r1977535785 From amitkumar at openjdk.org Mon Mar 3 14:25:54 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 3 Mar 2025 14:25:54 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5] In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 08:42:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix comment (trailing whitespace) > * another assert when snapshotting at a safepoint. I don't see any failure on s390x. Tier1 test looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2694563382 From ayang at openjdk.org Mon Mar 3 15:22:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 3 Mar 2025 15:22:10 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5] In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 08:42:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix comment (trailing whitespace) > * another assert when snapshotting at a safepoint. src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 106: > 104: > 105: __ testptr(count, count); > 106: __ jcc(Assembler::equal, done); I wonder if we can use "zero" instead of "equal" here; they have the same underlying value, but the semantic is to checking for "zero". src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 133: > 131: Label is_clean_card; > 132: __ cmpb(Address(addr, 0), G1CardTable::clean_card_val()); > 133: __ jcc(Assembler::equal, is_clean_card); Should this checking be guarded by `if (UseCondCardMark)`? I see that aarch64 does that. src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 143: > 141: > 142: __ bind(is_clean_card); > 143: // Card was not clean. Dirty card and go to next.. Why "not clean"? I thought this path is for dirtying clean card? src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 323: > 321: assert(thread == r15_thread, "must be"); > 322: #endif // _LP64 > 323: assert_different_registers(store_addr, new_val, thread, tmp1 /*, tmp2 unused */, noreg); Seems that `tmp2` is unused in this method. It is used in aarch64, but it's not obvious to me whether that is indeed necessary. If so, can you add a comment saying sth like "this unused var is needed for other archs..."? src/hotspot/share/gc/g1/g1CardTable.inline.hpp line 54: > 52: // result = 0xBBAABBAA > 53: inline size_t blend(size_t a, size_t b, size_t mask) { > 54: return a ^ ((a ^ b) & mask); The example makes it much clearer; I wonder if `return (a & ~mask) | (b & mask);` is more readable. src/hotspot/share/gc/g1/g1CardTableClaimTable.cpp line 59: > 57: > 58: void G1CardTableClaimTable::reset_all_claims_to_claimed() { > 59: for (size_t i = 0; i < _max_reserved_regions; i++) { `uint` for `i`? src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp line 64: > 62: void reset_all_claims_to_unclaimed(); > 63: void reset_all_claims_to_claimed(); > 64: I wonder if these two APIs can be renamed to "reset_all_to_x", which is more aligned with its single-region counterpart, `reset_to_unclaimed`, IMO. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 348: > 346: void G1ConcurrentRefineWorkState::snapshot_heap_into(G1CardTableClaimTable* sweep_table) { > 347: // G1CollectedHeap::heap_region_iterate() below will only visit committed regions. Initialize > 348: // all entries in the state table here to not require special handling when iterating over it. Can you elaborate on what the "special handling" would be, if we don's set "claimed" for non-committed regions? src/hotspot/share/gc/g1/g1RemSet.cpp line 837: > 835: for (; refinement_cur_card < refinement_end_card; ++refinement_cur_card, ++card_cur_word) { > 836: size_t value = *refinement_cur_card; > 837: *refinement_cur_card = G1CardTable::WordAllClean; Similarly, this is a "word", not "card", also. src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 857: > 855: // We do not expect too many non-Java threads compared to Java threads, so just > 856: // let one worker claim that work. > 857: if (!_non_java_threads_claim && !Atomic::cmpxchg(&_non_java_threads_claim, false, true, memory_order_relaxed)) { Do non-java threads have card-table-base? src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 862: > 860: > 861: class ResizeAndSwapCardTableClosure : public ThreadClosure { > 862: SwapCardTableClosure _cl; Field indentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977586579 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977594184 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977583002 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977601907 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977645576 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977571306 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977573354 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977704351 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977575441 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977701293 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977679688 From liach at openjdk.org Mon Mar 3 15:29:07 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 3 Mar 2025 15:29:07 GMT Subject: RFR: 8351045: ClassValue::remove cannot ensure computation observes up-to-date state Message-ID: After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a remove happened, and proceed to install an outdated value onto a CV. The fix is simple - to force computation to retry when a remove has happened, so the retry can observe the up-to-date states from the remove. (finishEntry and removeEntry are both synchronized on the object monitor of the ClassValueMap instance) ------------- Commit messages: - 8351045: ClassValue::remove cannot ensure computation observes up-to-date state Changes: https://git.openjdk.org/jdk/pull/23866/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23866&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351045 Stats: 81 lines in 2 files changed: 61 ins; 3 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/23866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23866/head:pull/23866 PR: https://git.openjdk.org/jdk/pull/23866 From tschatzl at openjdk.org Mon Mar 3 15:40:04 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 3 Mar 2025 15:40:04 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5] In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 14:11:09 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix comment (trailing whitespace) >> * another assert when snapshotting at a safepoint. > > src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 143: > >> 141: >> 142: __ bind(is_clean_card); >> 143: // Card was not clean. Dirty card and go to next.. > > Why "not clean"? I thought this path is for dirtying clean card? My interpretation is: in this path the card has been found clean ("is clean") earlier. So dirty it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977733993 From tschatzl at openjdk.org Mon Mar 3 15:42:57 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 3 Mar 2025 15:42:57 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5] In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 14:47:00 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix comment (trailing whitespace) >> * another assert when snapshotting at a safepoint. > > src/hotspot/share/gc/g1/g1CardTable.inline.hpp line 54: > >> 52: // result = 0xBBAABBAA >> 53: inline size_t blend(size_t a, size_t b, size_t mask) { >> 54: return a ^ ((a ^ b) & mask); > > The example makes it much clearer; I wonder if `return (a & ~mask) | (b & mask);` is more readable. ... and hope that the optimizer knows this pattern? If you insist I can do that, brief examination of that code snippet by itself (not within this code) showed that it does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977739888 From hannesw at openjdk.org Mon Mar 3 16:48:38 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 3 Mar 2025 16:48:38 GMT Subject: RFR: 8346118: Improve whitespace normalization in preformatted text Message-ID: Please review an enhancement to make `DocCommentParser` normalize whitespace inside `

` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.

This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 

The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 

If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 

Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.

[1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

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

Commit messages:
 - Make sure whitespace normalization is only applied to block content
 - Only normalize inside 
 tags, add tests
 - 8346118: Improve whitespace normalization in preformatted text

Changes: https://git.openjdk.org/jdk/pull/23868/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346118
  Stats: 334 lines in 11 files changed: 258 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/23868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23868/head:pull/23868

PR: https://git.openjdk.org/jdk/pull/23868

From tschatzl at openjdk.org  Mon Mar  3 16:55:55 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Mar 2025 16:55:55 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 3 Mar 2025 15:17:27 GMT, Albert Mingkun Yang  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * fix comment (trailing whitespace)
>>   * another assert when snapshotting at a safepoint.
>
> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 857:
> 
>> 855:     // We do not expect too many non-Java threads compared to Java threads, so just
>> 856:     // let one worker claim that work.
>> 857:     if (!_non_java_threads_claim && !Atomic::cmpxchg(&_non_java_threads_claim, false, true, memory_order_relaxed)) {
> 
> Do non-java threads have card-table-base?

This code should not be necessary (any more). Will remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977853483

From smarks at openjdk.org  Mon Mar  3 17:15:56 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 3 Mar 2025 17:15:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 3 Mar 2025 10:15:53 GMT, David Beaumont  wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final round of comment tweaks.

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2654752537

From naoto at openjdk.org  Mon Mar  3 18:05:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Mar 2025 18:05:55 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 1 Mar 2025 01:19:17 GMT, Joe Wang  wrote:

>> Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc).
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove commented section

test/jaxp/javax/xml/jaxp/unittest/validation/ValidationTest.java line 151:

> 149:      *
> 150:      * @throws Exception if the test fails, in which case the parser throws
> 151:      * IndexOutOfBoundsException.

Do we need this `throws Exception` clause (and the method declaration below)? Since AIOOBE is a `RuntimeException`, this `throws` clause does not seem to be necessary. Simple description of the failure case may suffice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23847#discussion_r1977948293

From tschatzl at openjdk.org  Mon Mar  3 18:22:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Mar 2025 18:22:24 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v6]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  ayang review 2
  * removal of useless code
  * renamings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/810bf2d3..b3dd0084

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=04-05

  Stats: 51 lines in 7 files changed: 16 ins; 10 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From joehw at openjdk.org  Mon Mar  3 19:24:38 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 3 Mar 2025 19:24:38 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA [v3]
In-Reply-To: 
References: 
Message-ID: 

> Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc).

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  improve the javadoc for the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23847/files
  - new: https://git.openjdk.org/jdk/pull/23847/files/2d4b7653..c8f07127

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23847&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23847&range=01-02

  Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23847/head:pull/23847

PR: https://git.openjdk.org/jdk/pull/23847

From joehw at openjdk.org  Mon Mar  3 19:24:38 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 3 Mar 2025 19:24:38 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 3 Mar 2025 18:01:48 GMT, Naoto Sato  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove commented section
>
> test/jaxp/javax/xml/jaxp/unittest/validation/ValidationTest.java line 151:
> 
>> 149:      *
>> 150:      * @throws Exception if the test fails, in which case the parser throws
>> 151:      * IndexOutOfBoundsException.
> 
> Do we need this `throws Exception` clause (and the method declaration below)? Since AIOOBE is a `RuntimeException`, this `throws` clause does not seem to be necessary. Simple description of the failure case may suffice.

Thanks Naoto. Improved the javadoc a bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23847#discussion_r1978060161

From alexey.semenyuk at oracle.com  Mon Mar  3 19:37:25 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 3 Mar 2025 14:37:25 -0500
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
Message-ID: <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>

Hi Michael,

Thank you for the detailed report! I filed [1] ticket that, I hope, 
captures all findings from your report. Let me know if anything was 
missed or misunderstood.

[1] https://bugs.openjdk.org/browse/JDK-8351073

- Alexey

On 2/28/2025 10:39 PM, Michael Hall wrote:
>
>
>> On Feb 27, 2025, at 11:43?AM, Alexey Semenyuk 
>>  wrote:
>>
>> Thank you for trying it out! I'll look closer at the issues you 
>> reported and get back to you.
>
> I put something up on my trying it out if helpful when you get a 
> chance to look at it.
>
> MacOS system JRE in JavaVirtualMachines with jpackage
> http://mikehall.pairserver.com/sysjdk.html 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mik3hall at gmail.com  Mon Mar  3 19:51:21 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 3 Mar 2025 13:51:21 -0600
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
 <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
Message-ID: <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>



> On Mar 3, 2025, at 1:37?PM, Alexey Semenyuk  wrote:
> 
> Hi Michael,
> 
> Thank you for the detailed report! I filed [1] ticket that, I hope, captures all findings from your report. Let me know if anything was missed or misunderstood.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8351073
> 
> - Alexey
> 

Hello Alexey,

>  jpackage should copy them as-is.

It would be nice if this was the case but I think you need to be sure changes are made to the Info.plist to ensure the correct version is indicated in a few places. 

Apple offers something like plist buddy that could maybe be used.

Apache looked to have some commons confguration package that included plist. 

I used to have code that did some things with plists. I thought about coming up with something to handle general editing but haven?t.

There were issues I still ran into related to the jre that I put together for this. I?m not sure whether they were due to it being an early, not quite ready, jdk 25 build. Or I still also missed something in making it a working jre. 

You might want to have some test(s) of the installed to be sure it is a valid working one.

Just java ?version maybe for one. And/or doing something with /usr/libexec/java_home.

Whatever else might seem appropriate. I couldn?t jlnk an application with mine for some reason was one issue, that led to others. 

Otherwise yes, if you are going to offer a system jre installer it needs some additional Mac specific changes, I?m sure you?ll determine what they might be. 

Thanks for following up.

Mike 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From iwalulya at openjdk.org  Mon Mar  3 20:18:58 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 3 Mar 2025 20:18:58 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 3 Mar 2025 08:42:05 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * fix comment (trailing whitespace)
>   * another assert when snapshotting at a safepoint.

src/hotspot/share/gc/g1/g1CardTable.cpp line 44:

> 42:       if (!failures) {
> 43:         G1CollectedHeap* g1h = G1CollectedHeap::heap();
> 44:         G1HeapRegion* r = g1h->heap_region_containing(mr.start());

Probably we can move this outside the loop, and assert that `mr` does not cross region boundaries

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 916:

> 914:   void safepoint_synchronize_end() override;
> 915: 
> 916:   jlong synchronized_duration() const { return _safepoint_duration; }

safepoint_duration() seems easier to comprehend.

src/hotspot/share/gc/g1/g1CollectionSet.cpp line 310:

> 308:   verify_young_cset_indices();
> 309: 
> 310:   size_t card_rs_length = _policy->analytics()->predict_card_rs_length(in_young_only_phase);

Why are we using a prediction here? Additionally, won't this prediction also include cards from the old gen regions in case of mixed gcs? How do we reconcile that when we are adding old gen regions to c-set?

src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 42:

> 40: class G1HeapRegion;
> 41: class G1Policy;
> 42: class G1CardTableClaimTable;

Nit: ordering of the declarations

src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 84:

> 82: // Tracks the current refinement state from idle to completion (and reset back
> 83: // to idle).
> 84: class G1ConcurrentRefineWorkState {

G1ConcurrentRefinementState? I am not convinced the "Work" adds any clarity

src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 113:

> 111:   // Current epoch the work has been started; used to determine if there has been
> 112:   // a forced card table swap due to a garbage collection while doing work.
> 113:   size_t _refine_work_epoch;

same as previous comment, why `refine_work` instead of `refinement`?

src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 43:

> 41:   size_t _cards_clean;                // Number of cards found clean.
> 42:   size_t _cards_not_parsable;         // Number of cards we could not parse and left unrefined.
> 43:   size_t _cards_still_refer_to_cset;  // Number of cards marked still young.

`_cards_still_refer_to_cset` from the naming it is not clear what the difference is with `_cards_refer_to_cset`, the comment is not helping with that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977688778
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977969470
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977982999
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1977991124
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1978017843
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1978019093
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1978119476

From vaivanov at openjdk.org  Mon Mar  3 20:30:31 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 3 Mar 2025 20:30:31 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451
Message-ID: 

test setup was updated to generate data of requested size.

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

Commit messages:
 - JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

Changes: https://git.openjdk.org/jdk/pull/23873/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23873&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350811
  Stats: 15 lines in 3 files changed: 10 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23873/head:pull/23873

PR: https://git.openjdk.org/jdk/pull/23873

From sviswanathan at openjdk.org  Mon Mar  3 20:58:53 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 3 Mar 2025 20:58:53 GMT
Subject: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with
 IndexOutOfBoundsException for size=1024
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov  wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23783#pullrequestreview-2655268727

From vaivanov at openjdk.org  Mon Mar  3 21:04:01 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 3 Mar 2025 21:04:01 GMT
Subject: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with
 IndexOutOfBoundsException for size=1024
In-Reply-To: 
References: 
Message-ID: <8USEixyhdLYngzAxbmJ-nf5HN0YxPRuNIOSQt405hMQ=.bda0c0cd-ead1-470e-9384-359f88230523@github.com>

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov  wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2695524548

From duke at openjdk.org  Mon Mar  3 21:04:01 2025
From: duke at openjdk.org (duke)
Date: Mon, 3 Mar 2025 21:04:01 GMT
Subject: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with
 IndexOutOfBoundsException for size=1024
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov  wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

@IvaVladimir 
Your change (at version 6f3450752f812bbc5fea4fdd9ecf2e9110c94229) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2695525529

From vaivanov at openjdk.org  Mon Mar  3 21:08:03 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 3 Mar 2025 21:08:03 GMT
Subject: Integrated: 8350682: [JMH] vector.IndexInRangeBenchmark failed with
 IndexOutOfBoundsException for size=1024
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov  wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

This pull request has now been integrated.

Changeset: 768b0241
Author:    Vladimir Ivanov 
Committer: Derek White 
URL:       https://git.openjdk.org/jdk/commit/768b02410f1b53ac95d6014f152be84c89eb33ab
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024

Reviewed-by: xgong, drwhite, sviswanathan

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

PR: https://git.openjdk.org/jdk/pull/23783

From lancea at openjdk.org  Mon Mar  3 22:30:08 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 3 Mar 2025 22:30:08 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v3]
In-Reply-To: 
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
 
 
Message-ID: <8_dU287zXyT0cCIVN9KNycZBUq90x8IguGpH4OuHn6E=.131d2442-937c-432e-b213-f4e1f08df88b@github.com>

On Mon, 3 Mar 2025 11:59:36 GMT, Eirik Bj?rsn?s  wrote:

> > Given the inputs from Alan, Eirik and Lance, I have now updated this PR [...]
> 
> > Does this look better?
> 
> I like the structure this is shaping into, with the affected constructors linking into a note. I like that the note explains that some forms of constructors require special attention to manage resources.
> 
> As noted by @vy, I find the note perhaps a bit verbose, and I agree that focus should be given to what actually needs attention, which is the constructors which allow passing a `Deflater`. I'm worried that the lengthy "introduction" means we loose readers before they get the message.
> 
> I also think it could maybe help understanding/importance if we explicitly mention that closing the deflater will release resources used by the deflater. Otherwise, the resource leak concequence of not closing the deflater is not made abundantly clear.
> 
> I tried rewording this with input from @vy in mind, and came up with this. Take whatever inspiration you find useful:
> 
> ```
>  * 
Some of the constructors in this class allow passing a {@link Deflater} for
>  * compressing data. When a {@code DeflaterOutputStream} is constructed by passing
>  * it a {@code Deflater}, then closing the stream will not close the passed
>  * {@code Deflater}. In such cases, it is the responsibility of the caller to
>  * to release resources used by the {@code Deflater} by
>  * {@linkplain Deflater#close() closing} it as and when appropriate,
>  * after the {@code DeflaterOutputStream} has been closed.
> ```
> 
>  > > perhaps with an example snippet demonstrating a safe use of the API class
> 
> Yes, I agree there is too much variabilty in the potential uses of Deflater here, the important message is that the caller is responsible for releasing resources by closing.

I think we can simplify this  further to something like:

`When a compressor({@link Deflater}) is specified when creating  a {@link DeflaterOutputStream} instance, it is the responsibility of the  caller to  release  {@code Deflaters'} resources by calling  {@linkplain Deflater#close()} `

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

PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2695709906

From naoto at openjdk.org  Mon Mar  3 22:58:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Mar 2025 22:58:02 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 3 Mar 2025 19:24:38 GMT, Joe Wang  wrote:

>> Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc).
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve the javadoc for the test

Looks good. Thanks for the update

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23847#pullrequestreview-2655532637

From jlu at openjdk.org  Tue Mar  4 01:42:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 01:42:15 GMT
Subject: RFR: 8351074: Disallow null prefix and suffix in DecimalFormat
Message-ID: 

Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.

Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/23880/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23880&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351074
  Stats: 60 lines in 2 files changed: 59 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23880/head:pull/23880

PR: https://git.openjdk.org/jdk/pull/23880

From jlu at openjdk.org  Tue Mar  4 01:47:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 01:47:40 GMT
Subject: RFR: 8351074: Disallow null prefix and suffix in DecimalFormat
 [v2]
In-Reply-To: 
References: 
Message-ID: <9YlrvHo8RszYEXGvitEoOr1l6cLODkGXiCV57cD2EJw=.526e1e82-be7b-4b5d-8899-6aa9cb8b66d6@github.com>

> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
> 
> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  correct bug ID for test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23880/files
  - new: https://git.openjdk.org/jdk/pull/23880/files/56af293b..e13ac0d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23880&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23880&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23880/head:pull/23880

PR: https://git.openjdk.org/jdk/pull/23880

From mik3hall at gmail.com  Tue Mar  4 02:58:08 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 3 Mar 2025 20:58:08 -0600
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
 <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
 <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>
Message-ID: <988B383E-B300-44B8-B1F2-4133719C79A9@gmail.com>



> On Mar 3, 2025, at 1:51?PM, Michael Hall  wrote:
> 
> 
> 
>> On Mar 3, 2025, at 1:37?PM, Alexey Semenyuk  wrote:
>> 
>> Hi Michael,
>> 
>> Thank you for the detailed report! I filed [1] ticket that, I hope, captures all findings from your report. Let me know if anything was missed or misunderstood.
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8351073
>> 
>> - Alexey
>> 
> 
> Hello Alexey,
> 
>>  jpackage should copy them as-is.
> 
> It would be nice if this was the case but I think you need to be sure changes are made to the Info.plist to ensure the correct version is indicated in a few places. 
> 
> Apple offers something like plist buddy that could maybe be used.
> 

Fwiw,

(base) mjh at MacBook-Pro-2 ~ % grep -C 1 CFBundleGetInfoString Info.plist
	libjli.dylib
	CFBundleGetInfoString
	Java SE 23.0.1+11-39
(base) mjh at MacBook-Pro-2 ~ % /usr/libexec/PlistBuddy -c 'set:CFBundleGetInfoString Java SE 25' Info.plist
(base) mjh at MacBook-Pro-2 ~ % /usr/libexec/PlistBuddy -c 'save' Info.plist    
Saving...
(base) mjh at MacBook-Pro-2 ~ % grep -C 1 CFBundleGetInfoString Info.plist                                  
	libjli.dylib
	CFBundleGetInfoString
	Java SE 25


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darcy at openjdk.org  Tue Mar  4 03:06:57 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Mar 2025 03:06:57 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v12]
In-Reply-To: 
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 
Message-ID: 

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs  wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

The changes in java.base look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2655808338

From joehw at openjdk.org  Tue Mar  4 03:51:57 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 4 Mar 2025 03:51:57 GMT
Subject: Integrated: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Feb 2025 17:42:24 GMT, Joe Wang  wrote:

> Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc).

This pull request has now been integrated.

Changeset: 96613cc5
Author:    Joe Wang 
URL:       https://git.openjdk.org/jdk/commit/96613cc53842bc744e220e5bf7d91e92d0769a8e
Stats:     73 lines in 2 files changed: 54 ins; 16 del; 3 mod

8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/23847

From huizhe.wang at oracle.com  Tue Mar  4 04:54:20 2025
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 3 Mar 2025 20:54:20 -0800
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <002b3ebb-cbb5-44d8-ad67-3f6ae5af2024@oracle.com>


On 3/1/25 10:19 PM, Mukul Gandhi wrote:
> Hi Joe,
> ? ? Thanks for nice thoughts.
>
> On Fri, 28 Feb, 2025, 00:06 Joe Wang,  wrote:
>
>     What's your assessment on the readiness for a formal release (or how
>     much additional work is needed)? What are the conformance test
>     results?
>
>
> The link here, 
> https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn 
>  
> has a pdf link at bottom of that page which is Xalan-J XSL 3 
> implementation's latest development status. This link also has 
> documentation about how to run Xalan-J's XSL 3 conformance test suite, 
> which currently has 900+ odd tests supported by Xalan-J covering wide 
> areas of XSLT 3.0 and XPath 3.1 language features.


Great work. Are the tests counted differently? The W3C test suite for 
XSLT 3.0 is said to "contain over 11,000 test cases". What would be the 
pass rate if measured against the W3C test suite?


-Joe

>
>
>     Also, do you have data showing how the Xalan-J's XSL 3
>     implementation is
>     used in user applications? What are the feedback (or bug reports)
>     from
>     developers?
>
>
> I know of few people, particularly 
> https://x.com/XSLT_knowmad?t=ZKJE2bkeVyceZTxTmy1sPg&s=09 
>  
> and probably others who've been using Xalan-J's XSL 3 implementation. 
> Gary Gregory (Apache Xalan's PMC chair) has also rigorously tested 
> Xalan-J's XSL 3 implementation and reported it to be ok and useful.
>
> Many thanks.
>
> Regards,
> Mukul
>
>
>     On 2/26/25 7:59 AM, Mukul Gandhi wrote:
>     > Hi Alan,
>     >? ? ? I've just seen this mail from you. Apologies for a delayed
>     response.
>     >
>     > My mail box has had few issues due to the volume of mails that I get
>     > from mailing lists.
>     >
>     > On Sun, Feb 2, 2025 at 9:38?PM Alan Bateman
>      wrote:
>     >
>     >> The stats for that branch suggest 5,845 changed files with
>     234,372 additions and 84,058 deletions. I can't easily tell how
>     much of this would need to come into the jdk repo but this looks
>     like a major update. If only 10% of this is applicable to the JDK
>     then it still needs seems like a major update that would require a
>     huge investment to audit and integrate this code. How much XML is
>     in new applications developed in 2025? Only asking because it's an
>     area that is surely much lower priority compared to all the other
>     major investments right now. Maybe there are useful security or
>     performance changes that would be useful to cherry pick instead?
>     Finally, does this Xalan update work with the SPIs so that someone
>     really looking for XSL 3 can just deploy it on the class path and
>     module path?
>     > Ofcourse, anyone could use Xalan-J's XSL 3 implementation with
>     JDK by
>     > placing Xalan jars on class path & module path.
>     >
>     > Since Xalan-J's XSLT 1.0 & XPath 1.0 implementations are already
>     > available within JDK, I thought its natural if JDK could pick
>     > Xalan-J's XSL 3 implementation and include that within JDK. I can
>     > imagine that this may surely be time consuming for someone from JDK
>     > team to integrate with JDK. XSLT 1.0's use I think is very less
>     these
>     > days particularly for new XML projects, due to vast improvements in
>     > language features offered by XSLT 3.0 and XPath 3.1.
>     >
>     > IMHO, I wrote all the XSL 3 implementation code (and solved various
>     > XSL 3 implementation bugs reported by community on Xalan-J's dev
>     > forum) within Xalan-J's XSL 3 dev respos branch, enhancing upon
>     > Xalan-J's XSLT 1.0 implementation. From my point of view, I'll be
>     > happy if JDK could include Xalan-J's XSL 3 implementation.
>     >
>     > I even wrote following two online articles on xml.com
>     
>     about few of XSL
>     > 3 language features, and how they're implemented within Xalan-J,
>     >
>     https://www.xml.com/articles/2024/07/22/string-analysis-with-analyze-string/
>     
>     >
>     https://www.xml.com/articles/2023/12/05/xml-path-language-xpath-higher-order-functions/
>     
>     >
>     >
>     > Many thanks.
>     >
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jpai at openjdk.org  Tue Mar  4 07:48:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Mar 2025 07:48:59 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v4]
In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
Message-ID: 

> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
> 
> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
> 
> I'll draft a CSR once we agree on the proposed text.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - additional updates to the doc
 - merge latest from master branch
 - change "@implSpec" to "@apiNote" and update their text
 - add class level documentation
 - merge latest from master branch
 - add tests
 - update DeflaterInputStream and InflaterInputStream
 - 8066583: DeflaterOutputStream and InflaterOutputStream should explain responsibility for freeing resources

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23655/files
  - new: https://git.openjdk.org/jdk/pull/23655/files/80af3b35..80323172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=02-03

  Stats: 16059 lines in 563 files changed: 4524 ins; 8759 del; 2776 mod
  Patch: https://git.openjdk.org/jdk/pull/23655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655

PR: https://git.openjdk.org/jdk/pull/23655

From jpai at openjdk.org  Tue Mar  4 07:49:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Mar 2025 07:49:01 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v3]
In-Reply-To: 
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
 
Message-ID: 

On Sat, 1 Mar 2025 07:50:44 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
>> 
>> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
>> 
>> I'll draft a CSR once we agree on the proposed text.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - change "@implSpec" to "@apiNote" and update their text
>  - add class level documentation
>  - merge latest from master branch
>  - add tests
>  - update DeflaterInputStream and InflaterInputStream
>  - 8066583: DeflaterOutputStream and InflaterOutputStream should explain responsibility for freeing resources

I've now updated the PR to use Lance's text with slight modifications.

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

PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2696513038

From mbaesken at openjdk.org  Tue Mar  4 08:15:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Mar 2025 08:15:01 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev  wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright headers

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2656386374

From tschatzl at openjdk.org  Tue Mar  4 08:24:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 08:24:54 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 3 Mar 2025 20:02:16 GMT, Ivan Walulya  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * fix comment (trailing whitespace)
>>   * another assert when snapshotting at a safepoint.
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 43:
> 
>> 41:   size_t _cards_clean;                // Number of cards found clean.
>> 42:   size_t _cards_not_parsable;         // Number of cards we could not parse and left unrefined.
>> 43:   size_t _cards_still_refer_to_cset;  // Number of cards marked still young.
> 
> `_cards_still_refer_to_cset` from the naming it is not clear what the difference is with `_cards_refer_to_cset`, the comment is not helping with that

`cards_still_refer_to_cset` refers to cards that were found to have already been marked as `to-collection-set`. Renamed to `_cards_already_refer_to_cset`, would that be okay?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1978868225

From tschatzl at openjdk.org  Tue Mar  4 08:28:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 08:28:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 3 Mar 2025 18:28:48 GMT, Ivan Walulya  wrote:

> Why are we using a prediction here?

Quickly checking again, do we have the actual count here from somewhere?

> Additionally, won't this prediction also include cards from the old gen regions in case of mixed gcs? How do we reconcile that when we are adding old gen regions to c-set?

The predictor contents changed to (supposedly) only contain cards containing young gen references. See g1Policy.cpp:934:

    _analytics->report_card_rs_length(total_cards_scanned - total_non_young_rs_cards, is_young_only_pause);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1978876199

From tschatzl at openjdk.org  Tue Mar  4 08:36:55 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 08:36:55 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 3 Mar 2025 15:19:20 GMT, Albert Mingkun Yang  wrote:

> Can you elaborate on what the "special handling" would be, if we don's set "claimed" for non-committed regions?

the iteration code, would for every region check whether the region is actually committed or not.

The `heap_region_iterate()` API of `G1CollectedHeap` only iterates over committed regions. So only committed regions will be updated in the state table. Later when iterating over the state table, the code uses the array directly, i.e. the claim state of uncommitted regions would be read as uninitialized.

Further, it would be hard to exclude regions committed after the snapshot otherwise (we do not need to iterate over them. Their card table can't contain card marks) as we do not track newly committed regions in the snapshot. We could do, but would be a headache due to memory synchronization because regions can be committed any time.

Imho it is much simpler to reset all the card claims to "already processed" and then make the regions we want to work on claimable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1978893134

From tschatzl at openjdk.org  Tue Mar  4 08:39:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 08:39:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 4 Mar 2025 08:22:03 GMT, Thomas Schatzl  wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 43:
>> 
>>> 41:   size_t _cards_clean;                // Number of cards found clean.
>>> 42:   size_t _cards_not_parsable;         // Number of cards we could not parse and left unrefined.
>>> 43:   size_t _cards_still_refer_to_cset;  // Number of cards marked still young.
>> 
>> `_cards_still_refer_to_cset` from the naming it is not clear what the difference is with `_cards_refer_to_cset`, the comment is not helping with that
>
> `cards_still_refer_to_cset` refers to cards that were found to have already been marked as `to-collection-set`. Renamed to `_cards_already_refer_to_cset`, would that be okay?

Fwiw, this is just for statistics, so if you want I can remove these. I did some experiments with re-examining these cards too to see whether we could clear them later. For determining if/when to do that a rate of increase for the young cards has been interesting.

As mentioned, if you want I can remove them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1978896272

From tschatzl at openjdk.org  Tue Mar  4 08:53:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 08:53:46 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v7]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * iwalulya initial comments
    * renaming
  * made blend() helper function more clear; at least gcc will optimize it to the same code as before

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/b3dd0084..8f46dc9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=05-06

  Stats: 27 lines in 9 files changed: 7 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Tue Mar  4 09:15:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 09:15:24 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v8]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * do not change card table base for gc threads during swapping
    * not necessary because they do not use it
    * (recent assert that verifies that non-java threads do not have a card table found this)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/8f46dc9a..9e2ee543

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=06-07

  Stats: 25 lines in 1 file changed: 9 ins; 14 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From iwalulya at openjdk.org  Tue Mar  4 09:38:58 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 4 Mar 2025 09:38:58 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 4 Mar 2025 08:36:58 GMT, Thomas Schatzl  wrote:

>> `cards_still_refer_to_cset` refers to cards that were found to have already been marked as `to-collection-set`. Renamed to `_cards_already_refer_to_cset`, would that be okay?
>
> Fwiw, this particular counter is just for statistics, so if you want I can remove these. I did some experiments with re-examining these cards too to see whether we could clear them later. For determining if/when to do that a rate of increase for the young cards has been interesting.
> 
> As mentioned, if you want I can remove them.

`_cards_already_refer_to_cset` is fine by me, i don't like the option of removing them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979009507

From iwalulya at openjdk.org  Tue Mar  4 09:43:54 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 4 Mar 2025 09:43:54 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 4 Mar 2025 08:26:10 GMT, Thomas Schatzl  wrote:

>> src/hotspot/share/gc/g1/g1CollectionSet.cpp line 310:
>> 
>>> 308:   verify_young_cset_indices();
>>> 309: 
>>> 310:   size_t card_rs_length = _policy->analytics()->predict_card_rs_length(in_young_only_phase);
>> 
>> Why are we using a prediction here? Additionally, won't this prediction also include cards from the old gen regions in case of mixed gcs? How do we reconcile that when we are adding old gen regions to c-set?
>
>> Why are we using a prediction here?
> 
> Quickly checking again, do we have the actual count here from somewhere?
> 
>> Additionally, won't this prediction also include cards from the old gen regions in case of mixed gcs? How do we reconcile that when we are adding old gen regions to c-set?
> 
> The predictor contents changed to (supposedly) only contain cards containing young gen references. See g1Policy.cpp:934:
> 
>     _analytics->report_card_rs_length(total_cards_scanned - total_non_young_rs_cards, is_young_only_pause);

Fair, I missed that details on young RS have been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979022900

From tschatzl at openjdk.org  Tue Mar  4 09:57:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 09:57:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v9]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * iwalulya review 2
    * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
    * some additional documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/9e2ee543..442d9eae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=07-08

  Stats: 93 lines in 7 files changed: 27 ins; 3 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Tue Mar  4 09:57:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 09:57:58 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: <3BAl6ELdTMEhWoovthkw7lq86mwuoUnyKxzCANFnwNc=.41077bf4-8073-4810-9d0d-078d7ad06240@github.com>

On Tue, 4 Mar 2025 09:52:40 GMT, Thomas Schatzl  wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 84:
>> 
>>> 82: // Tracks the current refinement state from idle to completion (and reset back
>>> 83: // to idle).
>>> 84: class G1ConcurrentRefineWorkState {
>> 
>> G1ConcurrentRefinementState? I am not convinced the "Work" adds any clarity
>
> We agreed on `G1ConcurrentRefineSweepState` for now, better suggestions welcome.
> 
> Use `Refine` instead of `Refinement` since all pre-existing classes also use `Refine`. This could be renamed in an extra change.

Add the `Sweep` in the name because this is not the state for entire refinement (which also includes information about when to start refinement/sweeping).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979053344

From tschatzl at openjdk.org  Tue Mar  4 09:57:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 09:57:58 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 3 Mar 2025 18:50:37 GMT, Ivan Walulya  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * fix comment (trailing whitespace)
>>   * another assert when snapshotting at a safepoint.
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 84:
> 
>> 82: // Tracks the current refinement state from idle to completion (and reset back
>> 83: // to idle).
>> 84: class G1ConcurrentRefineWorkState {
> 
> G1ConcurrentRefinementState? I am not convinced the "Work" adds any clarity

We agreed on `G1ConcurrentRefineSweepState` for now, better suggestions welcome.

Use `Refine` instead of `Refinement` since all pre-existing classes also use `Refine`. This could be renamed in an extra change.

> src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 113:
> 
>> 111:   // Current epoch the work has been started; used to determine if there has been
>> 112:   // a forced card table swap due to a garbage collection while doing work.
>> 113:   size_t _refine_work_epoch;
> 
> same as previous comment, why `refine_work` instead of `refinement`?

Already renamed, same as previous comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979050867
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979051649

From jpai at openjdk.org  Tue Mar  4 10:17:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Mar 2025 10:17:56 GMT
Subject: RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails
 with --enable-preview
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 13:33:05 GMT, Sean Mullan  wrote:

> Please review this fix to a test that fails when run with --enable-preview. This fix is to add all the necessary utility classes imported by the test to the JAR file, and not just the test classes.

The description in the JBS issue wasn't clear why this test would fail in this manner with `--enable-preview`. I looked at this a bit and I've added a comment to that JBS issue explaining what the issue is about.

I believe the proposed change here to package the necessary class files in the JAR file, so that they are available when launching `java` with that JAR file in the classpath, is correct.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23864#pullrequestreview-2656806335

From mdoerr at openjdk.org  Tue Mar  4 10:40:55 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 4 Mar 2025 10:40:55 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 09:57:56 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * iwalulya review 2
>     * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
>     * some additional documentation

I got an error while testing java/foreign/TestUpcallStress.java on linuxaarch64 with this PR:

#  Internal Error (/openjdk-jdk-linux_aarch64-dbg/jdk/src/hotspot/share/gc/g1/g1CardTable.cpp:56), pid=19044, tid=19159
#  guarantee(!failures) failed: there should not have been any failures
...
V  [libjvm.so+0xb6e988]  G1CardTable::verify_region(MemRegion, unsigned char, bool)+0x3b8  (g1CardTable.cpp:56)
V  [libjvm.so+0xc3a10c]  G1MergeHeapRootsTask::G1ClearBitmapClosure::do_heap_region(G1HeapRegion*)+0x13c  (g1RemSet.cpp:1048)
V  [libjvm.so+0xb7a80c]  G1CollectedHeap::par_iterate_regions_array(G1HeapRegionClosure*, G1HeapRegionClaimer*, unsigned int const*, unsigned long, unsigned int) const+0x9c  (g1CollectedHeap.cpp:2059)
V  [libjvm.so+0xc49fe8]  G1MergeHeapRootsTask::work(unsigned int)+0x708  (g1RemSet.cpp:1225)
V  [libjvm.so+0x19597bc]  WorkerThread::run()+0x98  (workerThread.cpp:69)
V  [libjvm.so+0x1824510]  Thread::call_run()+0xac  (thread.cpp:231)
V  [libjvm.so+0x13b3994]  thread_native_entry(Thread*)+0x130  (os_linux.cpp:877)
C  [libpthread.so.0+0x875c]  start_thread+0x18c

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2697024679

From tschatzl at openjdk.org  Tue Mar  4 10:48:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 10:48:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 4 Mar 2025 10:37:47 GMT, Martin Doerr  wrote:

> I got an error while testing java/foreign/TestUpcallStress.java on linuxaarch64 with this PR:
> 
> ```
> #  Internal Error (/openjdk-jdk-linux_aarch64-dbg/jdk/src/hotspot/share/gc/g1/g1CardTable.cpp:56), pid=19044, tid=19159
> #  guarantee(!failures) failed: there should not have been any failures
> ...
> V  [libjvm.so+0xb6e988]  G1CardTable::verify_region(MemRegion, unsigned char, bool)+0x3b8  (g1CardTable.cpp:56)
> V  [libjvm.so+0xc3a10c]  G1MergeHeapRootsTask::G1ClearBitmapClosure::do_heap_region(G1HeapRegion*)+0x13c  (g1RemSet.cpp:1048)
> V  [libjvm.so+0xb7a80c]  G1CollectedHeap::par_iterate_regions_array(G1HeapRegionClosure*, G1HeapRegionClaimer*, unsigned int const*, unsigned long, unsigned int) const+0x9c  (g1CollectedHeap.cpp:2059)
> V  [libjvm.so+0xc49fe8]  G1MergeHeapRootsTask::work(unsigned int)+0x708  (g1RemSet.cpp:1225)
> V  [libjvm.so+0x19597bc]  WorkerThread::run()+0x98  (workerThread.cpp:69)
> V  [libjvm.so+0x1824510]  Thread::call_run()+0xac  (thread.cpp:231)
> V  [libjvm.so+0x13b3994]  thread_native_entry(Thread*)+0x130  (os_linux.cpp:877)
> C  [libpthread.so.0+0x875c]  start_thread+0x18c
> ```

I will try to reproduce. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2697052899

From tschatzl at openjdk.org  Tue Mar  4 10:53:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 10:53:46 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v10]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * ayang review - fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/442d9eae..fc674f02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From duke at openjdk.org  Tue Mar  4 11:19:57 2025
From: duke at openjdk.org (Mikhail Yankelevich)
Date: Tue, 4 Mar 2025 11:19:57 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 20:24:54 GMT, Vladimir Ivanov  wrote:

> test setup was updated to generate data of requested size.

Looks good. Just 1 minor question

test/micro/org/openjdk/bench/java/lang/foreign/ToCStringTest.java line 100:

> 98:                  mollit anim id est laborum.
> 99:                 """;
> 100:         while (lorem.length() < size) lorem += lorem;

Minor: just out of interest, is there any particular reason you're using 
```java 
while (lorem.length() < size) lorem += lorem;
``` 
instead of
```java 
while (lorem.length() < size) {
	lorem += lorem;
}

?
It seems to me it might be harder to read, but it's fine as it is too

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

PR Review: https://git.openjdk.org/jdk/pull/23873#pullrequestreview-2657018870
PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1979206364

From iwalulya at openjdk.org  Tue Mar  4 11:19:59 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 4 Mar 2025 11:19:59 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 09:57:56 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * iwalulya review 2
>     * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
>     * some additional documentation

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 108:

> 106: 
> 107: void G1ConcurrentRefineThreadControl::control_thread_do(ThreadClosure* tc) {
> 108:   if (_control_thread != nullptr) {

maybe maintain using `if (max_num_threads() > 0)` as used in `G1ConcurrentRefineThreadControl::initialize`, so that it is clear that setting `G1ConcRefinementThreads=0` effectively turns off concurrent refinement.

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 354:

> 352:       if (!r->is_free()) {
> 353:         // Need to scan all parts of non-free regions, so reset the claim.
> 354:         // No need for synchronization: we are only interested about regions

s/about/in

src/hotspot/share/gc/g1/g1OopClosures.hpp line 205:

> 203:   G1CollectedHeap* _g1h;
> 204:   uint _worker_id;
> 205:   bool _has_to_cset_ref;

Similar to `_cards_refer_to_cset` , do you mind renaming `_has_to_cset_ref`  and `_has_to_old_ref`  to `_has_ref_to_cset` and `_has_ref_to_old`

src/hotspot/share/gc/g1/g1Policy.hpp line 105:

> 103:   uint _free_regions_at_end_of_collection;
> 104: 
> 105:   size_t _pending_cards_from_gc;

A comment on the variable would be nice, especially on how it is set/reset both at end of GC and by refinement. Also the `_to_collection_set_cards` below could use a comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979077904
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979102189
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979212854
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979155941

From duke at openjdk.org  Tue Mar  4 11:22:06 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Mar 2025 11:22:06 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev  wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright headers

@sercher 
Your change (at version bae78ff7c43e0446ef583db1c43b4a3d6c06ad4f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2697178573

From jlahoda at openjdk.org  Tue Mar  4 11:31:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 4 Mar 2025 11:31:46 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations
Message-ID: 

This is a patch to finalize the module imports feature. Please see:
https://bugs.openjdk.org/browse/JDK-8344700

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

Commit messages:
 - Cleanup.
 - Cleanup.
 - Finalizing module imports.

Changes: https://git.openjdk.org/jdk/pull/23801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344708
  Stats: 113 lines in 15 files changed: 9 ins; 71 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

PR: https://git.openjdk.org/jdk/pull/23801

From jpai at openjdk.org  Tue Mar  4 11:37:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Mar 2025 11:37:01 GMT
Subject: RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails
 with --enable-preview
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 10:15:18 GMT, Jaikiran Pai  wrote:

> I believe the proposed change here to package the necessary class files in the JAR file, so that they are available when launching java with that JAR file in the classpath, is correct.

I just realized one thing - this `OutputAnalyzer` is a test library class. So `test.classes` directory won't always contain this library class (jtreg sometimes compiles it into a separate directory and that behaviour is non-determinstic). So you might have to include additional paths when constructing that JAR file.

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

PR Comment: https://git.openjdk.org/jdk/pull/23864#issuecomment-2697219880

From tschatzl at openjdk.org  Tue Mar  4 11:39:55 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 11:39:55 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 4 Mar 2025 10:06:37 GMT, Ivan Walulya  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * iwalulya review 2
>>     * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
>>     * some additional documentation
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 108:
> 
>> 106: 
>> 107: void G1ConcurrentRefineThreadControl::control_thread_do(ThreadClosure* tc) {
>> 108:   if (_control_thread != nullptr) {
> 
> maybe maintain using `if (max_num_threads() > 0)` as used in `G1ConcurrentRefineThreadControl::initialize`, so that it is clear that setting `G1ConcRefinementThreads=0` effectively turns off concurrent refinement.

I added a new `is_refinement_enabled()` predicate instead  (that uses `max_num_threads()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979252156

From tschatzl at openjdk.org  Tue Mar  4 11:56:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 11:56:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  iwalulya review
    * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
    * predicate for determining whether the refinement has been disabled
    * some other typos/comment improvements
    * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/fc674f02..b4d19d9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=09-10

  Stats: 40 lines in 8 files changed: 14 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From davidalayachew at gmail.com  Tue Mar  4 13:03:55 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 4 Mar 2025 08:03:55 -0500
Subject: Question about IO.println
Message-ID: 

Hello Amber Dev Team and Core Libs Dev Team,

Another reddit discussion popped up today about IO.println(), and one of
the comments mentioned that they wanted something along the lines of this.

IO.println(num1, num2, num3); //prints out "1 2 3"

I proposed that maybe a better option would be a String.join overload. So,
instead of String.join(String delim, String... elements), there would be
String.join(String delim, Object... elements), with each object getting
toString() called on it.

What are your thoughts on either of these ideas? I actually think the
IO.println() version is nice, but I felt like String.join made a slightly
better compromise.

Another commentor mentioned that this will be easier with String Templates
too, so maybe it is better to wait for that. I don't think String templates
are a bad idea here, but it also felt like overkill imo. A library function
seems like a better fit.

Thank you for your time and thoughts.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From davidalayachew at gmail.com  Tue Mar  4 13:13:10 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 4 Mar 2025 08:13:10 -0500
Subject: Question about IO.println
In-Reply-To: 
References: 
Message-ID: 

Sorry, forgot to link the thread.

https://old.reddit.com/r/java/comments/1j2pr78/

And here is the comment in question.

https://old.reddit.com/r/java/comments/1j2pr78/compact_source_files_and_instance_main_methods_jep/mfy9dof/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jvernee at openjdk.org  Tue Mar  4 13:41:55 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 13:41:55 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
Message-ID: <5pL_A7PwMD_A1bc2cqBX2ePlV9jNfTqwUBQacA7fJ7Q=.b33e3485-1c0e-4ba9-a485-754e6c809552@github.com>

On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang  wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We no longer load DelegateMH as we no longer rebind

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1658:

> 1656:         var carrier = argument(0, L_TYPE).withConstraint(species); // BMH bound with data
> 1657:         Name[] constNames = new Name[] { carrier, new Name(species.getterFunction(0), carrier) };
> 1658:         return LF_constant[type.ordinal()] = create(1, constNames, Kind.CONSTANT);

I think this caching logic should be in `constantForm`, which also does the cache lookup.

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 972:

> 970:                 callFilter = null;
> 971:             else
> 972:                 callFilter = new Name(LambdaForm.identity(newType), newType.btWrapper.zero());

Maybe we could have a `Name` constructor that just takes an `Object` and returns it like this.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestDynamicRegenerateHolderClasses.java line 42:

> 40:     static String CHECK_MESSAGES[] = {"java.lang.invoke.Invokers$Holder source: shared objects file (top)",
> 41:                                       "java.lang.invoke.DirectMethodHandle$Holder source: shared objects file (top)",
> 42:                                       "java.lang.invoke.DelegatingMethodHandle$Holder source: shared objects file (top)",

I don't understand why this change is needed. Could you please explain it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979282388
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979441441
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979454377

From jvernee at openjdk.org  Tue Mar  4 13:41:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 13:41:56 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 <6w803Bt-p9pjcWwrgqxGZ8g9-1re_n8h21cL-VFagsw=.90fff225-ee93-4ee7-9059-b945b9e9a6ce@github.com>
 
Message-ID: 

On Mon, 24 Feb 2025 22:08:53 GMT, Chen Liang  wrote:

> we should just select a MH via hash table lookup and invoke that MH

I had something like this in an early prototype of the `tableSwitch` combinator, but it does not work, as it prevents the method handle calls for each case from being inlined.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979445701

From jvernee at openjdk.org  Tue Mar  4 14:14:54 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:14:54 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Feb 2025 02:45:46 GMT, Chen Liang  wrote:

> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.

You're gonna have to explain this. Looking at the code, I think the optimization here is that, the LambdaForm will just have a single call site for all the cases, whereas the intrinsic does emit a call per case? i.e. the point is that these do not necessarily have to do exactly the same thing?

I remember that having a call site per case was important from implementing this, since even if the selector is not a constant, we can then still inline each individual call site. Whereas with a single shared call site, the method handle would become not constant.

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

PR Comment: https://git.openjdk.org/jdk/pull/23763#issuecomment-2697769525

From liach at openjdk.org  Tue Mar  4 14:15:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Mar 2025 14:15:01 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 <6w803Bt-p9pjcWwrgqxGZ8g9-1re_n8h21cL-VFagsw=.90fff225-ee93-4ee7-9059-b945b9e9a6ce@github.com>
 
 
Message-ID: 

On Tue, 4 Mar 2025 13:35:50 GMT, Jorn Vernee  wrote:

>> I reviewed the other use of `intrinsicData`, `tableSwitch`. I believe the intrinsic is actually a regression by growing the bytecode size - we should just select a MH via hash table lookup and invoke that MH, given all MHs in that list have the same type. I have removed the use of intrinsic data here and we can move on to remove it later.
>> 
>> I noticed that intrinsics are useful really only as part of named functions. And named functions only reuse arbitrary MHs for the invoker form. Is my understanding here correct?
>
>> we should just select a MH via hash table lookup and invoke that MH
> 
> I had something like this in an early prototype of the `tableSwitch` combinator, but it does not work, as it prevents the method handle calls for each case from being inlined.

FYI this is being addressed in #23763

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979539450

From liach at openjdk.org  Tue Mar  4 14:15:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Mar 2025 14:15:00 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: <5pL_A7PwMD_A1bc2cqBX2ePlV9jNfTqwUBQacA7fJ7Q=.b33e3485-1c0e-4ba9-a485-754e6c809552@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
 <5pL_A7PwMD_A1bc2cqBX2ePlV9jNfTqwUBQacA7fJ7Q=.b33e3485-1c0e-4ba9-a485-754e6c809552@github.com>
Message-ID: 

On Tue, 4 Mar 2025 11:56:50 GMT, Jorn Vernee  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   We no longer load DelegateMH as we no longer rebind
>
> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1658:
> 
>> 1656:         var carrier = argument(0, L_TYPE).withConstraint(species); // BMH bound with data
>> 1657:         Name[] constNames = new Name[] { carrier, new Name(species.getterFunction(0), carrier) };
>> 1658:         return LF_constant[type.ordinal()] = create(1, constNames, Kind.CONSTANT);
> 
> I think this caching logic should be in `constantForm`, which also does the cache lookup.

Putting the field write in the `create` method is to help reduce the code that JIT needs to compile by reducing the getter's code size.

> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 972:
> 
>> 970:                 callFilter = null;
>> 971:             else
>> 972:                 callFilter = new Name(LambdaForm.identity(newType), newType.btWrapper.zero());
> 
> Maybe we could have a `Name` constructor that just takes an `Object` and returns it like this.

I don't think that is necessary - the majority of constant values like this are immediately sent to a NamedFunction, which already accepts such constants natively. The only case such a Name is necessary is for LF return values.

> test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestDynamicRegenerateHolderClasses.java line 42:
> 
>> 40:     static String CHECK_MESSAGES[] = {"java.lang.invoke.Invokers$Holder source: shared objects file (top)",
>> 41:                                       "java.lang.invoke.DirectMethodHandle$Holder source: shared objects file (top)",
>> 42:                                       "java.lang.invoke.DelegatingMethodHandle$Holder source: shared objects file (top)",
> 
> I don't understand why this change is needed. Could you please explain it?

With the simplification of `MethodHandles.constant`, it seems invoking `MethodHandles.constant` no longer need to initialize `DelegatingMethodHandle` because there is no longer need to rebind some MethodHandle; anyways we are loading fewer classes now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979534142
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979537500
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979543546

From liach at openjdk.org  Tue Mar  4 14:21:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Mar 2025 14:21:05 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 14:12:05 GMT, Jorn Vernee  wrote:

> the LambdaForm will just have a single call site for all the cases, whereas the intrinsic does emit a call per case?

Yes. The LambdaForm will be only used for non-customized bytecode (which cannot fully inline anyways) or interpretation.

> i.e. the point is that these do not necessarily have to do exactly the same thing?

I think so - that is what these MH Impl intrinsics are for, to stub out some names with replacement bytecode. Though in the long run, we might check if it's possible and worthy to add library call (intrinsic) for our combinator and improve the IR for C2 directly.

For performance, as I've mentioned before, JMH benchmarks results are the same for before and after; the only difference is that I had to add `@ForceInline` on Immutable collections to make them as performant as the old switch holder class because of the inlining shenigans when something is not constant.

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

PR Comment: https://git.openjdk.org/jdk/pull/23763#issuecomment-2697796793

From jvernee at openjdk.org  Tue Mar  4 14:32:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:32:56 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Feb 2025 02:45:46 GMT, Chen Liang  wrote:

> Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.
> 
> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.
> 
> Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 628:

> 626:                                         continue;
> 627:                                     }
> 628:                                     break; // Only inline target MHs if this is customized

I think this could be problematic, as we typically only customize the root method handle in a chain. So, if a table switch handle is used with another combinator, we will never benefit from the intrinsic.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7664:

> 7662:             if (mh.type() != expectedType)
> 7663:                 throw new IllegalArgumentException(
> 7664:                     "Some targets do not have the expected type " + expectedType + ": " + caseActions);

I think we should avoid changing the exception messages here, since it's observable from the outside.

FWIW, one of the downsides of only printing out a single method handle, is that a user can't tell which method handle in the list was problematic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979460526
PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979537776

From jvernee at openjdk.org  Tue Mar  4 14:32:54 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:32:54 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 4 Mar 2025 14:17:59 GMT, Chen Liang  wrote:

> The LambdaForm will be only used for non-customized bytecode (which cannot fully inline anyways)

True, without customization the cases holder in the current implementation will not be a constant, so we can never inline the cases for shared LFs. However, I think if the root MH in a chain is customized, we would still get inlining, whereas with the new implementation we don't, as we skipped generating the intrinsic...

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

PR Comment: https://git.openjdk.org/jdk/pull/23763#issuecomment-2697820353

From jvernee at openjdk.org  Tue Mar  4 14:32:57 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:32:57 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 14:10:36 GMT, Jorn Vernee  wrote:

>> Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.
>> 
>> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.
>> 
>> Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7664:
> 
>> 7662:             if (mh.type() != expectedType)
>> 7663:                 throw new IllegalArgumentException(
>> 7664:                     "Some targets do not have the expected type " + expectedType + ": " + caseActions);
> 
> I think we should avoid changing the exception messages here, since it's observable from the outside.
> 
> FWIW, one of the downsides of only printing out a single method handle, is that a user can't tell which method handle in the list was problematic.

At least, please motivate these changes. Why do you think changing the message is needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979539878

From liach at openjdk.org  Tue Mar  4 14:32:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Mar 2025 14:32:57 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 4 Mar 2025 14:11:28 GMT, Jorn Vernee  wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7664:
>> 
>>> 7662:             if (mh.type() != expectedType)
>>> 7663:                 throw new IllegalArgumentException(
>>> 7664:                     "Some targets do not have the expected type " + expectedType + ": " + caseActions);
>> 
>> I think we should avoid changing the exception messages here, since it's observable from the outside.
>> 
>> FWIW, one of the downsides of only printing out a single method handle, is that a user can't tell which method handle in the list was problematic.
>
> At least, please motivate these changes. Why do you think changing the message is needed?

Here you are making the check against the default case. However, these messages never print the default case's type, making this error message uninformative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979575675

From liach at openjdk.org  Tue Mar  4 14:32:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Mar 2025 14:32:56 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
 
Message-ID: <1oPz8eflj0whmor-EYrWpc-NqLva9_FV7JJAuNFFBIs=.dde3ac0e-ad2f-409a-a526-6db457b19ea0@github.com>

On Tue, 4 Mar 2025 13:42:16 GMT, Jorn Vernee  wrote:

>> Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.
>> 
>> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.
>> 
>> Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 628:
> 
>> 626:                                         continue;
>> 627:                                     }
>> 628:                                     break; // Only inline target MHs if this is customized
> 
> I think this could be problematic, as we typically only customize the root method handle in a chain. So, if a table switch handle is used with another combinator, we will never benefit from the intrinsic.

In that case, won't the root form be customized and the table switch names be inlined into the root form?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979571760

From liach at openjdk.org  Tue Mar  4 14:32:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Mar 2025 14:32:54 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 4 Mar 2025 14:25:45 GMT, Jorn Vernee  wrote:

> as we skipped generating the intrinsic

Huh, why? As I understand, intrinsics are bound on NamedFunction; the NamedFunction to select a MH should be still there in a MH chain.

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

PR Comment: https://git.openjdk.org/jdk/pull/23763#issuecomment-2697834960

From jvernee at openjdk.org  Tue Mar  4 14:35:54 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:35:54 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: <1oPz8eflj0whmor-EYrWpc-NqLva9_FV7JJAuNFFBIs=.dde3ac0e-ad2f-409a-a526-6db457b19ea0@github.com>
References: 
 
 <1oPz8eflj0whmor-EYrWpc-NqLva9_FV7JJAuNFFBIs=.dde3ac0e-ad2f-409a-a526-6db457b19ea0@github.com>
Message-ID: 

On Tue, 4 Mar 2025 14:26:19 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 628:
>> 
>>> 626:                                         continue;
>>> 627:                                     }
>>> 628:                                     break; // Only inline target MHs if this is customized
>> 
>> I think this could be problematic, as we typically only customize the root method handle in a chain. So, if a table switch handle is used with another combinator, we will never benefit from the intrinsic.
>
> In that case, won't the root form be customized and the table switch names be inlined into the root form?

The root would e.g. have a constant BMH pointing at a _shared_ tableSwitch LF. So, the BMH fields would be seen as constant as well, including the list of cases. The issue is that the bytecode of the tableSwitch BMH will not be using the intrinsic, since it's not customized itself, i.e. it will only have a single call site for all cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979585627

From jvernee at openjdk.org  Tue Mar  4 14:39:57 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:39:57 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: 
References: 
 
 <1oPz8eflj0whmor-EYrWpc-NqLva9_FV7JJAuNFFBIs=.dde3ac0e-ad2f-409a-a526-6db457b19ea0@github.com>
 
Message-ID: 

On Tue, 4 Mar 2025 14:33:27 GMT, Jorn Vernee  wrote:

>> In that case, won't the root form be customized and the table switch names be inlined into the root form?
>
> The root would e.g. have a constant BMH pointing at a _shared_ tableSwitch LF. So, the BMH fields would be seen as constant as well, including the list of cases. The issue is that the bytecode of the tableSwitch BMH will not be using the intrinsic, since it's not customized itself, i.e. it will only have a single call site for all cases.

I think we could get around this by always wrapping the `tableSwitch` MH in an `exactInvoker`, which adds the customization check for its callee. It would mean we will also separately customize any tableSwitch MH that's part of a larger chain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979591207

From jvernee at openjdk.org  Tue Mar  4 14:46:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:46:56 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
 <5pL_A7PwMD_A1bc2cqBX2ePlV9jNfTqwUBQacA7fJ7Q=.b33e3485-1c0e-4ba9-a485-754e6c809552@github.com>
 
Message-ID: 

On Tue, 4 Mar 2025 14:09:03 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1658:
>> 
>>> 1656:         var carrier = argument(0, L_TYPE).withConstraint(species); // BMH bound with data
>>> 1657:         Name[] constNames = new Name[] { carrier, new Name(species.getterFunction(0), carrier) };
>>> 1658:         return LF_constant[type.ordinal()] = create(1, constNames, Kind.CONSTANT);
>> 
>> I think this caching logic should be in `constantForm`, which also does the cache lookup.
>
> Putting the field write in the `create` method is to help reduce the code that JIT needs to compile by reducing the getter's code size.

Fair enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979606038

From jvernee at openjdk.org  Tue Mar  4 14:46:54 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Mar 2025 14:46:54 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
Message-ID: 

On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang  wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We no longer load DelegateMH as we no longer rebind

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23706#pullrequestreview-2657855612

From asemenyuk at openjdk.org  Tue Mar  4 15:33:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Mar 2025 15:33:18 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v12]
In-Reply-To: 
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 
Message-ID: 

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs  wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

jpackage looks good

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2658012030

From syan at openjdk.org  Tue Mar  4 15:36:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Mar 2025 15:36:03 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Feb 2025 12:35:50 GMT, SendaoYan  wrote:

> Hi all,
> 
> Several JMH tests fails "cannot access class jdk.internal.vm.ContinuationScope (in module java.base) because module java.base does not export jdk.internal.vm to unnamed module". This PR add VM option `--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to fix the JMH test bug.
> 
> Change has been verified locally, test-fix only, no risk.

Should we remove these JMH tests, or just fix the test bug and make tests run normally

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

PR Comment: https://git.openjdk.org/jdk/pull/23437#issuecomment-2698041624

From alexey.semenyuk at oracle.com  Tue Mar  4 15:45:36 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 4 Mar 2025 10:45:36 -0500
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: <988B383E-B300-44B8-B1F2-4133719C79A9@gmail.com>
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
 <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
 <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>
 <988B383E-B300-44B8-B1F2-4133719C79A9@gmail.com>
Message-ID: <3b2ed0a6-cb82-4629-9eab-ef6e2336dd50@oracle.com>



On 3/3/2025 9:58 PM, Michael Hall wrote:
>
>
>> On Mar 3, 2025, at 1:51?PM, Michael Hall  wrote:
>>
>>
>>
>>> On Mar 3, 2025, at 1:37?PM, Alexey Semenyuk 
>>>  wrote:
>>>
>>> Hi Michael,
>>>
>>> Thank you for the detailed report! I filed [1] ticket that, I hope, 
>>> captures all findings from your report. Let me know if anything was 
>>> missed or misunderstood.
>>>
>>> [1] https://bugs.openjdk.org/browse/JDK-8351073
>>>
>>> - Alexey
>>>
>>
>> Hello Alexey,
>>
>>> ?jpackage should copy them as-is.
>>
>> It would be nice if this was the case but I think you need to be sure 
>> changes are made to the Info.plist to ensure the correct version is 
>> indicated in a few places.
>>
>> Apple offers something like plist buddy that could maybe be used.
>>
>
> Fwiw,
>
> (base) mjh at MacBook-Pro-2 ~ % grep -C 1 CFBundleGetInfoString Info.plist
> libjli.dylib
> CFBundleGetInfoString
> Java SE 23.0.1+11-39
> (base) mjh at MacBook-Pro-2 ~ % /usr/libexec/PlistBuddy -c 
> 'set:CFBundleGetInfoString Java SE 25' Info.plist
> (base) mjh at MacBook-Pro-2 ~ % /usr/libexec/PlistBuddy -c 'save' Info.plist
> Saving...
> (base) mjh at MacBook-Pro-2 ~ % grep -C 1 CFBundleGetInfoString Info.plist
> libjli.dylib
> CFBundleGetInfoString
> Java SE 25
Good point about `CFBundleGetInfoString`. Maybe jpackage should set this 
field with the value of `--description` option. Another finding!

As for editing "Info.plist" from the runtime source, if the directory 
referenced from `--runtime-image` option is a valid bundle, i.e. has 
"Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and 
"Contents/_CodeSignature" elements, and there are no other options, like 
`--app-version`, jpackage should use the supplied directory as-is 
without editing the existing "Info.plist" file. Otherwise, jpackage 
should create "Info.plist" and make sure the values are consistent, of 
course.

- Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ayang at openjdk.org  Tue Mar  4 15:47:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 4 Mar 2025 15:47:00 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 11:56:56 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   iwalulya review
>     * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>     * predicate for determining whether the refinement has been disabled
>     * some other typos/comment improvements
>     * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 356:

> 354:     bool do_heap_region(G1HeapRegion* r) override {
> 355:       if (!r->is_free()) {
> 356:         // Need to scan all parts of non-free regions, so reset the claim.

Why is the condition "is_free"? I thought we scan only old-or-humongous regions?

src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 116:

> 114:     SwapGlobalCT,                // Swap global card table.
> 115:     SwapJavaThreadsCT,           // Swap java thread's card tables.
> 116:     SwapGCThreadsCT,             // Swap GC thread's card tables.

Do GC threads have card-table?

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 219:

> 217:       // The young gen revising mechanism reads the predictor and the values set
> 218:       // here. Avoid inconsistencies by locking.
> 219:       MutexLocker x(G1RareEvent_lock, Mutex::_no_safepoint_check_flag);

Who else can be in this critical-section? I don't get what this lock is protecting us from.

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 83:

> 81: 
> 82: public:
> 83:   static G1ConcurrentRefineThread* create(G1ConcurrentRefine* cr);

I wonder if the comment for this class "One or more G1 Concurrent Refinement Threads..."  has become obsolete. (AFAICS, this class is a singleton.)

src/hotspot/share/gc/g1/g1ConcurrentRefineWorkTask.cpp line 69:

> 67:     } else if (res == G1RemSet::NoInteresting) {
> 68:       _refine_stats.inc_cards_clean_again();
> 69:     }

A `switch` is probably cleaner.

src/hotspot/share/gc/g1/g1ConcurrentRefineWorkTask.cpp line 78:

> 76:       do_dirty_card(source, dest_card);
> 77:     }
> 78:     return pointer_delta(dirty_r, dirty_l, sizeof(CardValue));

I feel the `pointer_delta` line belongs to the caller. After that, even the entire method can be inlined to the caller.

YMMV.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979666477
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979678325
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979699376
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979695999
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979705019
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979709682

From acobbs at openjdk.org  Tue Mar  4 15:50:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 4 Mar 2025 15:50:57 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v12]
In-Reply-To: 
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 
Message-ID: 

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs  wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2698092830

From tschatzl at openjdk.org  Tue Mar  4 16:03:55 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 16:03:55 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 4 Mar 2025 15:16:17 GMT, Albert Mingkun Yang  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   iwalulya review
>>     * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>>     * predicate for determining whether the refinement has been disabled
>>     * some other typos/comment improvements
>>     * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 356:
> 
>> 354:     bool do_heap_region(G1HeapRegion* r) override {
>> 355:       if (!r->is_free()) {
>> 356:         // Need to scan all parts of non-free regions, so reset the claim.
> 
> Why is the condition "is_free"? I thought we scan only old-or-humongous regions?

We also need to clear young gen region marks because we want them to be all clean in the card table for the garbage collection (evacuation failure handling, use in next cycle).
This is maybe a bit of a waste if there are multiple refinement rounds between two gcs, but it's less expensive than in the pause wrt to latency. It's fast anyway.

> src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 116:
> 
>> 114:     SwapGlobalCT,                // Swap global card table.
>> 115:     SwapJavaThreadsCT,           // Swap java thread's card tables.
>> 116:     SwapGCThreadsCT,             // Swap GC thread's card tables.
> 
> Do GC threads have card-table?

Hmm, I thought I changed tat already just recently with Ivan's latest requests. Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979742662
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979752692

From mik3hall at gmail.com  Tue Mar  4 16:06:52 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 4 Mar 2025 10:06:52 -0600
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: <3b2ed0a6-cb82-4629-9eab-ef6e2336dd50@oracle.com>
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
 <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
 <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>
 <988B383E-B300-44B8-B1F2-4133719C79A9@gmail.com>
 <3b2ed0a6-cb82-4629-9eab-ef6e2336dd50@oracle.com>
Message-ID: <74D49715-48D0-4162-8C4B-323B3C2344B8@gmail.com>

>> 
> Good point about `CFBundleGetInfoString`. Maybe jpackage should set this field with the value of `--description` option. Another finding!
> 
> As for editing "Info.plist" from the runtime source, if the directory referenced from `--runtime-image` option is a valid bundle, i.e. has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, and there are no other options, like `--app-version`, jpackage should use the supplied directory as-is without editing the existing "Info.plist" file. Otherwise, jpackage should create "Info.plist" and make sure the values are consistent, of course.

I posted an example, there are a few other places in Info.plist that would also need changing to the correct version if you don?t already have a valid Info.plist for the JRE. The page of mine that you linked I think mentioned them all.

 __CodeSignature I didn?t include in what I did. It seemed like you might not be able to copy this but would need to do your own signing to generate it for a different JRE? My guess was that it is only really needed for an application distribution including that JRE. I know jpackage does some of its own signing. If this recreates the JRE __CodeSignature, this probably wouldn?t be a concern. 

It is possible if you are provided with a JRE where all this is correct then copying as-is would be fine. However, if you are copying a JRE that already has a JavaVirtualMachines file for that version I?m not sure what would happen. That should be checked? If you are providing a later release the new one should be used. If you are providing an earlier release the one you are adding will be ignored. Warnings at least? /usr/libexec/java_home -v  could maybe be useful here. I think though you would need to determine the version of what you are copying in.

Assuming the JRE you are adding to JavaVirtualMachines is a unique or current one for that java version then I think some fairly simple test like java ?version or something again with /usr/libexec/java_home could verify that everything is alright. 


From tschatzl at openjdk.org  Tue Mar  4 16:07:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 16:07:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 4 Mar 2025 16:00:46 GMT, Thomas Schatzl  wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 116:
>> 
>>> 114:     SwapGlobalCT,                // Swap global card table.
>>> 115:     SwapJavaThreadsCT,           // Swap java thread's card tables.
>>> 116:     SwapGCThreadsCT,             // Swap GC thread's card tables.
>> 
>> Do GC threads have card-table?
>
> Hmm, I thought I changed tat already just recently with Ivan's latest requests. Will fix.

Oh, I only fixed the string. Apologies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979761737

From tschatzl at openjdk.org  Tue Mar  4 16:07:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 16:07:58 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 4 Mar 2025 15:33:29 GMT, Albert Mingkun Yang  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   iwalulya review
>>     * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>>     * predicate for determining whether the refinement has been disabled
>>     * some other typos/comment improvements
>>     * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 219:
> 
>> 217:       // The young gen revising mechanism reads the predictor and the values set
>> 218:       // here. Avoid inconsistencies by locking.
>> 219:       MutexLocker x(G1RareEvent_lock, Mutex::_no_safepoint_check_flag);
> 
> Who else can be in this critical-section? I don't get what this lock is protecting us from.

The concurrent refine control thread in `G1ConcurrentRefineThread::do_refinement`, when calling `G1Policy::record_dirtying_stats`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979759329

From mik3hall at gmail.com  Tue Mar  4 16:17:33 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 4 Mar 2025 10:17:33 -0600
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: <74D49715-48D0-4162-8C4B-323B3C2344B8@gmail.com>
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
 <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
 <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>
 <988B383E-B300-44B8-B1F2-4133719C79A9@gmail.com>
 <3b2ed0a6-cb82-4629-9eab-ef6e2336dd50@oracle.com>
 <74D49715-48D0-4162-8C4B-323B3C2344B8@gmail.com>
Message-ID: 



> On Mar 4, 2025, at 10:06?AM, Michael Hall  wrote:
> 
>>> 
>> Good point about `CFBundleGetInfoString`. Maybe jpackage should set this field with the value of `--description` option. Another finding!
>> 
>> As for editing "Info.plist" from the runtime source, if the directory referenced from `--runtime-image` option is a valid bundle, i.e. has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, and there are no other options, like `--app-version`, jpackage should use the supplied directory as-is without editing the existing "Info.plist" file. Otherwise, jpackage should create "Info.plist" and make sure the values are consistent, of course.
> 
> I posted an example, there are a few other places in Info.plist that would also need changing to the correct version if you don?t already have a valid Info.plist for the JRE. The page of mine that you linked I think mentioned them all.
> 
> __CodeSignature I didn?t include in what I did. It seemed like you might not be able to copy this but would need to do your own signing to generate it for a different JRE? My guess was that it is only really needed for an application distribution including that JRE. I know jpackage does some of its own signing. If this recreates the JRE __CodeSignature, this probably wouldn?t be a concern. 
> 
> It is possible if you are provided with a JRE where all this is correct then copying as-is would be fine. However, if you are copying a JRE that already has a JavaVirtualMachines file for that version I?m not sure what would happen. That should be checked? If you are providing a later release the new one should be used. If you are providing an earlier release the one you are adding will be ignored. Warnings at least? /usr/libexec/java_home -v  could maybe be useful here. I think though you would need to determine the version of what you are copying in.
> 
> Assuming the JRE you are adding to JavaVirtualMachines is a unique or current one for that java version then I think some fairly simple test like java ?version or something again with /usr/libexec/java_home could verify that everything is alright. 
> 

I didn?t really think that through. I just realized that if you have a dmg with a JRE that the user will install onto their own machine all the version related will depend on what they have in their own JavaVirtualMachines. You can?t really do any install checking on a drag and drop. So I guess that would be at their own risk. You could still do some verification on adding the JRE to a dmg to ensure its validity for the Mac specific files.




From alexey.semenyuk at oracle.com  Tue Mar  4 16:20:00 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 4 Mar 2025 11:20:00 -0500
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: <74D49715-48D0-4162-8C4B-323B3C2344B8@gmail.com>
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
 <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
 <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>
 <988B383E-B300-44B8-B1F2-4133719C79A9@gmail.com>
 <3b2ed0a6-cb82-4629-9eab-ef6e2336dd50@oracle.com>
 <74D49715-48D0-4162-8C4B-323B3C2344B8@gmail.com>
Message-ID: 



On 3/4/2025 11:06 AM, Michael Hall wrote:
>> Good point about `CFBundleGetInfoString`. Maybe jpackage should set this field with the value of `--description` option. Another finding!
>>
>> As for editing "Info.plist" from the runtime source, if the directory referenced from `--runtime-image` option is a valid bundle, i.e. has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, and there are no other options, like `--app-version`, jpackage should use the supplied directory as-is without editing the existing "Info.plist" file. Otherwise, jpackage should create "Info.plist" and make sure the values are consistent, of course.
> I posted an example, there are a few other places in Info.plist that would also need changing to the correct version if you don?t already have a valid Info.plist for the JRE. The page of mine that you linked I think mentioned them all.
>
>   __CodeSignature I didn?t include in what I did. It seemed like you might not be able to copy this but would need to do your own signing to generate it for a different JRE? My guess was that it is only really needed for an application distribution including that JRE. I know jpackage does some of its own signing. If this recreates the JRE __CodeSignature, this probably wouldn?t be a concern.
>
> It is possible if you are provided with a JRE where all this is correct then copying as-is would be fine.
Right. If you package unpacked official OpenJDK tar.gz jpackage should 
take it as is.

> However, if you are copying a JRE that already has a JavaVirtualMachines file for that version I?m not sure what would happen.
The same as in the above case, I guess. jpackage should take it as is.

> That should be checked? If you are providing a later release the new one should be used.
Sorry, I don't follow. What release do you mean?

> If you are providing an earlier release the one you are adding will be ignored. Warnings at least? /usr/libexec/java_home -v  could maybe be useful here. I think though you would need to determine the version of what you are copying in.
>
> Assuming the JRE you are adding to JavaVirtualMachines is a unique or current one for that java version then I think some fairly simple test like java ?version or something again with /usr/libexec/java_home could verify that everything is alright.
jpackage doesn't control how you use bundles it produces. You can use 
the same input runtime image and create two separate bundles with 
different names, but with the same versions and install them both.

- Alexey
>


From tschatzl at openjdk.org  Tue Mar  4 16:20:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 16:20:58 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 4 Mar 2025 15:56:05 GMT, Thomas Schatzl  wrote:

> It's fast anyway.

To clarify: If you have multiple refinement rounds between two garbage collections, the time to clear the young gen cards is almost noise compared to the actual refinement effort. Like two magnitudes faster.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979785011

From asemenyuk at openjdk.org  Tue Mar  4 16:25:03 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Mar 2025 16:25:03 GMT
Subject: Integrated: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Feb 2025 16:54:59 GMT, Alexey Semenyuk  wrote:

> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>  - Don't issue the warning when the `--install-dir` value equals the default installation directory location.
>  - Add relevant tests.

This pull request has now been integrated.

Changeset: 6a31aaeb
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/6a31aaeb00b6c37e2e19c5f2759c4aa9ed87f25a
Stats:     186 lines in 5 files changed: 154 ins; 19 del; 13 mod

8350594: Misleading warning about install dir for DMG packaging

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/23752

From tschatzl at openjdk.org  Tue Mar  4 16:34:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 16:34:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
 
 
 
Message-ID: <3LR5VKMhSuXWmMlphpe8SLHm8vQQt6j343qaO61S_mQ=.dc1d2e4a-c858-44bd-9da0-f3f98340d939@github.com>

On Tue, 4 Mar 2025 16:04:00 GMT, Thomas Schatzl  wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 219:
>> 
>>> 217:       // The young gen revising mechanism reads the predictor and the values set
>>> 218:       // here. Avoid inconsistencies by locking.
>>> 219:       MutexLocker x(G1RareEvent_lock, Mutex::_no_safepoint_check_flag);
>> 
>> Who else can be in this critical-section? I don't get what this lock is protecting us from.
>
> The concurrent refine control thread in `G1ConcurrentRefineThread::do_refinement`, when calling `G1Policy::record_dirtying_stats`.

I could create an extra mutex for that if you want to make it clear which two parties access the same data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1979810144

From jlu at openjdk.org  Tue Mar  4 17:11:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 17:11:59 GMT
Subject: Integrated: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods
In-Reply-To: 
References: 
Message-ID: 

On Wed, 26 Feb 2025 22:18:17 GMT, Justin Lu  wrote:

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

This pull request has now been integrated.

Changeset: 5b8d3491
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/5b8d3491bf685a64b72b0ae763697353d09f61a1
Stats:     14 lines in 1 file changed: 9 ins; 0 del; 5 mod

4745837: Make grouping usage during parsing apparent in relevant NumberFormat methods

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/23813

From tschatzl at openjdk.org  Tue Mar  4 17:20:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Mar 2025 17:20:28 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v12]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  ayang review
    * renamings
    * refactorings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/b4d19d9b..4a978118

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=10-11

  Stats: 34 lines in 4 files changed: 13 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From naoto at openjdk.org  Tue Mar  4 17:56:06 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Mar 2025 17:56:06 GMT
Subject: RFR: 8351074: Disallow null prefix and suffix in DecimalFormat
 [v2]
In-Reply-To: <9YlrvHo8RszYEXGvitEoOr1l6cLODkGXiCV57cD2EJw=.526e1e82-be7b-4b5d-8899-6aa9cb8b66d6@github.com>
References: 
 <9YlrvHo8RszYEXGvitEoOr1l6cLODkGXiCV57cD2EJw=.526e1e82-be7b-4b5d-8899-6aa9cb8b66d6@github.com>
Message-ID: 

On Tue, 4 Mar 2025 01:47:40 GMT, Justin Lu  wrote:

>> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
>> 
>> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct bug ID for test

src/java.base/share/classes/java/text/DecimalFormat.java line 2815:

> 2813:      * 
Examples: +123, $123, sFr123
> 2814:      *
> 2815:      * @param newValue the new positive prefix

Although it may be apparent with the `@throws` tag, `@param` can also mention the new value is non-null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23880#discussion_r1979942411

From liach at openjdk.org  Tue Mar  4 17:59:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Mar 2025 17:59:03 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
 
Message-ID: 

On Tue, 25 Feb 2025 21:51:15 GMT, Claes Redestad  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   We no longer load DelegateMH as we no longer rebind
>
> Just got back home. Some comments inline, will need to run some tests and mull this over before approval.

@cl4es @rose00 I think I have addressed your existing comments; can you review again?

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

PR Comment: https://git.openjdk.org/jdk/pull/23706#issuecomment-2698472891

From jlu at openjdk.org  Tue Mar  4 18:12:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 18:12:48 GMT
Subject: RFR: 8351074: Disallow null prefix and suffix in DecimalFormat
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
> 
> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Make non-null apparent in param tag as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23880/files
  - new: https://git.openjdk.org/jdk/pull/23880/files/e13ac0d0..623bfdac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23880&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23880&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23880/head:pull/23880

PR: https://git.openjdk.org/jdk/pull/23880

From naoto at openjdk.org  Tue Mar  4 18:32:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Mar 2025 18:32:04 GMT
Subject: RFR: 8351074: Disallow null prefix and suffix in DecimalFormat
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 18:12:48 GMT, Justin Lu  wrote:

>> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
>> 
>> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make non-null apparent in param tag as well

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23880#pullrequestreview-2658576784

From jrose at openjdk.org  Tue Mar  4 19:21:11 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 4 Mar 2025 19:21:11 GMT
Subject: RFR: 8351045: ClassValue::remove cannot ensure computation
 observes up-to-date state
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 15:24:05 GMT, Chen Liang  wrote:

> After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a remove happened, and proceed to install an outdated value onto a CV.
> 
> The fix is simple - to force computation to retry when a remove has happened, so the retry can observe the up-to-date states from the remove. (finishEntry and removeEntry are both synchronized on the object monitor of the ClassValueMap instance)

Test is good also.

src/java.base/share/classes/java/lang/ClassValue.java line 504:

> 502:             Entry e = remove(classValue.identity);
> 503:             // e == null: Uninitialized, and no pending calls to computeValue.
> 504:             // remove didn't change anything.  No change.

Please capitalize the sentence: "Remove didn't?"
Also "Remove and discard" instead of "remove discarded".
Perhaps (this is being very picky) "Inside finishEntry, the logic will retry when it discovers the promise is removed."

This is a good bug fix.  Thanks for finding it.

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

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23866#pullrequestreview-2658737905
PR Review Comment: https://git.openjdk.org/jdk/pull/23866#discussion_r1980091146

From vromero at openjdk.org  Tue Mar  4 19:23:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 4 Mar 2025 19:23:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations
In-Reply-To: 
References: 
Message-ID: 

On Wed, 26 Feb 2025 13:50:52 GMT, Jan Lahoda  wrote:

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

looks sensible

test/langtools/tools/javac/modules/EdgeCases.java line 1190:

> 1188: 
> 1189:         List expected = List.of(
> 1190:                 "Test.java:2:8: compiler.err.feature.not.supported.in.source.plural: (compiler.misc.feature.module.imports), 24, 25",

isn't there a similar test above?

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2658747032
PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r1980096065

From mullan at openjdk.org  Tue Mar  4 19:27:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Mar 2025 19:27:59 GMT
Subject: RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails
 with --enable-preview
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 13:33:05 GMT, Sean Mullan  wrote:

> Please review this fix to a test that fails when run with --enable-preview. This fix is to add all the necessary utility classes imported by the test to the JAR file, and not just the test classes.

I am withdrawing this PR for now and marking the bug as a duplicate of [JDK-8351188](https://bugs.openjdk.org/browse/JDK-8351188). Although we could workaround the issue in the test, it is not causing normal mach 5 tests to fail (since they don't run with --enable-preview), so I think it is best to wait and see how this issue is resolved first.

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

PR Comment: https://git.openjdk.org/jdk/pull/23864#issuecomment-2698690691

From mullan at openjdk.org  Tue Mar  4 19:27:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Mar 2025 19:27:59 GMT
Subject: Withdrawn: 8350685: java/lang/System/SecurityManagerWarnings.java
 fails with --enable-preview
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 13:33:05 GMT, Sean Mullan  wrote:

> Please review this fix to a test that fails when run with --enable-preview. This fix is to add all the necessary utility classes imported by the test to the JAR file, and not just the test classes.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23864

From vaivanov at openjdk.org  Tue Mar  4 19:37:32 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 4 Mar 2025 19:37:32 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
Message-ID: 

> test setup was updated to generate data of requested size.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23873/files
  - new: https://git.openjdk.org/jdk/pull/23873/files/e5b2b4b0..69207701

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23873&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23873&range=00-01

  Stats: 8 lines in 3 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23873/head:pull/23873

PR: https://git.openjdk.org/jdk/pull/23873

From vaivanov at openjdk.org  Tue Mar  4 19:40:01 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 4 Mar 2025 19:40:01 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451
In-Reply-To: 
References: 
Message-ID: <4uGws8V7PrArUEcyCE6r7nq5nb2R1VfnZsRUD2W-SNA=.5f33f19a-3da7-418b-8c1c-80f61368c192@github.com>

On Mon, 3 Mar 2025 20:24:54 GMT, Vladimir Ivanov  wrote:

> test setup was updated to generate data of requested size.

Update to regular cycle template. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23873#issuecomment-2698720228

From duke at openjdk.org  Tue Mar  4 19:42:15 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Tue, 4 Mar 2025 19:42:15 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
Message-ID: 

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s  wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @SuppressWarnings (serial)

Sorting of short/byte/char is almost finished

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2698726394

From alanb at openjdk.org  Tue Mar  4 19:42:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Mar 2025 19:42:59 GMT
Subject: RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails
 with --enable-preview
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 13:33:05 GMT, Sean Mullan  wrote:

> Please review this fix to a test that fails when run with --enable-preview. This fix is to add all the necessary utility classes imported by the test to the JAR file, and not just the test classes.

The core reflection used by the launcher can provoke linkage errors. Same thing happens in other usages when looking for constructors or methods.  That said, it does appear that this test creates a JAR file containing classes with dangling references. Changing the change to launch a helper class rather than launching SecurityManagerWarnings, and adding the helper to the JAR file, would avoid this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23864#issuecomment-2698727500

From asemenyuk at openjdk.org  Tue Mar  4 20:34:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Mar 2025 20:34:11 GMT
Subject: Integrated: 8350013: Add a test for JDK-8150442
In-Reply-To: 
References: 
Message-ID: 

On Thu, 27 Feb 2025 14:17:30 GMT, Alexey Semenyuk  wrote:

> Add a test to verify jpackage is using a custom MSI condition blocking package installation depending on the version of Windows where the package installer runs. Support for this MSI condition was added in [JDK-8150442](https://bugs.openjdk.org/browse/JDK-8150442).
> 
> The test adds an unconditionally failing OS-version MSI condition to the resource directory. MSI installer using this condition should always fail. The exit code of the failed installation would be 1603. Extended error information can be dug in the MSI log file. To make the test work, the following changes to jpackage test lib have been made:
>  - Support non-0 exit code from MSI install handler. Support for non-0 exit codes was added to install handlers of all other types too. Added `PackageTest.setExpectedInstallExitCode(int)` method to configure the expected exit code of a package installation;
>  - Support using msi log files when MSI and EXE packages get installed, unpacked, or uninstalled. Added `PackageTest.createMsiLog(boolean)` to enable or disable creation of msi log files in a PackageTest instance and `Optional JPackageCommand.winMsiLogFile()` to access the current log file from the callbacks registered with the PackageTest instance.
> 
> Added tests for PackageTest class (PackageTestTest).
> 
> Additionally, improved the code in WindowsHelper detecting paths to Start Menu, Desktop, and other common paths. Previously, it relied on reading these paths from the registry. On some machines, required registry keys are not available. The code now will call .NET `Environment.GetFolderPath()` function through powershell if a registry key is missing.

This pull request has now been integrated.

Changeset: 3e86b3a8
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/3e86b3a879c7a425e7c689142cb1f0fdd4f679ed
Stats:     1898 lines in 8 files changed: 1419 ins; 181 del; 298 mod

8350013: Add a test for JDK-8150442

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/23825

From jrose at openjdk.org  Tue Mar  4 20:41:11 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 4 Mar 2025 20:41:11 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
Message-ID: 

On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang  wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We no longer load DelegateMH as we no longer rebind

I hope that the intrinsic mechanism can be further simplified, at some point.  But I defer to Jorn's comments about tableswitch.

Excellent cleanups.  Lots and lots of deleted code, and other code regularized.  Thank you!

src/java.base/share/classes/java/lang/invoke/SimpleMethodHandle.java line 36:

> 34:  * A method handle whose behavior is determined only by its LambdaForm.
> 35:  * Access to SimpleMethodHandle should ensure BoundMethodHandle is initialized
> 36:  * first.

Did you try factoring UNSAFE.ensureInit(BMH) into a static block in SimpleMethodHandle.java?
Sometimes that works.

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

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23706#pullrequestreview-2658926068
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1980190604

From bchristi at openjdk.org  Tue Mar  4 23:16:13 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Mar 2025 23:16:13 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 23 Feb 2025 10:20:23 GMT, Kim Barrett  wrote:

> I've made a prototype that adds Cleaner.waitForCleaning() and changes Bits.reserveMemory() to use it.
> 
> https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:wait-for-cleaning?expand=1

These caught my eye during my read-through:

- The main `CleanerImpl.run()` loop is changed to call `queue.poll()` in place of (blocking) `queue.remove(timeout)`. Could this make this a busier wait loop? 
- My impression is that it does more locking.

I wonder how these together could affect performance of less specialized Cleaner usage cases (where objects are not being enqueued very often).

I'm therefore inclined for changes along these lines to be limited to a DirectByteBuffer-specific mechanism, as you suggested in your point (2).

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2699207286

From mik3hall at gmail.com  Wed Mar  5 04:23:24 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 4 Mar 2025 22:23:24 -0600
Subject: [External] : Re: RFR: 8350594: Misleading warning about install
 dir for DMG packaging
In-Reply-To: 
References: 
 
 
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <1BBAF174-19F0-4704-A514-BA5CE2820542@gmail.com>
 <8dd675d3-5865-46b7-91c3-91be8f15f344@oracle.com>
 <5B6F124C-624E-4AF7-B356-D31881783EB1@gmail.com>
 <988B383E-B300-44B8-B1F2-4133719C79A9@gmail.com>
 <3b2ed0a6-cb82-4629-9eab-ef6e2336dd50@oracle.com>
 <74D49715-48D0-4162-8C4B-323B3C2344B8@gmail.com>
 
Message-ID: 



> On Mar 4, 2025, at 10:20?AM, Alexey Semenyuk  wrote:
> 
> 
> 
> On 3/4/2025 11:06 AM, Michael Hall wrote:
>>> Good point about `CFBundleGetInfoString`. Maybe jpackage should set this field with the value of `--description` option. Another finding!
>>> 
>>> As for editing "Info.plist" from the runtime source, if the directory referenced from `--runtime-image` option is a valid bundle, i.e. has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, and there are no other options, like `--app-version`, jpackage should use the supplied directory as-is without editing the existing "Info.plist" file. Otherwise, jpackage should create "Info.plist" and make sure the values are consistent, of course.
>> I posted an example, there are a few other places in Info.plist that would also need changing to the correct version if you don?t already have a valid Info.plist for the JRE. The page of mine that you linked I think mentioned them all.
>> 
>>  __CodeSignature I didn?t include in what I did. It seemed like you might not be able to copy this but would need to do your own signing to generate it for a different JRE? My guess was that it is only really needed for an application distribution including that JRE. I know jpackage does some of its own signing. If this recreates the JRE __CodeSignature, this probably wouldn?t be a concern.
>> 
>> It is possible if you are provided with a JRE where all this is correct then copying as-is would be fine.
> Right. If you package unpacked official OpenJDK tar.gz jpackage should take it as is.
> 
>> However, if you are copying a JRE that already has a JavaVirtualMachines file for that version I?m not sure what would happen.
> The same as in the above case, I guess. jpackage should take it as is.
> 
>> That should be checked? If you are providing a later release the new one should be used.
> Sorry, I don't follow. What release do you mean?
> 
>> If you are providing an earlier release the one you are adding will be ignored. Warnings at least? /usr/libexec/java_home -v  could maybe be useful here. I think though you would need to determine the version of what you are copying in.
>> 
>> Assuming the JRE you are adding to JavaVirtualMachines is a unique or current one for that java version then I think some fairly simple test like java ?version or something again with /usr/libexec/java_home could verify that everything is alright.
> jpackage doesn't control how you use bundles it produces. You can use the same input runtime image and create two separate bundles with different names, but with the same versions and install them both.
> 
> - Alexey

Sorry again that I was thinking something could be done for the actual install on the users machine which it can?t.

If you are using this for official release installs yes, it should be no problem copying it as-is. More or less what I do manually and it has worked just fine.

If it is a jpackage option that others might use, which as you indicate, it is. My suggestion is that jpackage can do some checking of its validity. I was trying a number of different things, some very different and all were accepted, none were valid JavaVirtualMachine system runtimes. 

As a further enhancement I think it would be possible if the MacOS needed files are not there for jpackage to supply them to make it a valid JavaVirtualMachines system jre. My Info.plist example showed a way you could make all needed version/description changes using /usr/libexec/PlistBuddy. I believe jpackage currently relies on issuing just such native commands. Maybe some future use of that for jpackage could also turn up. This is why I thought about  writing a plist editor for jpackage application build use. Signing if needed I?m sure you could manage, you probably already address the issues.

As mentioned I manually put together a JavaVirtualMachines runtime from a built jdk that seemed to work fine command line and when used as the user specified runtime for a fairly complex application. For some reason it didn?t work to automatically jlink from. This led to other issues when I tried to address ?add-modules needed for JavaFX. So there might be some non-trivial complications that I didn?t resolve. 

Thanks yet again for the follow-up. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tschatzl at openjdk.org  Wed Mar  5 09:45:00 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 5 Mar 2025 09:45:00 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v13]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * fix whitespace
  * additional whitespace between log tags
  * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/4a978118..a457e6e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=11-12

  Stats: 116 lines in 6 files changed: 50 ins; 50 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From mukulg at apache.org  Wed Mar  5 09:54:12 2025
From: mukulg at apache.org (Mukul Gandhi)
Date: Wed, 5 Mar 2025 15:24:12 +0530
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <002b3ebb-cbb5-44d8-ad67-3f6ae5af2024@oracle.com>
References: 
 
 
 
 
 
 <002b3ebb-cbb5-44d8-ad67-3f6ae5af2024@oracle.com>
Message-ID: 

Hi Joe,
    Thanks for your mail, and interest about what Apache Xalan-J team
has been able to do up to now with respect to XSLT 3.0 language
implementation.

On Tue, Mar 4, 2025 at 10:24?AM Joe Wang  wrote:
> Great work. Are the tests counted differently?
Apache Xalan-J's XSLT 3.0 & XPath 3.1 tests have been verified to pass
with Xalan-J's XSL 3.0 implementation, and therefore obviously have
tests numeric count intrinsic to Xalan-J's XSL 3 implementation. As
I've mentioned, and as of now Xalan-J has 910 XSL 3 tests. Although,
these tests count may seem less overall, but many more XSL 3 tests can
be added to Xalan-J's XSL 3 test suite (I'm adding such newer tests,
as I'm working more with Xalan-J).

Gary Gregory wrote 1-2 days before on Xalan-J dev forum, that he'll be
happy to support making Xalan-J's XSL 3 beta release around these
days.

> The W3C test suite for XSLT 3.0 is said to "contain over 11,000 test cases". What would be the pass rate if measured against the W3C test suite?

I'm in a process to configure on my local, to run W3C's XSLT 3.0 test
suite and to know what is Xalan-J XSL 3 implementation's quality with
respect to those tests. I shall publish those XSL 3 test suite results
when I've successfully run those tests.

Xalan-J's XSL 3.0 implementation already has following working tests
from W3C XSLT 3.0 test suite.

https://github.com/apache/xalan-java/blob/xalan-j_xslt3.0_mvn/src/test/java/org/apache/xalan/tests/xslt3/W3c_xslt30_AxesTests.java
https://github.com/apache/xalan-java/blob/xalan-j_xslt3.0_mvn/src/test/java/org/apache/xalan/tests/xslt3/W3c_xslt30_IterateTests.java
(Xalan-J's own xsl:iterate tests are located at,
https://github.com/apache/xalan-java/blob/xalan-j_xslt3.0_mvn/src/test/java/org/apache/xalan/tests/xslt3/XslIterateTests.java)

The reason why, Xalan-J hasn't been able to run all XSLT 3.0 tests yet
from W3C test suite, is how Xalan-J's XSLT transformation serializer
currently works. Xalan-J's XSLT transformation serializer emits
results a bit differently (mostly these are whitespace character
issues, but compliant with XSLT 3.0 spec) than the XSL tests expected
output specified within W3C's XSLT 3.0 test suite. I'm trying to get
around with these XSL tests issues.

Many thanks.


-- 
Regards,
Mukul Gandhi

From schernyshev at openjdk.org  Wed Mar  5 10:35:14 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 5 Mar 2025 10:35:14 GMT
Subject: Integrated: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: 
References: 
Message-ID: 

On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev  wrote:

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

This pull request has now been integrated.

Changeset: de29ef3b
Author:    Sergey Chernyshev 
Committer: Dmitry Chuyko 
URL:       https://git.openjdk.org/jdk/commit/de29ef3bf3a029f99f340de9f093cd20544217fd
Stats:     491 lines in 9 files changed: 449 ins; 3 del; 39 mod

8343191: Cgroup v1 subsystem fails to set subsystem path

Co-authored-by: Severin Gehwolf 
Reviewed-by: sgehwolf, mbaesken

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

PR: https://git.openjdk.org/jdk/pull/21808

From iwalulya at openjdk.org  Wed Mar  5 11:12:58 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 5 Mar 2025 11:12:58 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 17:20:28 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review
>     * renamings
>     * refactorings

src/hotspot/share/gc/g1/g1HeapRegion.hpp line 475:

> 473:   void hr_clear(bool clear_space);
> 474:   // Clear the card table corresponding to this region.
> 475:   void clear_cardtable();

in some places `cardtable()` has been refactored to `card_table` e.g. in G1HeapRegionManager.

src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 67:

> 65: 
> 66:   size_t _num_marked_as_dirty_cards;
> 67:   size_t _num_marked_as_into_cset_cards;

Suggestion:

  size_t _num_cards_marked_dirty;
  size_t _num_cards_marked_to_cset;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1980117641
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1980145229

From iwalulya at openjdk.org  Wed Mar  5 11:12:56 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 5 Mar 2025 11:12:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 5 Mar 2025 09:45:00 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * fix whitespace
>   * additional whitespace between log tags
>   * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename

src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp line 32:

> 30: #include "gc/g1/g1HeapRegion.hpp"
> 31: #include "gc/g1/g1ThreadLocalData.hpp"
> 32: #include "utilities/macros.hpp"

Suggestion:

#include "utilities/formatBuffer.hpp"
#include "utilities/macros.hpp"

to use `err_msg`

src/hotspot/share/gc/g1/g1RemSet.cpp line 90:

> 88: // contiguous ranges of dirty cards to be scanned. These blocks are converted to actual
> 89: // memory ranges and then passed on to actual scanning.
> 90: class G1RemSetScanState : public CHeapObj {

Need to update the comment above to remove reference to "log buffers" (L:67).

src/hotspot/share/gc/g1/g1RemSet.hpp line 44:

> 42: class CardTableBarrierSet;
> 43: class G1AbstractSubTask;
> 44: class G1RemSetScanState;

Already declared on line 48 below

src/hotspot/share/gc/g1/g1ThreadLocalData.hpp line 29:

> 27: #include "gc/g1/g1BarrierSet.hpp"
> 28: #include "gc/g1/g1CardTable.hpp"
> 29: #include "gc/g1/g1CollectedHeap.hpp"

probably does not need to be included

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1981138746
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1981162792
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1981118865
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1981142943

From rriggs at openjdk.org  Wed Mar  5 15:04:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Mar 2025 15:04:57 GMT
Subject: RFR: 8351045: ClassValue::remove cannot ensure computation
 observes up-to-date state
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 15:24:05 GMT, Chen Liang  wrote:

> After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a remove happened, and proceed to install an outdated value onto a CV.
> 
> The fix is simple - to force computation to retry when a remove has happened, so the retry can observe the up-to-date states from the remove. (finishEntry and removeEntry are both synchronized on the object monitor of the ClassValueMap instance)

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23866#pullrequestreview-2661404171

From liach at openjdk.org  Wed Mar  5 15:14:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 15:14:20 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v10]
In-Reply-To: 
References: 
Message-ID: 

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Links

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/c237c2ad..712d3ec5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=08-09

  Stats: 7 lines in 6 files changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977

PR: https://git.openjdk.org/jdk/pull/19977

From vklang at openjdk.org  Wed Mar  5 15:15:58 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 5 Mar 2025 15:15:58 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 1 Mar 2025 15:43:17 GMT, Doug Lea 
 wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce volatile reads

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3741:

> 3739:     public  ForkJoinTask submitWithTimeout(Callable callable,
> 3740:                                                  long timeout, TimeUnit unit,
> 3741:                                                  Consumer> timeoutAction) {

I wonder if the variance of the Consumer to this method should be more permissible. Something like:

public  ForkJoinTask submitWithTimeout(Callable callable,
                                                 long timeout, TimeUnit unit,
                                                 Consumer> timeoutAction) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1981598242

From liach at openjdk.org  Wed Mar  5 15:19:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 15:19:27 GMT
Subject: RFR: 8351045: ClassValue::remove cannot ensure computation
 observes up-to-date state [v2]
In-Reply-To: 
References: 
Message-ID: 

> After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a remove happened, and proceed to install an outdated value onto a CV.
> 
> The fix is simple - to force computation to retry when a remove has happened, so the retry can observe the up-to-date states from the remove. (finishEntry and removeEntry are both synchronized on the object monitor of the ClassValueMap instance)

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Improve docs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-remove
 - 8351045: ClassValue::remove cannot ensure computation observes up-to-date state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23866/files
  - new: https://git.openjdk.org/jdk/pull/23866/files/eabc8b63..a11aff0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23866&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23866&range=00-01

  Stats: 9916 lines in 215 files changed: 6360 ins; 1787 del; 1769 mod
  Patch: https://git.openjdk.org/jdk/pull/23866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23866/head:pull/23866

PR: https://git.openjdk.org/jdk/pull/23866

From liach at openjdk.org  Wed Mar  5 15:19:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 15:19:28 GMT
Subject: RFR: 8351045: ClassValue::remove cannot ensure computation
 observes up-to-date state [v2]
In-Reply-To: 
References: 
 
Message-ID: <-_EuN2zDKitAOsiS6cGROw4aRQoEEA2lH5QVWf548r4=.70fc2644-7cde-4cb4-a205-20d3bdea1a1b@github.com>

On Tue, 4 Mar 2025 19:17:57 GMT, John R Rose  wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Improve docs
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-remove
>>  - 8351045: ClassValue::remove cannot ensure computation observes up-to-date state
>
> src/java.base/share/classes/java/lang/ClassValue.java line 504:
> 
>> 502:             Entry e = remove(classValue.identity);
>> 503:             // e == null: Uninitialized, and no pending calls to computeValue.
>> 504:             // remove didn't change anything.  No change.
> 
> Please capitalize the sentence: "Remove didn't?"
> Also "Remove and discard" instead of "remove discarded".
> Perhaps (this is being very picky) "Inside finishEntry, the logic will retry when it discovers the promise is removed."
> 
> This is a good bug fix.  Thanks for finding it.

`remove` refers to the `WeakHashMap.remove(identity)` call. Clarified by using `remove(identity)` instead of just "remove".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23866#discussion_r1981603956

From ecaspole at openjdk.org  Wed Mar  5 15:21:39 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 5 Mar 2025 15:21:39 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH fails
 with -ea
Message-ID: 

The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

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

Commit messages:
 - 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem benchmark fails with -ea

Changes: https://git.openjdk.org/jdk/pull/23917/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23917&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350460
  Stats: 153 lines in 1 file changed: 0 ins; 153 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23917/head:pull/23917

PR: https://git.openjdk.org/jdk/pull/23917

From alanb at openjdk.org  Wed Mar  5 16:18:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Mar 2025 16:18:54 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 15:33:16 GMT, SendaoYan  wrote:

> Should we remove these JMH tests, or just fix the test bug and make tests run normally

I think that would be best as they are left over from early development.

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

PR Comment: https://git.openjdk.org/jdk/pull/23437#issuecomment-2701421456

From liach at openjdk.org  Wed Mar  5 16:43:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 16:43:54 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 15:16:03 GMT, Eric Caspole  wrote:

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

These benchmarks are malformed indeed; the blackhole is never used.

@ericcaspole Do you mean hotspot-compiler for the label instead of javac?

Also might need to add an 2025 copyright header for this file.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23917#pullrequestreview-2661738797
PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2701485115
PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2701489585

From acobbs at openjdk.org  Wed Mar  5 17:36:13 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 5 Mar 2025 17:36:13 GMT
Subject: Integrated: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs)
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: 

On Sat, 2 Nov 2024 15:40:30 GMT, Archie Cobbs  wrote:

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

This pull request has now been integrated.

Changeset: 661bd5bf
Author:    Archie Cobbs 
URL:       https://git.openjdk.org/jdk/commit/661bd5bfe883a7449c6949c9f4bd6b5d82d20e10
Stats:     211 lines in 93 files changed: 0 ins; 90 del; 121 mod

8343478: Remove unnecessary @SuppressWarnings annotations (core-libs)

Reviewed-by: darcy, asemenyuk, joehw

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

PR: https://git.openjdk.org/jdk/pull/21852

From liach at openjdk.org  Wed Mar  5 17:48:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 17:48:05 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
 
Message-ID: 

On Tue, 4 Mar 2025 20:36:02 GMT, John R Rose  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   We no longer load DelegateMH as we no longer rebind
>
> src/java.base/share/classes/java/lang/invoke/SimpleMethodHandle.java line 36:
> 
>> 34:  * A method handle whose behavior is determined only by its LambdaForm.
>> 35:  * Access to SimpleMethodHandle should ensure BoundMethodHandle is initialized
>> 36:  * first.
> 
> Did you try factoring UNSAFE.ensureInit(BMH) into a static block in SimpleMethodHandle.java?
> Sometimes that works.

To be exact, I did not encounter any initialization issue during my use of BMH/SimpleMH. We don't need ensureInit as SimpleMH already extends BMH. Maybe my concern is just red herring, as I saw a warning on BMH$Species_L that its access should go through BMH first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1981887881

From jjg at openjdk.org  Wed Mar  5 18:09:53 2025
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Mar 2025 18:09:53 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 16:41:18 GMT, Hannes Walln?fer  wrote:

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

As you indicated, there are two problems being addressed here, which might indicate the need for two separate patches. These issues are:

1. The leading 1-space problem.
2. The trailing newline-after-
 problem

For the first, it is unduly hard work to fix this just for `
` blocks. I still think that an overall better long-term solution would be to apply a conceptual `stripIndent` to the entire doc comment. This would bring traditional comments into line with the new Markdown comments, and can be done in just a few lines in `DocCommentParser`, and doing it there in DCP means you need not update `Elements.getDocComment`. If nothing else, I would suggest doing the experiment and comparing the generated docs, to verify there are no unexpected side effects. If there are any significant unexpected side effects, then your approach might deserve a second look. You could also make this a JDK-version-specific change if you wanted: meaning the new behavior does not apply to older JDK versions, although that is not a policy we have adhered to in the past.

For the second, I just feel that is a step too far, using JavaScript to clean up what some might consider to be bad input. Authors should either write HTML according to the HTML (and CSS?) specs, so that `javadoc` is just a "pass-through" layer, or authors should use a suitable construct, like `{@snippet...}`, that is "pleasing" to look at in source form while still generating the desired output.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2701699839

From jlu at openjdk.org  Wed Mar  5 18:16:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Mar 2025 18:16:08 GMT
Subject: Integrated: 8351074: Disallow null prefix and suffix in DecimalFormat
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Mar 2025 01:37:57 GMT, Justin Lu  wrote:

> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
> 
> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

This pull request has now been integrated.

Changeset: c3b48196
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/c3b48196af40356a8251b42db13e02ed905c2139
Stats:     64 lines in 2 files changed: 59 ins; 0 del; 5 mod

8351074: Disallow null prefix and suffix in DecimalFormat

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/23880

From redestad at openjdk.org  Wed Mar  5 18:58:55 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 5 Mar 2025 18:58:55 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
Message-ID: 

On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang  wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We no longer load DelegateMH as we no longer rebind

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23706#pullrequestreview-2662196626

From redestad at openjdk.org  Wed Mar  5 18:58:56 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 5 Mar 2025 18:58:56 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
 
 
Message-ID: 

On Tue, 25 Feb 2025 22:08:33 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2241:
>> 
>>> 2239:         var form = constantForm(basicType);
>>> 2240: 
>>> 2241:         if (type.isPrimitive()) {
>> 
>> I think you could simplify this using `Wrapper.forBasicType`; all variants should be able to use `wrapper.convert`
>
> The cast is not performed if the `type` is an interface; this is a behavioral disparity with the old `value = ptype.cast(value);` in `insertArguments`.

Sure, we'd need an explicit `cast` in the `OBJECT` case and that would be a bit redundant. Might still amount to a code simplification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1982027617

From hannesw at openjdk.org  Wed Mar  5 20:48:57 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 Mar 2025 20:48:57 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 16:41:18 GMT, Hannes Walln?fer  wrote:

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

Thanks for reviewing this, Jon. I agree there are two issues that maybe shold be handled separately. 

Regarding the first issue, stripping leading space in `DocCommentParser`, I did in fact start out processing the whole doc comment. I was pretty far into fixing tests when I realized that this approach breaks our ability to get a diagnostic position from a string extracted from the comment. The source postion mapping is generated in `JavadocScanner`, and it would be quite complex to keep track of whitespace removed after the fact and correctly translate to a source position. 

The test that made me realize this problem was [TestDocTreeDiags.java], which tests reporting positions inside strings extracted from the comment (added in [JDK-8268420]) , but with wholesale whitespace removal also start positions are affected. I should have mentioned this in the PR description, but it was already long enough as it was.

[TestDocTreeDiags.java]: https://github.com/openjdk/jdk/blob/master/test/langtools/jdk/javadoc/doclet/testDocTreeDiags/TestDocTreeDiags.java
[JDK-8268420]: https://bugs.openjdk.org/browse/JDK-8268420

This is why I reverted to the proposed minimalistic solution, limiting space removal to text and `{@code}`/`{@literal}` tags within `
` elements. These are all doctrees that are passed though without further processing, so it is highly unlikely that anybody would ever want to report a source position inside of them. The begin postions will be correct since we're parsing the unchanged doc comment, but positions inside the string after the first line break would report a wrong position. This is why I filed [a CSR to amend the spec for above mentioned method][CSR] with a note about this. 

[CSR]: https://bugs.openjdk.org/browse/JDK-8350428

Regarding the second issue, I agree the JavaScript solution is not ideal. But it's a small price to pay in order to get readable and good looking documentation. We have close to 1000 instances of `
{@code}` in JDK source code alone, and they will never get fixed and continue to haunt our otherwise great documentation. The same problem affects most Java libraries out there. You see I'm quite passionate about this, but I agree to move it to a separate issue if you think that's the best way to handle this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2702033467

From duke at openjdk.org  Wed Mar  5 23:59:00 2025
From: duke at openjdk.org (Sunmisc Unsafe)
Date: Wed, 5 Mar 2025 23:59:00 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v6]
In-Reply-To: 
References: 
 
 
Message-ID: <60IBeWm3452rLJC_2GQEdhY0I_vY0D7UKXCLgxkw5eM=.f728b6a3-bca0-4c4d-bb89-e69626d833db@github.com>

On Wed, 5 Mar 2025 15:13:06 GMT, Viktor Klang  wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce volatile reads
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3741:
> 
>> 3739:     public  ForkJoinTask submitWithTimeout(Callable callable,
>> 3740:                                                  long timeout, TimeUnit unit,
>> 3741:                                                  Consumer> timeoutAction) {
> 
> I wonder if the variance of the Consumer to this method should be more permissible. Something like:
> 
> public  ForkJoinTask submitWithTimeout(Callable callable,
>                                                  long timeout, TimeUnit unit,
>                                                  Consumer> timeoutAction) {

Maybe it's worth using java.time.Duration, although it doesn't fit into the API very elegantly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1982349285

From vpaprotski at openjdk.org  Thu Mar  6 00:11:01 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 6 Mar 2025 00:11:01 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 19:37:32 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 149:

> 147:         while (lorem.length() < size) {
> 148:             lorem += lorem;
> 149:         }

This is matter of taste, but I would prefer StringBuilder instead:

        StringBuilder builder = new StringBuilder(lorem.length()+size);
        for (int l = 0; l 179: 
> 180:     static class SlicingPool {
> 181:         final MemorySegment pool;

This seems ok; though I was suspicious but I can't measure a difference: with the default parameters for size of 5, 20, 100, arena was 10x-200x+ times bigger. Now it fits exactly.

I measured 1x, 10x, 100x (for size 1500 and 15000) and results appear consistent.

So, this is just a note; looks good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1982330072
PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1982357391

From darcy at openjdk.org  Thu Mar  6 00:31:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Mar 2025 00:31:54 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 15:16:03 GMT, Eric Caspole  wrote:

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23917#pullrequestreview-2662793406

From vaivanov at openjdk.org  Thu Mar  6 00:43:05 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Mar 2025 00:43:05 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 5 Mar 2025 23:29:42 GMT, Volodymyr Paprotski  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451
>
> test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 149:
> 
>> 147:         while (lorem.length() < size) {
>> 148:             lorem += lorem;
>> 149:         }
> 
> This is matter of taste, but I would prefer StringBuilder instead:
> 
>         StringBuilder builder = new StringBuilder(lorem.length()+size);
>         for (int l = 0; l             builder.append(lorem);
>         }
>         return builder.substring(0, size);

The initial version looks more readable for me. 
While it initialization part no need to tune performance here and simple version should be OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1982384108

From vpaprotski at openjdk.org  Thu Mar  6 00:46:58 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 6 Mar 2025 00:46:58 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 19:37:32 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

LGTM

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

Marked as reviewed by vpaprotski (Author).

PR Review: https://git.openjdk.org/jdk/pull/23873#pullrequestreview-2662811832

From vpaprotski at openjdk.org  Thu Mar  6 00:46:59 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 6 Mar 2025 00:46:59 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 6 Mar 2025 00:39:59 GMT, Vladimir Ivanov  wrote:

>> test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 149:
>> 
>>> 147:         while (lorem.length() < size) {
>>> 148:             lorem += lorem;
>>> 149:         }
>> 
>> This is matter of taste, but I would prefer StringBuilder instead:
>> 
>>         StringBuilder builder = new StringBuilder(lorem.length()+size);
>>         for (int l = 0; l>             builder.append(lorem);
>>         }
>>         return builder.substring(0, size);
>
> The initial version looks more readable for me. 
> While it initialization part no need to tune performance here and simple version should be OK.

Sounds good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1982387796

From asemenyuk at openjdk.org  Thu Mar  6 01:08:46 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Mar 2025 01:08:46 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
Message-ID: 

jpackage app laucnher will expand environment variables in .cfg files.

Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
| String    | Variables | Variable Values | Expanded string | Note |
| -------- | ------- |------- |------- |------- |
| 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
| 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
| 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
| 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
| 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
| 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |

`$` character combination prevents variable expansion:
| String    | Variables | Variable Values | Expanded string |
| -------- | ------- |------- |------- |
| 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
| 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |

`\` character combination escapes ``:
| String    | Variables | Variable Values | Expanded string |
| -------- | ------- |------- |------- |
| 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |

If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
| String    | Expanded string |
| -------- | ------- |
|
a\\b\\c
|
a\\b\\c
|


Expansion is non-recursive:
| String    | Variables | Variable Values | Expanded string | Note |
| -------- | ------- |------- |------- |------- |
| 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" will not be expanded |

Values of `APPDIR`, `BINDIR`, and `ROOTDIR` environment variables are ignored, and these names are substituted by values calculated by jpackage app launcher as previously.

`$APPDIR` is equivalent to `${APPDIR}`.
`$BINDIR` is equivalent to `${BINDIR}`.
`$ROOTDIR` is equivalent to `${ROOTDIR}`.

You will find two entities dealing with token replacement in this patch:
 - StringProcessing.cpp/.h - code that performs variable substitution in .cfg files;
 - TokenReplace.java - helper class for jpackage tests. It will be later used with other jpackage tests and to implement [jdk.jpackage.internal.OverridableResource.substitute()](https://github.com/openjdk/jdk/blob/11a37c829c12d064874416a7b242596cf23972e5/src/jdk.jpackage/share/classes/jdk/jpackage/internal/OverridableResource.java#L305) method.

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

Commit messages:
 - Shorter test desc
 - Minor
 - A bit of javadoc
 - Update copyright year
 - Applied bin/blessed-modifier-order.sh
 - 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files
 - Moved $APPDIR, $BINDIR, and $ROOTDIR macros to JPackageCommand
 - Add Executor.setEnvVar()
 - Move token substitution in generic TokenReplace class.

Changes: https://git.openjdk.org/jdk/pull/23923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341641
  Stats: 1067 lines in 11 files changed: 1025 ins; 8 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/23923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923

PR: https://git.openjdk.org/jdk/pull/23923

From asemenyuk at openjdk.org  Thu Mar  6 01:08:46 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Mar 2025 01:08:46 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 21:13:44 GMT, Alexey Semenyuk  wrote:

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" will ...

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/23923#issuecomment-2702462093

From duke at openjdk.org  Thu Mar  6 01:35:54 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 6 Mar 2025 01:35:54 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException [v2]
In-Reply-To: 
References: 
 <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>
 
Message-ID: 

On Thu, 27 Feb 2025 01:55:59 GMT, Xiaohong Gong  wrote:

>> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException
>>    
>>    Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86
>>    and AArch64 with the following error:
>>    
>>    ```
>>    java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>>    ```
>>    
>>    The variable `long256_arr_idx` is misused when indexing `LongVector l2`,
>>    `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()`
>>    resulting in the IndexOutOfBoundsException error. On the other hand, the
>>    unified index for 128-bit, 256-bit and 512-bit species might not be
>>    proper since it leaves gaps in between when accessing the data
>>    for 128-bit and 256-bit species. This will unnecessarily include the
>>    noise due to cache misses or (on some targets) prefetching additional
>>    cache lines which are not usable, thereby impacting the crispness of
>>    microbenchmark.
>>    
>>    Hence, we improved the benchmark from several aspects,
>>    1. Used sufficient number of predicated operations within the vector
>>    loop while minimizing the noise due to memory operations.
>>    2. Modified the index computation logic which can now withstand any
>>    ARRAYLEN without resulting in an IOOBE.
>>    3. Removed redundant vector read/writes to instance fields, thus
>>    eliminating significant boxing penalty which translates into throughput
>>    gains.
>>    
>>    Change-Id: Ie8a9d495b1ca5e36f1eae069ff70a815a2de00c0
>>  - Revert "8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException"
>>    
>>    This reverts commit 083bedec04d5ab78a420e156e74c1257ce30aee8.
>
> Still looks good to me!

@XiaohongGong @eme64 @jatin-bhateja @PaulSandoz  Thanks for your review. I'm going to integrate the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2702495138

From duke at openjdk.org  Thu Mar  6 01:35:55 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Mar 2025 01:35:55 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException [v2]
In-Reply-To: <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>
References: 
 <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>
Message-ID: 

On Wed, 26 Feb 2025 07:04:58 GMT, Nicole Xu  wrote:

>> Suite `MaskedLogicOpts.maskedLogicOperationsLong512()` failed on both x86 and AArch64 with the following error:
>> 
>> 
>> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>> 
>> 
>> The variable `long256_arr_idx` is misused when indexing `LongVector l2`, `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()` resulting in the IndexOutOfBoundsException error. On the other hand, the unified index for 128-bit, 256-bit and 512-bit species might not be proper since it leaves gaps in between when accessing the data for 128-bit and 256-bit species. This will unnecessarily include the noise due to cache misses or (on some targets) prefetching additional cache lines which are not usable, thereby impacting the crispness of microbenchmark.
>> 
>> Hence, we improved the benchmark from several aspects,
>> 1. Used sufficient number of predicated operations within the vector loop while minimizing the noise due to memory operations.
>> 2. Modified the index computation logic which can now withstand any ARRAYLEN without resulting in an IOOBE.
>> 3. Removed redundant vector read/writes to instance fields, thus eliminating significant boxing penalty which translates into throughput gains.
>
> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException
>    
>    Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86
>    and AArch64 with the following error:
>    
>    ```
>    java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>    ```
>    
>    The variable `long256_arr_idx` is misused when indexing `LongVector l2`,
>    `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()`
>    resulting in the IndexOutOfBoundsException error. On the other hand, the
>    unified index for 128-bit, 256-bit and 512-bit species might not be
>    proper since it leaves gaps in between when accessing the data
>    for 128-bit and 256-bit species. This will unnecessarily include the
>    noise due to cache misses or (on some targets) prefetching additional
>    cache lines which are not usable, thereby impacting the crispness of
>    microbenchmark.
>    
>    Hence, we improved the benchmark from several aspects,
>    1. Used sufficient number of predicated operations within the vector
>    loop while minimizing the noise due to memory operations.
>    2. Modified the index computation logic which can now withstand any
>    ARRAYLEN without resulting in an IOOBE.
>    3. Removed redundant vector read/writes to instance fields, thus
>    eliminating significant boxing penalty which translates into throughput
>    gains.
>    
>    Change-Id: Ie8a9d495b1ca5e36f1eae069ff70a815a2de00c0
>  - Revert "8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException"
>    
>    This reverts commit 083bedec04d5ab78a420e156e74c1257ce30aee8.

@xyyNicole 
Your change (at version 896c27ea0b74f2848185d1bd8f931a0f44249673) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2702497534

From duke at openjdk.org  Thu Mar  6 01:43:05 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 6 Mar 2025 01:43:05 GMT
Subject: Integrated: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails
 due to IndexOutOfBoundsException
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Jan 2025 09:04:47 GMT, Nicole Xu  wrote:

> Suite `MaskedLogicOpts.maskedLogicOperationsLong512()` failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing `LongVector l2`, `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()` resulting in the IndexOutOfBoundsException error. On the other hand, the unified index for 128-bit, 256-bit and 512-bit species might not be proper since it leaves gaps in between when accessing the data for 128-bit and 256-bit species. This will unnecessarily include the noise due to cache misses or (on some targets) prefetching additional cache lines which are not usable, thereby impacting the crispness of microbenchmark.
> 
> Hence, we improved the benchmark from several aspects,
> 1. Used sufficient number of predicated operations within the vector loop while minimizing the noise due to memory operations.
> 2. Modified the index computation logic which can now withstand any ARRAYLEN without resulting in an IOOBE.
> 3. Removed redundant vector read/writes to instance fields, thus eliminating significant boxing penalty which translates into throughput gains.

This pull request has now been integrated.

Changeset: 107ee878
Author:    Nicole Xu 
URL:       https://git.openjdk.org/jdk/commit/107ee878d66f4006f102c1fd12af3bf156a25757
Stats:     145 lines in 1 file changed: 5 ins; 29 del; 111 mod

8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException

Co-authored-by: Jatin Bhateja 
Reviewed-by: jbhateja, xgong

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

PR: https://git.openjdk.org/jdk/pull/22963

From almatvee at openjdk.org  Thu Mar  6 02:21:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Mar 2025 02:21:52 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 21:13:44 GMT, Alexey Semenyuk  wrote:

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" will ...

If you do `echo` on macOS in terminal for unset variable it will be expanded to `empty string`, so for `"Unset variables are not expanded."` should we have `Welcome !` instead of `Welcome $USER!`?

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

PR Comment: https://git.openjdk.org/jdk/pull/23923#issuecomment-2702585129

From syan at openjdk.org  Thu Mar  6 02:56:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 02:56:34 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope [v2]
In-Reply-To: 
References: 
Message-ID: <1uabYpqku5peFfFSEtLItA_Fy8BSsAiTeDPhObGvYN8=.369bd032-3be2-4d52-b006-b1474c25a474@github.com>

> Hi all,
> 
> Several JMH tests fails "cannot access class jdk.internal.vm.ContinuationScope (in module java.base) because module java.base does not export jdk.internal.vm to unnamed module". This PR add VM option `--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to fix the JMH test bug.
> 
> Change has been verified locally, test-fix only, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove test/micro/org/openjdk/bench/loom/obsolete/FreezeAndThaw.java test/micro/org/openjdk/bench/loom/obsolete/OneShot.java test/micro/org/openjdk/bench/loom/obsolete/Oscillation.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23437/files
  - new: https://git.openjdk.org/jdk/pull/23437/files/fe58200d..6161b740

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23437&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23437&range=00-01

  Stats: 505 lines in 3 files changed: 0 ins; 505 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23437/head:pull/23437

PR: https://git.openjdk.org/jdk/pull/23437

From syan at openjdk.org  Thu Mar  6 02:56:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 02:56:34 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope
In-Reply-To: 
References: 
 
 
Message-ID: <5qTe2qJdPJC2KM7U3UxYQ5ENDA3ptAqYZmlD6h5suZ0=.a9c50ae1-d3e9-4f16-a3db-a0962d8dc417@github.com>

On Wed, 5 Mar 2025 16:15:55 GMT, Alan Bateman  wrote:

> > Should we remove these JMH tests, or just fix the test bug and make tests run normally
> 
> I think that would be best as they are left over from early development.

The related test files has been removed in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23437#issuecomment-2702656385

From almatvee at openjdk.org  Thu Mar  6 03:16:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Mar 2025 03:16:52 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 21:13:44 GMT, Alexey Semenyuk  wrote:

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" will ...

Looks good overall with minor comment and question.

src/jdk.jpackage/share/native/applauncher/StringProcessing.cpp line 129:

> 127:         if (it->type() == ESCAPED_CHAR) {
> 128:             ss << it->value().substr(1);
> 129:         }

`} else {` in one line for consistency.

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

PR Review: https://git.openjdk.org/jdk/pull/23923#pullrequestreview-2663204935
PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r1982616871

From syan at openjdk.org  Thu Mar  6 03:55:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 03:55:25 GMT
Subject: RFR: 8351233: [ASAN] avx2-emu-funcs.hpp:151:20: error:
 =?UTF-8?B?4oCYRC44MjE4OOKAmQ==?= is used uninitialized
Message-ID: 

Hi all,

The return type of function `const __m256i &perm` is `__m256i`, so `const __m256i &perm` should be replaced as 'const __m256i perm'.

The function implementation in gcc/clang compiler header:

1. gcc: lib/gcc/x86_64-pc-linux-gnu/14.2.0/include/avxintrin.h


extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__, __artificial__))
_mm256_loadu_si256 (__m256i_u const *__P)
{
  return *__P;
}


2. clang: lib64/clang/17/include/avxintrin.h


static __inline __m256i __DEFAULT_FN_ATTRS
_mm256_loadu_si256(__m256i_u const *__p)
{
  struct __loadu_si256 {
    __m256i_u __v;
  } __attribute__((__packed__, __may_alias__));
  return ((const struct __loadu_si256*)__p)->__v;
}


Additional testing:

- [ ] jtreg tests(include tier1/2/3 etc.) on linux-x64(AMD EPYC 9T24 96-Core Processor) with release build
- [ ] jtreg tests(include tier1/2/3 etc.) on linux-x64(AMD EPYC 9T24 96-Core Processor) with fastdebug build

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

Commit messages:
 - 8351233: [ASAN] avx2-emu-funcs.hpp:151:20: error: ?D.82188? is used uninitialized

Changes: https://git.openjdk.org/jdk/pull/23925/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23925&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351233
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23925/head:pull/23925

PR: https://git.openjdk.org/jdk/pull/23925

From syan at openjdk.org  Thu Mar  6 03:55:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 03:55:25 GMT
Subject: RFR: 8351233: [ASAN] avx2-emu-funcs.hpp:151:20: error:
 =?UTF-8?B?4oCYRC44MjE4OOKAmQ==?= is used uninitialized
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan  wrote:

> Hi all,
> 
> The return type of function `const __m256i &perm` is `__m256i`, so `const __m256i &perm` should be replaced as 'const __m256i perm'.
> 
> The function implementation in gcc/clang compiler header:
> 
> 1. gcc: lib/gcc/x86_64-pc-linux-gnu/14.2.0/include/avxintrin.h
> 
> 
> extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__, __artificial__))
> _mm256_loadu_si256 (__m256i_u const *__P)
> {
>   return *__P;
> }
> 
> 
> 2. clang: lib64/clang/17/include/avxintrin.h
> 
> 
> static __inline __m256i __DEFAULT_FN_ATTRS
> _mm256_loadu_si256(__m256i_u const *__p)
> {
>   struct __loadu_si256 {
>     __m256i_u __v;
>   } __attribute__((__packed__, __may_alias__));
>   return ((const struct __loadu_si256*)__p)->__v;
> }
> 
> 
> Additional testing:
> 
> - [ ] jtreg tests(include tier1/2/3 etc.) on linux-x64(AMD EPYC 9T24 96-Core Processor) with release build
> - [ ] jtreg tests(include tier1/2/3 etc.) on linux-x64(AMD EPYC 9T24 96-Core Processor) with fastdebug build

@vamsi-parasa Could you take look this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/23925#issuecomment-2702711575

From hannesw at openjdk.org  Thu Mar  6 05:18:26 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 05:18:26 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Remove script for normalizing leading space in pre/code based on review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23868/files
  - new: https://git.openjdk.org/jdk/pull/23868/files/13638f80..d2128b3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23868/head:pull/23868

PR: https://git.openjdk.org/jdk/pull/23868

From hannesw at openjdk.org  Thu Mar  6 05:31:52 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 05:31:52 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 05:18:26 GMT, Hannes Walln?fer  wrote:

>> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
>> 
>> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
>> 
>> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
>> 
>> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
>> 
>> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
>> 
>> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove script for normalizing leading space in pre/code based on review feedback

I removed the script to strip leading whitespace based on your feedback. 

Regarding the added complexity this patch adds to `DocCommentParser` (which I dislike as you do): I think we could reconsider exclusion of multiline inline content. The test examples I came up with are very contrived (multiline `title` attribute and `{@index}` tag inside `
`, both of which would not mind removal of redundant space after line breaks). I initially tried using a `{@snippet}` tag inside `
` which is also completely unrealistic, but `{@snippet}` is not even affected as it does its own parsing.

Without that exclusion, the patch is mostly just two simple methods, and all the added complexity to `content` and other existing methods is gone.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2702853308

From jpai at openjdk.org  Thu Mar  6 06:27:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 06:27:00 GMT
Subject: RFR: 8204868: java/util/zip/ZipFile/TestCleaner.java still fails
 with "cleaner failed to clean zipfile."
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Feb 2025 05:50:40 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this test-only change which proposes to address an intermittent failure in the `test/jdk/java/util/zip/ZipFile/TestCleaner.java` test?
> 
> This test does operations on Inflater/Deflater/ZipFile and  closes those instances and then waits for GC to kick in. After wait for a second, it then checks that the underlying resources held by these instances have been cleaned (by the Cleaner).
> 
> Once in a while, we have noticed that this test fails because the resources haven't been cleaned. I suspect this is because within the (fixed) 1 second wait time, the Cleaner hasn't yet invoked the cleaning action for these instances.
> 
> The commit in this PR updates the test to run it in `othervm` so that the Cleaner actions aren't delayed by any other test or code that might have previously run on the `agentvm`. Furthermore, the test is also updated to the use the `ForceGC` test util which takes into account the jtreg test timeout factor for deciding how long to wait for the Cleaner to initiate the cleaning action. Our CI is configured with a timeout factor of 4, so with this change, instead of a fixed maximum 1 second wait time, the test will now wait a maximum of 4 seconds for the cleaner action to be invoked.
> 
> The test continues to pass with this change, even with a repeat execution of 50 runs.

Thank you Lance for the review. I'll go ahead and integrate this now. For any new utility method, if it gets introduced in the Cleaner, like Brent notes we can rework the implementation of this test util at that time.

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

PR Comment: https://git.openjdk.org/jdk/pull/23742#issuecomment-2702919883

From jpai at openjdk.org  Thu Mar  6 06:27:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 06:27:01 GMT
Subject: Integrated: 8204868: java/util/zip/ZipFile/TestCleaner.java still
 fails with "cleaner failed to clean zipfile."
In-Reply-To: 
References: 
Message-ID: <5RwAeyDfgn5w5oF1zAG3BM5otAV5xxf8naUeRWKBqQU=.11bf8524-5de4-404b-91a1-f2507c3ac2b7@github.com>

On Mon, 24 Feb 2025 05:50:40 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this test-only change which proposes to address an intermittent failure in the `test/jdk/java/util/zip/ZipFile/TestCleaner.java` test?
> 
> This test does operations on Inflater/Deflater/ZipFile and  closes those instances and then waits for GC to kick in. After wait for a second, it then checks that the underlying resources held by these instances have been cleaned (by the Cleaner).
> 
> Once in a while, we have noticed that this test fails because the resources haven't been cleaned. I suspect this is because within the (fixed) 1 second wait time, the Cleaner hasn't yet invoked the cleaning action for these instances.
> 
> The commit in this PR updates the test to run it in `othervm` so that the Cleaner actions aren't delayed by any other test or code that might have previously run on the `agentvm`. Furthermore, the test is also updated to the use the `ForceGC` test util which takes into account the jtreg test timeout factor for deciding how long to wait for the Cleaner to initiate the cleaning action. Our CI is configured with a timeout factor of 4, so with this change, instead of a fixed maximum 1 second wait time, the test will now wait a maximum of 4 seconds for the cleaner action to be invoked.
> 
> The test continues to pass with this change, even with a repeat execution of 50 runs.

This pull request has now been integrated.

Changeset: 3626ac35
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/3626ac35b34650dc64938af63ea21f9f4e011fe4
Stats:     44 lines in 1 file changed: 21 ins; 11 del; 12 mod

8204868: java/util/zip/ZipFile/TestCleaner.java still fails with "cleaner failed to clean zipfile."

Reviewed-by: lancea

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

PR: https://git.openjdk.org/jdk/pull/23742

From syan at openjdk.org  Thu Mar  6 07:04:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 07:04:04 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope
In-Reply-To: 
References: 
 
 
Message-ID: <-TpusZpdtTI165IPRGbIW8mfHG2AEsu-9JWm452AF1I=.60096df1-7b62-4621-92e2-4cf45b29dfd7@github.com>

On Wed, 5 Mar 2025 16:15:55 GMT, Alan Bateman  wrote:

>> Should we remove these JMH tests, or just fix the test bug and make tests run normally
>
>> Should we remove these JMH tests, or just fix the test bug and make tests run normally
> 
> I think that would be best as they are left over from early development.

Thanks @AlanBateman

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

PR Comment: https://git.openjdk.org/jdk/pull/23437#issuecomment-2702984016

From alanb at openjdk.org  Thu Mar  6 07:04:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Mar 2025 07:04:03 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope [v2]
In-Reply-To: <1uabYpqku5peFfFSEtLItA_Fy8BSsAiTeDPhObGvYN8=.369bd032-3be2-4d52-b006-b1474c25a474@github.com>
References: 
 <1uabYpqku5peFfFSEtLItA_Fy8BSsAiTeDPhObGvYN8=.369bd032-3be2-4d52-b006-b1474c25a474@github.com>
Message-ID: 

On Thu, 6 Mar 2025 02:56:34 GMT, SendaoYan  wrote:

>> Hi all,
>> 
>> Several JMH tests fails "cannot access class jdk.internal.vm.ContinuationScope (in module java.base) because module java.base does not export jdk.internal.vm to unnamed module". This PR add VM option `--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to fix the JMH test bug.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove test/micro/org/openjdk/bench/loom/obsolete/FreezeAndThaw.java test/micro/org/openjdk/bench/loom/obsolete/OneShot.java test/micro/org/openjdk/bench/loom/obsolete/Oscillation.java

Okay

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23437#pullrequestreview-2663509747

From syan at openjdk.org  Thu Mar  6 07:04:05 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Mar 2025 07:04:05 GMT
Subject: Integrated: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 Feb 2025 12:35:50 GMT, SendaoYan  wrote:

> Hi all,
> 
> Several JMH tests fails "cannot access class jdk.internal.vm.ContinuationScope (in module java.base) because module java.base does not export jdk.internal.vm to unnamed module". This PR add VM option `--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to fix the JMH test bug.
> 
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 5c552a9d
Author:    SendaoYan 
URL:       https://git.openjdk.org/jdk/commit/5c552a9d64c8116161cb9ef4c777e75a2602a75b
Stats:     505 lines in 3 files changed: 0 ins; 505 del; 0 mod

8349358: [JMH] Cannot access class jdk.internal.vm.ContinuationScope

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/23437

From michaelm at openjdk.org  Thu Mar  6 10:28:20 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 10:28:20 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
Message-ID: 

Hi,

Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
addresses from exception message strings, unless the enhanced mode for the specific category 
has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
updated in 8207846.

This PR aims to increase the coverage of enhanced exception messages in the networking code.
A limited number of exceptions are already hidden (restricted) by default. The new categories and 
exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
(while preserving the existing behavior).

The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
a comma separated list of category names, which identify groups of exceptions where the exception
message may be enhanced. Any category not listed is "restricted" which means that potentially
sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.

The changes to the java.security conf file describe the exact changes in terms of the categories now
supported and any changes in behavior.

Thanks,
Michael

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

Commit messages:
 - remove file added by mistake
 - whitespace
 - moved test
 - Merge branch 'master' into 8348986-exceptions
 - update
 - update
 - Merge branch 'master' into 8348986-exceptions
 - update
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - ... and 3 more: https://git.openjdk.org/jdk/compare/b1a21b56...c4419860

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348986
  Stats: 1002 lines in 42 files changed: 762 ins; 104 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From duke at openjdk.org  Thu Mar  6 10:45:04 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 10:45:04 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
Message-ID: 

Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.

This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.

Sponsored by: The FreeBSD Foundation
Co-authored-by: Greg Lewis 

[1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

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

Commit messages:
 - 8351322: Parameterize link option for pthreads

Changes: https://git.openjdk.org/jdk/pull/23930/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23930&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351322
  Stats: 661 lines in 10 files changed: 9 ins; 0 del; 652 mod
  Patch: https://git.openjdk.org/jdk/pull/23930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23930/head:pull/23930

PR: https://git.openjdk.org/jdk/pull/23930

From michaelm at openjdk.org  Thu Mar  6 10:46:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 10:46:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  doc + copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/c4419860..074da251

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=00-01

  Stats: 23 lines in 3 files changed: 10 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From liach at openjdk.org  Thu Mar  6 11:57:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Mar 2025 11:57:07 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov  wrote:

> We have helpful NPE messages now - they are more user-friendly.
> And shorter methods are more likely to be inlined.

Looks nice to me, thanks!

src/java.base/share/classes/java/lang/String.java line 3650:

> 3648:         var delim = delimiter.toString();
> 3649:         var elems = new String[8];
> 3650:         int size = 0;

Can you add a `// implicit null check` before the loop? Otherwise, the null check may be forgotten that future code change may early return before the null check here is triggered.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23710#pullrequestreview-2638571708
PR Review Comment: https://git.openjdk.org/jdk/pull/23710#discussion_r1964153031

From aturbanov at openjdk.org  Thu Mar  6 11:57:07 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Mar 2025 11:57:07 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
Message-ID: 

We have helpful NPE messages now - they are more user-friendly.
And shorter methods are more likely to be inlined.

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

Commit messages:
 - [PATCH] Avoid explicit Objects.requireNonNull where we know implicit NPE will happen
 - [PATCH] Avoid explicit Objects.requireNonNull where we know implicit NPE will happen

Changes: https://git.openjdk.org/jdk/pull/23710/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23710&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351344
  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23710/head:pull/23710

PR: https://git.openjdk.org/jdk/pull/23710

From aturbanov at openjdk.org  Thu Mar  6 12:05:59 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Mar 2025 12:05:59 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 10:46:11 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc + copyright update

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 103:

> 101:      * the output is the replacement string.
> 102:      */
> 103:     public static abstract class SensitiveInfo  {

Let's sort modifiers in blessed order
Suggestion:

    public abstract static class SensitiveInfo {

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 338:

> 336:                                       | hostCompatFlag;
> 337:         enhancedUserExceptionText = SecurityProperties.includedInExceptions("userInfo");
> 338:         enhancedJarExceptionText =  SecurityProperties.INCLUDE_JAR_NAME_IN_EXCEPTIONS;

Suggestion:

        enhancedJarExceptionText = SecurityProperties.INCLUDE_JAR_NAME_IN_EXCEPTIONS;

test/jdk/sun/net/util/ExceptionsTest.java line 47:

> 45: 
> 46:     static boolean netEnabled() {
> 47:         System.out.printf("netEnabled = %b\n",  enhancedNetExceptions());

Suggestion:

        System.out.printf("netEnabled = %b\n", enhancedNetExceptions());

test/jdk/sun/net/util/ExceptionsTest.java line 52:

> 50: 
> 51:     static boolean dnsEnabled() {
> 52:         System.out.printf("dnsEnabled = %b\n",  enhancedLookupExceptions());

Suggestion:

        System.out.printf("dnsEnabled = %b\n", enhancedLookupExceptions());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983229570
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232405
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232786
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232968

From aturbanov at openjdk.org  Thu Mar  6 12:12:53 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Mar 2025 12:12:53 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 21:13:44 GMT, Alexey Semenyuk  wrote:

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" will ...

src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java line 112:

> 110:         regexps = new ArrayList<>();
> 111: 
> 112:         for(;;) {

Suggestion:

        for (;;) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r1983241792

From asemenyuk at openjdk.org  Thu Mar  6 12:29:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Mar 2025 12:29:55 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 12:10:01 GMT, Andrey Turbanov  wrote:

>> jpackage app laucnher will expand environment variables in .cfg files.
>> 
>> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
>> | String    | Variables | Variable Values | Expanded string | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
>> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
>> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
>> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
>> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
>> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
>> 
>> `$` character combination prevents variable expansion:
>> | String    | Variables | Variable Values | Expanded string |
>> | -------- | ------- |------- |------- |
>> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
>> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
>> 
>> `\` character combination escapes ``:
>> | String    | Variables | Variable Values | Expanded string |
>> | -------- | ------- |------- |------- |
>> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
>> 
>> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
>> | String    | Expanded string |
>> | -------- | ------- |
>> |
a\\b\\c
|
a\\b\\c
|
>> 
>> 
>> Expansion is non-recursive:
>> | String    | Variables | Variable Values | Expanded string | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Hello $A!
  | A | 
A=$B...
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java line 112:
> 
>> 110:         regexps = new ArrayList<>();
>> 111: 
>> 112:         for(;;) {
> 
> Suggestion:
> 
>         for (;;) {

> If you do echo on macOS in terminal for unset variable it will be expanded to empty string, so for "Unset variables are not expanded." should we have Welcome ! instead of Welcome $USER!?

This is true for any shell behavior. It is also true that some shells fail to expand undefined variables if configured accordingly. Bash. for example:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r1983266187

From michaelm at openjdk.org  Thu Mar  6 12:32:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 12:32:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v3]
In-Reply-To: 
References: 
Message-ID: <9L8DA7kJW6gXoCrbx4Gkn7hGk_3h8FmARRPHqzbHNs8=.6dc91725-b519-45c4-aa20-618df1155a91@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  from turbanoff review
  
  Co-authored-by: Andrey Turbanov 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/074da251..41d1ef82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From jpai at openjdk.org  Thu Mar  6 12:41:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 12:41:00 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov  wrote:

> We have helpful NPE messages now - they are more user-friendly.
> And shorter methods are more likely to be inlined.

src/java.base/share/classes/java/lang/String.java line 3649:

> 3647:             Iterable elements) {
> 3648:         Objects.requireNonNull(delimiter);
> 3649:         Objects.requireNonNull(elements);

Hello Andrey, I have a different opinion about this. I think removing existing calls to `Objects.requireNonNull()` in favour of implicit null check (some times too far away in the code) isn't useful. 

You noted that the implicit `NullPointerException` stacktrace are more user friendly now. I think you can get similar level of useful information from `Objects.requireNonNull()` too. In these two specific cases, what you could perhaps do is change those calls to even pass the `message` so that it's clear what parameter is `null`. Something like:

    Objects.requireNonNull(delimiter, "delimiter");
    Objects.requireNonNull(elements, "elements");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23710#discussion_r1983281966

From dholmes at openjdk.org  Thu Mar  6 12:49:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 12:49:02 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 10:39:27 GMT, snake66  wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis 
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

Needs build team approval before integrating.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664340896

From duke at openjdk.org  Thu Mar  6 13:29:55 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 13:29:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 12:46:25 GMT, David Holmes  wrote:

> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2703853406

From duke at openjdk.org  Thu Mar  6 13:55:53 2025
From: duke at openjdk.org (Antonio Vieiro)
Date: Thu, 6 Mar 2025 13:55:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 10:39:27 GMT, snake66  wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis 
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/test/JtregNativeHotspot.gmk line 886:

> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
> 885: else
> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)

Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
Could be me too, I need new reading glasses...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983396617

From galder at openjdk.org  Thu Mar  6 14:06:35 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 6 Mar 2025 14:06:35 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v13]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: 

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:

  Add simple reduction benchmarks on top of multiply ones

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/a190ae68..d0e793a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=11-12

  Stats: 44 lines in 1 file changed: 40 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From erikj at openjdk.org  Thu Mar  6 14:23:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Mar 2025 14:23:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 10:39:27 GMT, snake66  wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis 
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?

make/autoconf/libraries.m4 line 142:

> 140:   # Threading library
> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"

If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.

Suggestion:

    BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

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

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664582520
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983435650

From alanb at openjdk.org  Thu Mar  6 14:36:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Mar 2025 14:36:57 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v6]
In-Reply-To: <60IBeWm3452rLJC_2GQEdhY0I_vY0D7UKXCLgxkw5eM=.f728b6a3-bca0-4c4d-bb89-e69626d833db@github.com>
References: 
 
 
 <60IBeWm3452rLJC_2GQEdhY0I_vY0D7UKXCLgxkw5eM=.f728b6a3-bca0-4c4d-bb89-e69626d833db@github.com>
Message-ID: 

On Wed, 5 Mar 2025 23:55:52 GMT, Sunmisc Unsafe  wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3741:
>> 
>>> 3739:     public  ForkJoinTask submitWithTimeout(Callable callable,
>>> 3740:                                                  long timeout, TimeUnit unit,
>>> 3741:                                                  Consumer> timeoutAction) {
>> 
>> I wonder if the variance of the Consumer to this method should be more permissible. Something like:
>> 
>> public  ForkJoinTask submitWithTimeout(Callable callable,
>>                                                  long timeout, TimeUnit unit,
>>                                                  Consumer> timeoutAction) {
>
> Maybe it's worth using java.time.Duration, although it doesn't fit into the API very elegantly.

> I wonder if the variance of the Consumer to this method should be more permissible. Something like:
> 
> public ForkJoinTask submitWithTimeout(Callable callable, long timeout, TimeUnit unit, Consumer> timeoutAction) {

I think this is a good point but it might be more practical to limit it to just a contravariant Consumer, as in ` Consumer>`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1983469247

From asemenyuk at openjdk.org  Thu Mar  6 14:59:23 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Mar 2025 14:59:23 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v2]
In-Reply-To: 
References: 
Message-ID: 

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" will ...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java
  
  Co-authored-by: Andrey Turbanov 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23923/files
  - new: https://git.openjdk.org/jdk/pull/23923/files/32f2b529..e5d248a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923

PR: https://git.openjdk.org/jdk/pull/23923

From epeter at openjdk.org  Thu Mar  6 15:07:07 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 6 Mar 2025 15:07:07 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: 
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 
 
Message-ID: 

On Thu, 27 Feb 2025 16:38:30 GMT, Galder Zamarre?o  wrote:

>> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into topic.intrinsify-max-min-long
>>  - Fix typo
>>  - Renaming methods and variables and add docu on algorithms
>>  - Fix copyright years
>>  - Make sure it runs with cpus with either avx512 or asimd
>>  - Test can only run with 256 bit registers or bigger
>>    
>>    * Remove platform dependant check
>>    and use platform independent configuration instead.
>>  - Fix license header
>>  - Tests should also run on aarch64 asimd=true envs
>>  - Added comment around the assertions
>>  - Adjust min/max identity IR test expectations after changes
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/47fdb836...a190ae68
>
> Also, I've started a [discussion on jmh-dev](https://mail.openjdk.org/pipermail/jmh-dev/2025-February/004094.html) to see if there's a way to minimise pollution of `Math.min(II)` compilation. As a follow to https://github.com/openjdk/jdk/pull/20098#issuecomment-2684701935 I looked at where the other `Math.min(II)` calls are coming from, and a big chunk seem related to the JMH infrastructure.

@galderz about:
> Additional performance improvement: make SuperWord recognize more cases as profitble (see Regression 1). Optional.

This should already be covered by these, and I will handle that eventually with the Cost-Model RFE [JDK-8340093](https://bugs.openjdk.org/browse/JDK-8340093):
- [JDK-8345044](https://bugs.openjdk.org/browse/JDK-8345044) Sum of array elements not vectorized
  - (min/max of array)
- [JDK-8336000](https://bugs.openjdk.org/browse/JDK-8336000) C2 SuperWord: report that 2-element reductions do not vectorize
  - You would for example see that on aarch64 machines with only neon/asimd support you can have at most 2 longs per vector, because the max vector length is 128 bits.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2704110051

From asemenyuk at openjdk.org  Thu Mar  6 15:25:13 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Mar 2025 15:25:13 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v3]
In-Reply-To: 
References: 
Message-ID: 

> jpackage app laucnher will expand environment variables in .cfg files.
> 
> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
> 
> `$` character combination prevents variable expansion:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
> 
> `\` character combination escapes ``:
> | String    | Variables | Variable Values | Expanded string |
> | -------- | ------- |------- |------- |
> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
> 
> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
> | String    | Expanded string |
> | -------- | ------- |
> |
a\\b\\c
|
a\\b\\c
|
> 
> 
> Expansion is non-recursive:
> | String    | Variables | Variable Values | Expanded string | Note |
> | -------- | ------- |------- |------- |------- |
> | 
Hello $A!
  | A | 
A=$B
B=John
 | 
Hello $B
 | Variable "B" will ...

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8341641-master' of https://github.com/alexeysemenyukoracle/jdk into JDK-8341641-master
 - Formatting fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23923/files
  - new: https://git.openjdk.org/jdk/pull/23923/files/e5d248a1..05cbac43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23923&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23923/head:pull/23923

PR: https://git.openjdk.org/jdk/pull/23923

From epeter at openjdk.org  Thu Mar  6 15:26:09 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 6 Mar 2025 15:26:09 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: 
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 
 
Message-ID: 

On Thu, 27 Feb 2025 16:38:30 GMT, Galder Zamarre?o  wrote:

>> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into topic.intrinsify-max-min-long
>>  - Fix typo
>>  - Renaming methods and variables and add docu on algorithms
>>  - Fix copyright years
>>  - Make sure it runs with cpus with either avx512 or asimd
>>  - Test can only run with 256 bit registers or bigger
>>    
>>    * Remove platform dependant check
>>    and use platform independent configuration instead.
>>  - Fix license header
>>  - Tests should also run on aarch64 asimd=true envs
>>  - Added comment around the assertions
>>  - Adjust min/max identity IR test expectations after changes
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/dfbb2ee6...a190ae68
>
> Also, I've started a [discussion on jmh-dev](https://mail.openjdk.org/pipermail/jmh-dev/2025-February/004094.html) to see if there's a way to minimise pollution of `Math.min(II)` compilation. As a follow to https://github.com/openjdk/jdk/pull/20098#issuecomment-2684701935 I looked at where the other `Math.min(II)` calls are coming from, and a big chunk seem related to the JMH infrastructure.

@galderz about:
> Additional performance improvement: extend backend capabilities for vectorization (see Regression 2 + 3). Optional.

I looked at `src/hotspot/cpu/x86/x86.ad`
bool Matcher::match_rule_supported_vector(int opcode, int vlen, BasicType bt) {

   1774     case Op_MaxV:                                                                                                                                                                                                             
   1775     case Op_MinV:
   1776       if (UseSSE < 4 && is_integral_type(bt)) {
   1777         return false;
   1778       }
...

So it seems that here lanewise min/max are supported for AVX2. But it seems that's different for reductions:

   1818     case Op_MinReductionV:
   1819     case Op_MaxReductionV:                                                                                                                                                                                                    
   1820       if ((bt == T_INT || is_subword_type(bt)) && UseSSE < 4) {
   1821         return false;
   1822       } else if (bt == T_LONG && (UseAVX < 3 || !VM_Version::supports_avx512vlbwdq())) {
   1823         return false;
   1824       }
...

So it seems maybe we could improve the AVX2 coverage for reductions. But honestly, I will probably find this issue again once I work on the other reductions above, and run the benchmarks. I think that will make it easier to investigate all of this. I will for example adjust the IR rules, and then it will be apparent where there are cases that are not covered.

@galderz you said you would add some extra comments, then I will review again :)

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2704159992
PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2704161929

From tschatzl at openjdk.org  Thu Mar  6 15:39:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 6 Mar 2025 15:39:57 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v11]
In-Reply-To: 
References: 
 
 
Message-ID: <4um7PHAs89PIoa3QgbkPx-8Jx9vHiYr7afFQGOtFTY8=.f1ca8bad-0827-4f8c-852d-0fc82ffd546a@github.com>

On Tue, 4 Mar 2025 15:33:29 GMT, Albert Mingkun Yang  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   iwalulya review
>>     * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>>     * predicate for determining whether the refinement has been disabled
>>     * some other typos/comment improvements
>>     * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 219:
> 
>> 217:       // The young gen revising mechanism reads the predictor and the values set
>> 218:       // here. Avoid inconsistencies by locking.
>> 219:       MutexLocker x(G1RareEvent_lock, Mutex::_no_safepoint_check_flag);
> 
> Who else can be in this critical-section? I don't get what this lock is protecting us from.

Actually further discussion with @albertnetymk showed that this change introduces an unintended behaviorial change where since the refinement control thread is also responsible for updating the current young gen length.

It means that the mutex isn't required.

However this means that while the refinement is running this is not done any more, because refinement can take seconds, I need to move this work to another thread (probably the `G1ServiceThread?). I will add a separate mutex then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1983587293

From ihse at openjdk.org  Thu Mar  6 15:51:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:51:52 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 14:21:08 GMT, Erik Joelsson  wrote:

> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?

This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

Yes, this is incorrect. Remember that m4 are shell scripts so you need to use shell syntax here. (I know it is confusing).

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2704233217
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983608153

From ihse at openjdk.org  Thu Mar  6 15:58:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:58 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro  wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis 
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

You're absolutely right. 

@snake66 Making changes to makefiles is tricky, since a misspelled variable do not get any warning but is just silently ignored. 

For a change like this, that is a pure refactoring that is not supposed to change the output, I highly recommend using the `COMPARE_BUILD` system. Unfortunately, this is severely underdocumented. There is a short paragraph at https://openjdk.org/groups/build/doc/building.html under "Developing the Build System Itself", but in short, what I'd do is to create a diff files of these changes compared to a baseline (e.g. master, a specific build or commit), make sure you have the baseline checked out, and then run `make jdk-image test-image COMPARE_BUILD=PATCH=my_patch.diff`. This will build the targets twice, one without the patch and one with the patch, and then automatically run the `compare` script to analyze any differences. For this particular patch, there should be none. This would likely have caught this typo. (Given that the test-image is actually compared; I suddenly got a bit uncertain about that...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983618250

From ihse at openjdk.org  Thu Mar  6 15:58:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 10:39:27 GMT, snake66  wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis 
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/Hsdis.gmk line 131:

> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
> 131:   else

The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983621784

From tschatzl at openjdk.org  Thu Mar  6 16:13:02 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 6 Mar 2025 16:13:02 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v13]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 5 Mar 2025 10:41:02 GMT, Ivan Walulya  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * fix whitespace
>>   * additional whitespace between log tags
>>   * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename
>
> src/hotspot/share/gc/g1/g1ThreadLocalData.hpp line 29:
> 
>> 27: #include "gc/g1/g1BarrierSet.hpp"
>> 28: #include "gc/g1/g1CardTable.hpp"
>> 29: #include "gc/g1/g1CollectedHeap.hpp"
> 
> probably does not need to be included

`g1CardTable.hpp` needed because of `G1CardTable::CardValue` I think. I removed the 'G1CollectedHeap` include though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1983655594

From tschatzl at openjdk.org  Thu Mar  6 16:26:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 6 Mar 2025 16:26:31 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v14]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * iwalulya review
    * renaming
    * fix some includes, forward declaration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/a457e6e7..350a4fa3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=12-13

  Stats: 31 lines in 13 files changed: 1 ins; 2 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From jbhateja at openjdk.org  Thu Mar  6 16:37:52 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 6 Mar 2025 16:37:52 GMT
Subject: RFR: 8350909: [JMH] test ThreadOnSpinWaitShared failed for 2
 threads config
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Feb 2025 01:20:44 GMT, Vladimir Ivanov  wrote:

> The scope was updated to support multithread configuration (jmh option '-t 2') . No other changes needed.

LGTM.

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23834#pullrequestreview-2665031670

From hannesw at openjdk.org  Thu Mar  6 16:42:42 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 16:42:42 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Switch to post-processing approach that fixes both problems
  
  This implements a visitor-based post-processing method in
  DocCommentParser that is able to fix both kinds of whitespace
  common in traditional doc comments. Tests have to be adapted
  to the additional normalization step. A few more tests should
  be added on the javadoc side.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23868/files
  - new: https://git.openjdk.org/jdk/pull/23868/files/d2128b3a..8a9036d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=01-02

  Stats: 304 lines in 4 files changed: 200 ins; 63 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/23868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23868/head:pull/23868

PR: https://git.openjdk.org/jdk/pull/23868

From hannesw at openjdk.org  Thu Mar  6 16:54:13 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 6 Mar 2025 16:54:13 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23868/files
  - new: https://git.openjdk.org/jdk/pull/23868/files/8a9036d6..69464173

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23868&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23868/head:pull/23868

PR: https://git.openjdk.org/jdk/pull/23868

From duke at openjdk.org  Thu Mar  6 17:21:01 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:21:01 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
 
Message-ID: <1xDhCbB5y6lKeTsljSaXQIctUdhLeZYMZc3ttv3CCAY=.e32e38b6-8431-4fa9-9b49-8fb305a744aa@github.com>

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro  wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis 
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

@vieiro Thanks! That's well spotted, I'll fix!

@magicus Thanks for this info! I'll give it a try without fixing the typo first, to see if it would catch it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983764371

From duke at openjdk.org  Thu Mar  6 17:31:53 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 15:56:43 GMT, Magnus Ihse Bursie  wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis 
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/Hsdis.gmk line 131:
> 
>> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
>> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
>> 131:   else
> 
> The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

Ack, I'll drop that one from the patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983780437

From duke at openjdk.org  Thu Mar  6 17:31:54 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
 
Message-ID: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>

On Thu, 6 Mar 2025 14:15:38 GMT, Erik Joelsson  wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis 
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

@erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983779126

From vaivanov at openjdk.org  Thu Mar  6 17:47:53 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Mar 2025 17:47:53 GMT
Subject: RFR: 8350909: [JMH] test ThreadOnSpinWaitShared failed for 2
 threads config
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Feb 2025 01:20:44 GMT, Vladimir Ivanov  wrote:

> The scope was updated to support multithread configuration (jmh option '-t 2') . No other changes needed.

Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23834#issuecomment-2704538159

From duke at openjdk.org  Thu Mar  6 17:47:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Mar 2025 17:47:54 GMT
Subject: RFR: 8350909: [JMH] test ThreadOnSpinWaitShared failed for 2
 threads config
In-Reply-To: 
References: 
Message-ID: <0oO7qD9j2FBWk6OlRjFYYWh_MirjOVo9yw0s2s-8FwQ=.2a95af07-967d-4dfc-931c-26ab6547db17@github.com>

On Fri, 28 Feb 2025 01:20:44 GMT, Vladimir Ivanov  wrote:

> The scope was updated to support multithread configuration (jmh option '-t 2') . No other changes needed.

@IvaVladimir 
Your change (at version 2b70cd408597bbfd0a2f490714a7ebab8eceb1f6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23834#issuecomment-2704539712

From ihse at openjdk.org  Thu Mar  6 18:24:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 18:24:05 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
References: 
 
 <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
Message-ID: <8oD1j-gxmzv2_5BOV5GohhkiKcuTDqxAC-3mnF8i-3o=.f2d870af-a508-4b53-95ac-d886fdc21b09@github.com>

On Thu, 6 Mar 2025 17:28:10 GMT, snake66  wrote:

>> make/autoconf/libraries.m4 line 142:
>> 
>>> 140:   # Threading library
>>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
>> 
>> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
>> 
>> Suggestion:
>> 
>>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"
>
> @erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

I'm not sure what you mean now. The link is to this very patch, which does what you describe -- sets LIBPTHREAD according to OS and stores it in spec.gmk.

And no, the paranthesis should not stay. If you keep them, the variable will be re-evaluated in make every time BASIC_JVM_LIBS is evaluated. That is not needed; by dropping the parenthesis the actual value to be used will be inserted as a string constant. Which is what we want, since we know the value at configure time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983853576

From rgiulietti at openjdk.org  Thu Mar  6 19:16:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Mar 2025 19:16:01 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov  wrote:

> We have helpful NPE messages now - they are more user-friendly.
> And shorter methods are more likely to be inlined.

I second @jaikiran in that the `Objects.requireNonNull()` are there to clearly validate the arguments right at method entry.

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

PR Comment: https://git.openjdk.org/jdk/pull/23710#issuecomment-2704726863

From asemenyuk at openjdk.org  Thu Mar  6 19:19:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Mar 2025 19:19:59 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 15:25:13 GMT, Alexey Semenyuk  wrote:

>> jpackage app laucnher will expand environment variables in .cfg files.
>> 
>> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and `$ROOTDIR` tokens with the corresponding path values. With this patch, any environment variable can be expanded. The syntax is shell-like `$ENV_VAR_NAME` or `${ENV_VAR_NAME}`. If `$ENV_VAR_NAME` syntax is used, the variable name stops at the first character outside of `[a-zA-Z0-9_]` character range. If `${ENV_VAR_NAME}` syntax is used, the variable name stops at the first `}` character after `${` substring. E.g:
>> | String    | Variables | Variable Values | Expanded string | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Welcome $USER!
  | 
USER
 | 
USER=John
 | 
Welcome John!
 ||
>> | 
Welcome $USER!
  | 
USER
 | 
not set
 | 
Welcome $USER!
 | Unset variables are not expanded. |
>> | 
Welcome $USER2
 | 
USER2
   | 
USER2=John
 | 
Welcome John!
 ||
>> | 
Welcome ${USER}2
 | 
USER
  | 
USER=John
 | 
Welcome John2!
 ||
>> | 
Welcome $USER-2
 | 
USER
   | 
USER=John
 | 
Welcome John-2!
 ||
>> | 
Welcome ${USER-2}
 | 
USER-2
   | 
USER-2=John
 | 
Welcome John!
 | `USER-2` is likely to be an invalid env variable name, but jpackage launcher is not validating names. |
>> 
>> `$` character combination prevents variable expansion:
>> | String    | Variables | Variable Values | Expanded string |
>> | -------- | ------- |------- |------- |
>> | 
Hello \$A! Bye $B
  | B | 
B=John
 | 
Hello $A! Bye John
 |
>> | 
Hello \${A}! Bye $B
  | B | 
B=John
 | 
Hello ${A}! Bye John
 |
>> 
>> `\` character combination escapes ``:
>> | String    | Variables | Variable Values | Expanded string |
>> | -------- | ------- |------- |------- |
>> | 
Hello \\\$A! Bye $B
  | A, B | 
A=Ana
B=John
 | 
Hello \\Ana! Bye John
 |
>> 
>> If `` character is not followed by another `` character or `$` character, it is interpreted as a regular character:
>> | String    | Expanded string |
>> | -------- | ------- |
>> |
a\\b\\c
|
a\\b\\c
|
>> 
>> 
>> Expansion is non-recursive:
>> | String    | Variables | Variable Values | Expanded string | Note |
>> | -------- | ------- |------- |------- |------- |
>> | 
Hello $A!
  | A | 
A=$B...
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8341641-master' of https://github.com/alexeysemenyukoracle/jdk into JDK-8341641-master
>  - Formatting fixed

This is true for any shell behavior. It is also true that some shells fail to expand undefined variables if configured accordingly. Bash, for example:

bash -c 'FOO=10; echo FOO=$FOO; unset FOO; set -u; echo FOO=$FOO'

Output:

FOO=10
bash: line 1: FOO: unbound variable


.cfg files are not scripts and jpackage app launcher is not an interpreter. Performed string substitution is less variable expansion and more token replacement; if token value is not available, it is not replaced.
Regardless of handling undefined variables, users have to deal with the consequences. Say they pass `--java-options -DmyAppData=$HOME/.myData` option to jackage and `HOME` variable happens undefined on a machine where installed app is launched. How would `/.myData` be better than `$HOME/.myData`? At least it is clear something went wrong in the second case.

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

PR Comment: https://git.openjdk.org/jdk/pull/23923#issuecomment-2704734396

From ecaspole at openjdk.org  Thu Mar  6 19:51:46 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 6 Mar 2025 19:51:46 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea [v2]
In-Reply-To: 
References: 
Message-ID: 

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Fix header and remove unused Blackhole

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23917/files
  - new: https://git.openjdk.org/jdk/pull/23917/files/8c882666..649957dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23917&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23917&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23917/head:pull/23917

PR: https://git.openjdk.org/jdk/pull/23917

From ecaspole at openjdk.org  Thu Mar  6 19:51:47 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 6 Mar 2025 19:51:47 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 5 Mar 2025 16:40:55 GMT, Chen Liang  wrote:

>> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.
>
> Also might need to add an 2025 copyright header for this file.

Thanks @liach I removed the unused Blackhole and updated the copyright header.

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

PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2704796397

From duke at openjdk.org  Thu Mar  6 19:55:07 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Mar 2025 19:55:07 GMT
Subject: Withdrawn: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Dec 2024 16:30:47 GMT, Quan Anh Mai  wrote:

> Hi,
> 
> This patch improves the performance of a typical `Arena::allocate` in several ways:
> 
> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
> - Split the allocation of over-aligned memory to a slow-path method.
> - Align the memory to 8 bytes, allowing faster zeroing.
> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/22610

From aturbanov at openjdk.org  Thu Mar  6 20:05:19 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Mar 2025 20:05:19 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 12:38:01 GMT, Jaikiran Pai  wrote:

>> We have helpful NPE messages now - they are more user-friendly.
>> And shorter methods are more likely to be inlined.
>
> src/java.base/share/classes/java/lang/String.java line 3649:
> 
>> 3647:             Iterable elements) {
>> 3648:         Objects.requireNonNull(delimiter);
>> 3649:         Objects.requireNonNull(elements);
> 
> Hello Andrey, I have a different opinion about this. I think removing existing calls to `Objects.requireNonNull()` in favour of implicit null check (some times too far away in the code) isn't useful. 
> 
> You noted that the implicit `NullPointerException` stacktrace are more user friendly now. I think you can get similar level of useful information from `Objects.requireNonNull()` too. In these two specific cases, what you could perhaps do is change those calls to even pass the `message` so that it's clear what parameter is `null`. Something like:
> 
>     Objects.requireNonNull(delimiter, "delimiter");
>     Objects.requireNonNull(elements, "elements");

Should we add it to other overloads of `join` then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23710#discussion_r1983977821

From aturbanov at openjdk.org  Thu Mar  6 20:10:10 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Mar 2025 20:10:10 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov  wrote:

> We have helpful NPE messages now - they are more user-friendly.
> And shorter methods are more likely to be inlined.

While having prerequirements checks often is good, I think not having it in String.join can be a good thing.
1. String.join is quite short method. 11 lines. And having 2 lines to have _excessive_ check don't improve reading experience much.
2. There are other overloads which don't have null check. I personally like them more - they are easier to read.
3. `String` is one of core classes, and having a bit shorter and more performant code will never be redundant in it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23710#issuecomment-2704832981

From rgiulietti at openjdk.org  Thu Mar  6 20:24:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Mar 2025 20:24:53 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov  wrote:

> We have helpful NPE messages now - they are more user-friendly.
> And shorter methods are more likely to be inlined.

At some point we will probably have [null-restricted types](https://openjdk.org/jeps/8303099).

Then it will be possible to annotate the parameters as null-restricted, and remove the _explicit_ validation checks, which enhances readability. But they will be replaced by language compiler generated checks, in some form or another.

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

PR Comment: https://git.openjdk.org/jdk/pull/23710#issuecomment-2704858514

From rriggs at openjdk.org  Thu Mar  6 20:39:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Mar 2025 20:39:58 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
Message-ID: 

On Thu, 20 Feb 2025 09:30:02 GMT, Andrey Turbanov  wrote:

> We have helpful NPE messages now - they are more user-friendly.
> And shorter methods are more likely to be inlined.

To confirm your intuition, please show the before/after performance differences if any.

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

PR Comment: https://git.openjdk.org/jdk/pull/23710#issuecomment-2704887884

From darcy at openjdk.org  Thu Mar  6 20:57:53 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Mar 2025 20:57:53 GMT
Subject: RFR: 8351344: Avoid explicit Objects.requireNonNull in String.join
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 6 Mar 2025 20:01:47 GMT, Andrey Turbanov  wrote:

>> src/java.base/share/classes/java/lang/String.java line 3649:
>> 
>>> 3647:             Iterable elements) {
>>> 3648:         Objects.requireNonNull(delimiter);
>>> 3649:         Objects.requireNonNull(elements);
>> 
>> Hello Andrey, I have a different opinion about this. I think removing existing calls to `Objects.requireNonNull()` in favour of implicit null check (some times too far away in the code) isn't useful. 
>> 
>> You noted that the implicit `NullPointerException` stacktrace are more user friendly now. I think you can get similar level of useful information from `Objects.requireNonNull()` too. In these two specific cases, what you could perhaps do is change those calls to even pass the `message` so that it's clear what parameter is `null`. Something like:
>> 
>>     Objects.requireNonNull(delimiter, "delimiter");
>>     Objects.requireNonNull(elements, "elements");
>
> Should we add it to other overloads of `join` then?

I agree that the easier to read explicit method calls to validate non-nullness should be left in place.

> Hello Andrey, I have a different opinion about this. I think removing existing calls to `Objects.requireNonNull()` in favour of implicit null check (some times too far away in the code) isn't useful.
> 
> You noted that the implicit `NullPointerException` stacktrace are more user friendly now. I think you can get similar level of useful information from `Objects.requireNonNull()` too. In these two specific cases, what you could perhaps do is change those calls to even pass the `message` so that it's clear what parameter is `null`. Something like:
> 
> ```java
>     Objects.requireNonNull(delimiter, "delimiter");
>     Objects.requireNonNull(elements, "elements");
> ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23710#discussion_r1984036994

From almatvee at openjdk.org  Thu Mar  6 21:53:56 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Mar 2025 21:53:56 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 6 Mar 2025 12:26:50 GMT, Alexey Semenyuk  wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java line 112:
>> 
>>> 110:         regexps = new ArrayList<>();
>>> 111: 
>>> 112:         for(;;) {
>> 
>> Suggestion:
>> 
>>         for (;;) {
>
>> If you do echo on macOS in terminal for unset variable it will be expanded to empty string, so for "Unset variables are not expanded." should we have Welcome ! instead of Welcome $USER!?
> 
> This is true for any shell. It is also true that some shells fail to expand undefined variables if configured accordingly. Bash, for example:
> 
> bash -c 'FOO=10; echo FOO=$FOO; unset FOO; set -u; echo FOO=$FOO'
> 
> 
> output:
> 
> FOO=10
> bash: line 1: FOO: unbound variable
> 
> 
> .cfg file is not a script, and the jpackage app launcher is not a shell. The substitution performed is less of a variable expansion and more a token replacement, and a token is not replaced if it doesn't have a value.
> 
> Regardless of the handling of undefined variables, users have to deal with the case of undefined variables in .cfg files. Imagine they pass `--java-options -DmyAppData=$HOME/.myData` to jpackage and `HOME` happens to be undefined on the machine where the app runs. Is `/.myData` any better than `$HOME/.myData`?

Agree. Makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r1984101788

From mcimadamore at openjdk.org  Thu Mar  6 22:07:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 6 Mar 2025 22:07:57 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 19:37:32 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

Thanks for fixing!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23873#pullrequestreview-2665741137

From asemenyuk at openjdk.org  Thu Mar  6 22:29:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Mar 2025 22:29:55 GMT
Subject: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables
 available in *.cfg files [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 6 Mar 2025 21:51:37 GMT, Alexander Matveev  wrote:

>>> If you do echo on macOS in terminal for unset variable it will be expanded to empty string, so for "Unset variables are not expanded." should we have Welcome ! instead of Welcome $USER!?
>> 
>> This is true for any shell. It is also true that some shells fail to expand undefined variables if configured accordingly. Bash, for example:
>> 
>> bash -c 'FOO=10; echo FOO=$FOO; unset FOO; set -u; echo FOO=$FOO'
>> 
>> 
>> output:
>> 
>> FOO=10
>> bash: line 1: FOO: unbound variable
>> 
>> 
>> .cfg file is not a script, and the jpackage app launcher is not a shell. The substitution performed is less of a variable expansion and more a token replacement, and a token is not replaced if it doesn't have a value.
>> 
>> Regardless of the handling of undefined variables, users have to deal with the case of undefined variables in .cfg files. Imagine they pass `--java-options -DmyAppData=$HOME/.myData` to jpackage and `HOME` happens to be undefined on the machine where the app runs. Is `/.myData` any better than `$HOME/.myData`?
>
> Agree. Makes sense.

Oh, I thought I posted my reply in the main thread and then didn't find it there, assumed my comment was lost and wrote it again ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r1984135948

From naoto at openjdk.org  Thu Mar  6 23:42:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Mar 2025 23:42:25 GMT
Subject: RFR: 8351017: ChronoUnit.MONTHS.between() not giving correct result
 when date is in February
Message-ID: 

Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/23937/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23937&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351017
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23937/head:pull/23937

PR: https://git.openjdk.org/jdk/pull/23937

From vaivanov at openjdk.org  Thu Mar  6 23:47:52 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Mar 2025 23:47:52 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 19:37:32 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23873#issuecomment-2705185511

From duke at openjdk.org  Thu Mar  6 23:47:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Mar 2025 23:47:52 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 19:37:32 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

@IvaVladimir 
Your change (at version 6920770118c6533c9e618bad1d6fb883dd6de3da) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23873#issuecomment-2705186362

From dholmes at openjdk.org  Fri Mar  7 00:20:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 00:20:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
 
 
Message-ID: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>

On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie  wrote:

>> What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?
>
>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
> 
> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

@magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2705227213

From dholmes at openjdk.org  Fri Mar  7 04:37:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 04:37:09 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev  wrote:

>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
>
>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
> 
> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.

@sercher  your new test is failing in our CI:

[STDOUT]
mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory

I will file a new bug

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2705506729

From jbhateja at openjdk.org  Fri Mar  7 06:08:00 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Mar 2025 06:08:00 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Mar 2025 19:37:32 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 57:

> 55: 
> 56:     SegmentAllocator segmentAllocator;
> 57:     SegmentAllocator arenaAllocator;

Please update the copyright of this and other modified files.

test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 60:

> 58:     SlicingPool pool;
> 59: 
> 60:     @Param({"5", "20", "100"})

Can you also add size 451 in this list as this is what was fixed :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1984488315
PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1984497674

From galder at openjdk.org  Fri Mar  7 06:19:04 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 7 Mar 2025 06:19:04 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: 
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 
 
 
Message-ID: 

On Thu, 6 Mar 2025 15:22:18 GMT, Emanuel Peter  wrote:

>> Also, I've started a [discussion on jmh-dev](https://mail.openjdk.org/pipermail/jmh-dev/2025-February/004094.html) to see if there's a way to minimise pollution of `Math.min(II)` compilation. As a follow to https://github.com/openjdk/jdk/pull/20098#issuecomment-2684701935 I looked at where the other `Math.min(II)` calls are coming from, and a big chunk seem related to the JMH infrastructure.
>
> @galderz you said you would add some extra comments, then I will review again :)

@eme64 I've added the comment that was pending from your last review. I've also merged latest master.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2705620662

From galder at openjdk.org  Fri Mar  7 06:19:03 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 7 Mar 2025 06:19:03 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v14]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:

 - Merge branch 'master' into topic.intrinsify-max-min-long
 - Add assertion comments
 - Add simple reduction benchmarks on top of multiply ones
 - Merge branch 'master' into topic.intrinsify-max-min-long
 - Fix typo
 - Renaming methods and variables and add docu on algorithms
 - Fix copyright years
 - Make sure it runs with cpus with either avx512 or asimd
 - Test can only run with 256 bit registers or bigger
   
   * Remove platform dependant check
   and use platform independent configuration instead.
 - Fix license header
 - ... and 37 more: https://git.openjdk.org/jdk/compare/a328e466...1aa690d3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/d0e793a3..1aa690d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=12-13

  Stats: 65249 lines in 2144 files changed: 33401 ins; 21691 del; 10157 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From galder at openjdk.org  Fri Mar  7 06:19:04 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 7 Mar 2025 06:19:04 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <9ReqLUCZ6XDaSQxgYw3NyZZdMv3SOHkCkzJ0DLAksas=.8cb29982-8cb8-4068-a251-59a189c83b93@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 
 
 <9ReqLUCZ6XDaSQxgYw3NyZZdMv3SOHkCkzJ0DLAksas=.8cb29982-8cb8-4068-a251-59a189c83b93@github.com>
Message-ID: 

On Tue, 17 Dec 2024 16:40:01 GMT, Galder Zamarre?o  wrote:

>> test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxInlining.java line 80:
>> 
>>> 78:     @IR(phase = { CompilePhase.BEFORE_MACRO_EXPANSION }, counts = { IRNode.MIN_L, "1" })
>>> 79:     @IR(phase = { CompilePhase.AFTER_MACRO_EXPANSION }, counts = { IRNode.MIN_L, "0" })
>>> 80:     private static long testLongMin(long a, long b) {
>> 
>> Can you add a comment why it disappears after macro expansion?
>
> ~Good question. On non-avx512 machines after macro expansion the min/max nodes become cmov nodes, but but that's not the full story because on avx512 machines, they become minV/maxV nodes. Would you tweak the `@IR` annotations to capture this? Or would you leave it just as a comment?~
> 
> Scratch that, this is not a test for arrays, so no minV/maxV nodes. I'll just add a comment.

I've added a comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1984510490

From epeter at openjdk.org  Fri Mar  7 06:48:05 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 7 Mar 2025 06:48:05 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v14]
In-Reply-To: <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
Message-ID: 

On Fri, 7 Mar 2025 06:19:03 GMT, Galder Zamarre?o  wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Add assertion comments
>  - Add simple reduction benchmarks on top of multiply ones
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/99572e4c...1aa690d3

Looks good, thanks for all the updates :)

I'm launching another round of testing on our side ;)

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2666394529
PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2705659841

From scolebourne at openjdk.org  Fri Mar  7 06:50:51 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Fri, 7 Mar 2025 06:50:51 GMT
Subject: RFR: 8351017: ChronoUnit.MONTHS.between() not giving correct
 result when date is in February
In-Reply-To: 
References: 
Message-ID: <_SL0c6sLPnjoMI5DUDK6Qf0WRvUDGWYvfeEIzpwXFIY=.30f0ae78-e7a9-4db7-bb05-57fd5fff3564@github.com>

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato  wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

Marked as reviewed by scolebourne (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/23937#pullrequestreview-2666401651

From galder at openjdk.org  Fri Mar  7 09:23:06 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 7 Mar 2025 09:23:06 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v14]
In-Reply-To: 
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
 
Message-ID: 

On Fri, 7 Mar 2025 06:44:57 GMT, Emanuel Peter  wrote:

>> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into topic.intrinsify-max-min-long
>>  - Add assertion comments
>>  - Add simple reduction benchmarks on top of multiply ones
>>  - Merge branch 'master' into topic.intrinsify-max-min-long
>>  - Fix typo
>>  - Renaming methods and variables and add docu on algorithms
>>  - Fix copyright years
>>  - Make sure it runs with cpus with either avx512 or asimd
>>  - Test can only run with 256 bit registers or bigger
>>    
>>    * Remove platform dependant check
>>    and use platform independent configuration instead.
>>  - Fix license header
>>  - ... and 37 more: https://git.openjdk.org/jdk/compare/bc67ede6...1aa690d3
>
> I'm launching another round of testing on our side ;)

@eme64 I've run tier[1-3] locally and looked good overall. I had to update jtreg and noticed this failure but I don't think it's related to this PR:


java.lang.AssertionError: gtest execution failed; exit code = 2. the failed tests: [codestrings::validate_vm]
	at GTestWrapper.main(GTestWrapper.java:98)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1447)

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2705937075

From ihse at openjdk.org  Fri Mar  7 11:34:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 11:34:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: 
 
 
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: 

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes  wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

@dholmes-ora Good question. I don't know the answer. I know we used `-pthread` exclusively on Solaris, and that we've used `-lpthread` on Linux (but apparently not in all cases?). I guess this difference would not have been introduced when the Linux port was created from the Solaris port unless it made sense. So maybe at that time, GCC did not support `-pthread`. Otoh, that might have changed by now.

Regardless, I would still like to see this change. We have generalized almost all system libraries to variable (like `$LIBM`, `$LIBDL` etc), and this is the last remaining (I think).

We can then check if we can turn `-lpthread` into `-pthread` on Linux as a follow up.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2706220845

From galder at openjdk.org  Fri Mar  7 12:28:58 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 7 Mar 2025 12:28:58 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <63F-0aHgMthexL0b2DFmkW8_QrJeo8OOlCaIyZApfpY=.4744070d-9d56-4031-8684-be14cf66d1e5@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 
 
 
 <63F-0aHgMthexL0b2DFmkW8_QrJeo8OOlCaIyZApfpY=.4744070d-9d56-4031-8684-be14cf66d1e5@github.com>
Message-ID: 

On Thu, 27 Feb 2025 06:54:30 GMT, Emanuel Peter  wrote:

> As for possible solutions. In all Regression 1-3 cases, it seems the issue is scalar cmove. So actually in all cases a possible solution is using branching code (i.e. `cmp+mov`). So to me, these are the follow-up RFE's:
> 
> * Detect "extreme" probability scalar cmove, and replace them with branching code. This should take care of all regressions here. This one has high priority, as it fixes the regression caused by this patch here. But it would also help to improve performance for the `Integer.min/max` cases, which have the same issue.

I've created [JDK-8351409](https://bugs.openjdk.org/browse/JDK-8351409) to address this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2706324225

From duke at openjdk.org  Fri Mar  7 12:43:02 2025
From: duke at openjdk.org (Dalaiyaz21213M)
Date: Fri, 7 Mar 2025 12:43:02 GMT
Subject: RFR: 8337972: Problem list
 jdk/internal/util/ReferencedKeyTest.java
In-Reply-To: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
References: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
Message-ID: <8NeUWwrgrJ1lA8joGWUxfn7vBngA2BZzhMuC4lYmJyg=.80c6d13b-565c-4ce2-8b3e-f6c3913a0ed7@github.com>

On Wed, 7 Aug 2024 08:33:06 GMT, Doug Simon  wrote:

> Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926) is fixed to reduce the noise in testing.

Marked as reviewed by Dalaiyaz21213M at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/20488#pullrequestreview-2667138049

From syan at openjdk.org  Fri Mar  7 13:02:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Mar 2025 13:02:03 GMT
Subject: RFR: 8351233: [ASAN] avx2-emu-funcs.hpp:151:20: error:
 =?UTF-8?B?4oCYRC44MjE4OOKAmQ==?= is used uninitialized
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan  wrote:

> Hi all,
> 
> The return type of function `const __m256i &perm` is `__m256i`, so `const __m256i &perm` should be replaced as 'const __m256i perm'.
> 
> The function implementation in gcc/clang compiler header:
> 
> 1. gcc: lib/gcc/x86_64-pc-linux-gnu/14.2.0/include/avxintrin.h
> 
> 
> extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__, __artificial__))
> _mm256_loadu_si256 (__m256i_u const *__P)
> {
>   return *__P;
> }
> 
> 
> 2. clang: lib64/clang/17/include/avxintrin.h
> 
> 
> static __inline __m256i __DEFAULT_FN_ATTRS
> _mm256_loadu_si256(__m256i_u const *__p)
> {
>   struct __loadu_si256 {
>     __m256i_u __v;
>   } __attribute__((__packed__, __may_alias__));
>   return ((const struct __loadu_si256*)__p)->__v;
> }
> 
> 
> Additional testing:
> 
> - [x] jtreg tests(include tier1/2/3 etc.) on linux-x64(AMD EPYC 9T24 96-Core Processor) with release build
> - [x] jtreg tests(include tier1/2/3 etc.) on linux-x64(AMD EPYC 9T24 96-Core Processor) with fastdebug build

GHA report 1 test failure:

1. Job 'macos-aarch64 hs/tier1 gc' report "gc/TestAllocHumongousFragment.java#generational" timed out, this issue has been recorded by [JDK-8345958](https://bugs.openjdk.org/browse/JDK-8345958), it's unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23925#issuecomment-2706398809

From ayang at openjdk.org  Fri Mar  7 13:16:59 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 7 Mar 2025 13:16:59 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v14]
In-Reply-To: 
References: 
 
Message-ID: <5w6qUwzDQadxseocRl6rRF0AllyeukWTpYl2XjAfiTE=.fb62a50e-e308-4d08-8057-67e70e13ccbb@github.com>

On Thu, 6 Mar 2025 16:26:31 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * iwalulya review
>     * renaming
>     * fix some includes, forward declaration

src/hotspot/share/gc/g1/g1CardTable.hpp line 76:

> 74:     g1_card_already_scanned = 0x1,
> 75:     g1_to_cset_card = 0x2,
> 76:     g1_from_remset_card = 0x4

Could you outline the motivation for this more precise info? Is it for optimization or essentially for correctness?

src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 54:

> 52:     assert(refinement_r == card_r, "not same region source %u (%zu) dest %u (%zu) ", refinement_r->hrm_index(), refinement_i, card_r->hrm_index(), card_i);
> 53:     assert(refinement_i == card_i, "indexes are not same %zu %zu", refinement_i, card_i);
> 54: #endif

I feel this assert logic can be extracted to a method, sth like `verify_card_pair`.

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 64:

> 62:         report_inactive("Paused");
> 63:         sts_join.yield();
> 64:         // Reset after yield rather than accumulating across yields, else a

The comment seems obsolete after the removal of stats.

src/hotspot/share/gc/g1/g1OopClosures.inline.hpp line 158:

> 156:   if (_has_ref_to_cset) {
> 157:     return;
> 158:   }

Is it really necessary to write `false` to `_has_ref_to_cset`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1985041202
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1983846649
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1983842440
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1983857348

From epeter at openjdk.org  Fri Mar  7 13:19:59 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 7 Mar 2025 13:19:59 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: 
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 
 
 
 <63F-0aHgMthexL0b2DFmkW8_QrJeo8OOlCaIyZApfpY=.4744070d-9d56-4031-8684-be14cf66d1e5@github.com>
 
Message-ID: 

On Fri, 7 Mar 2025 12:25:51 GMT, Galder Zamarre?o  wrote:

>> @galderz Thanks for the summary of regressions! Yes, there are plenty of speedups, I assume primarily because of `Long.min/max` vectorization, but possibly also because the operation can now "float" out of a loop for example.
>> 
>> All your Regressions 1-3 are cases with "extreme" probabilitiy (close to 100% / 0%), you listed none else. That matches with my intuition, that branching code is usually better than cmove in extreme probability cases.
>> 
>> As for possible solutions. In all Regression 1-3 cases, it seems the issue is scalar cmove. So actually in all cases a possible solution is using branching code (i.e. `cmp+mov`). So to me, these are the follow-up RFE's:
>> - Detect "extreme" probability scalar cmove, and replace them with branching code. This should take care of all regressions here. This one has high priority, as it fixes the regression caused by this patch here. But it would also help to improve performance for the `Integer.min/max` cases, which have the same issue.
>> - Additional performance improvement: make SuperWord recognize more cases as profitble (see Regression 1). Optional.
>> - Additional performance improvement: extend backend capabilities for vectorization (see Regression 2 + 3). Optional.
>> 
>> Does that make sense, or am I missing something?
>
>> As for possible solutions. In all Regression 1-3 cases, it seems the issue is scalar cmove. So actually in all cases a possible solution is using branching code (i.e. `cmp+mov`). So to me, these are the follow-up RFE's:
>> 
>> * Detect "extreme" probability scalar cmove, and replace them with branching code. This should take care of all regressions here. This one has high priority, as it fixes the regression caused by this patch here. But it would also help to improve performance for the `Integer.min/max` cases, which have the same issue.
> 
> I've created [JDK-8351409](https://bugs.openjdk.org/browse/JDK-8351409) to address this.

@galderz Excellent. Testing looks all good on our side. Yes I think what you saw was unrelated.
@rwestrel Could give this a last quick scan and then I think you can integrate :)

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2706434983

From ecaspole at openjdk.org  Fri Mar  7 15:31:08 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 7 Mar 2025 15:31:08 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea [v2]
In-Reply-To: 
References: 
 
Message-ID: <-WCvmCD8w4Mdjm8IIjlkf2tFkUCZSJFSuZerS1YDCaM=.f7b06be3-cbcf-46fa-b40a-94cdf3b9488a@github.com>

On Thu, 6 Mar 2025 19:51:46 GMT, Eric Caspole  wrote:

>> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix header and remove unused Blackhole

If these last cleanups are OK could I get one last Reviewer rubber stamp? TIA

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

PR Comment: https://git.openjdk.org/jdk/pull/23917#issuecomment-2706738246

From rriggs at openjdk.org  Fri Mar  7 15:47:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Mar 2025 15:47:54 GMT
Subject: RFR: 8351017: ChronoUnit.MONTHS.between() not giving correct
 result when date is in February
In-Reply-To: 
References: 
Message-ID: <1Tovre03xAO-vYF_SbW_0NcE7MzFUF3LMF93kfXWsO4=.d071de1b-9e79-4ad0-a41c-aa2ff1c0b892@github.com>

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato  wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

A nice, simple and direct clarification.  Thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23937#pullrequestreview-2667651475

From vaivanov at openjdk.org  Fri Mar  7 15:51:36 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Mar 2025 15:51:36 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v3]
In-Reply-To: 
References: 
Message-ID: 

> test setup was updated to generate data of requested size.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23873/files
  - new: https://git.openjdk.org/jdk/pull/23873/files/69207701..1f569a46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23873&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23873&range=01-02

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23873/head:pull/23873

PR: https://git.openjdk.org/jdk/pull/23873

From vaivanov at openjdk.org  Fri Mar  7 15:51:37 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Mar 2025 15:51:37 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 7 Mar 2025 05:47:59 GMT, Jatin Bhateja  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451
>
> test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 57:
> 
>> 55: 
>> 56:     SegmentAllocator segmentAllocator;
>> 57:     SegmentAllocator arenaAllocator;
> 
> Please update the copyright of this and other modified files.

Thanks. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1985294435

From vaivanov at openjdk.org  Fri Mar  7 15:54:02 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Mar 2025 15:54:02 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 7 Mar 2025 05:59:29 GMT, Jatin Bhateja  wrote:

>> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451
>
> test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 60:
> 
>> 58:     SlicingPool pool;
>> 59: 
>> 60:     @Param({"5", "20", "100"})
> 
> Can you also add size 451 in this list as this is what was fixed :-)

Thanks. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1985301955

From jbhateja at openjdk.org  Fri Mar  7 16:05:56 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Mar 2025 16:05:56 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 Mar 2025 15:51:36 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2024, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23873#discussion_r1985323523

From vaivanov at openjdk.org  Fri Mar  7 16:16:33 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Mar 2025 16:16:33 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v4]
In-Reply-To: 
References: 
Message-ID: <4CJ5iQMoVBj8e_Lk4-cbzNQ6XeA2TPvmfkNyRkRqitE=.6cc954da-15c9-4e71-bd64-9f89878dda79@github.com>

> test setup was updated to generate data of requested size.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23873/files
  - new: https://git.openjdk.org/jdk/pull/23873/files/1f569a46..908b2b40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23873&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23873&range=02-03

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23873/head:pull/23873

PR: https://git.openjdk.org/jdk/pull/23873

From jbhateja at openjdk.org  Fri Mar  7 16:16:33 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Mar 2025 16:16:33 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v4]
In-Reply-To: <4CJ5iQMoVBj8e_Lk4-cbzNQ6XeA2TPvmfkNyRkRqitE=.6cc954da-15c9-4e71-bd64-9f89878dda79@github.com>
References: 
 <4CJ5iQMoVBj8e_Lk4-cbzNQ6XeA2TPvmfkNyRkRqitE=.6cc954da-15c9-4e71-bd64-9f89878dda79@github.com>
Message-ID: 

On Fri, 7 Mar 2025 16:13:05 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

Marked as reviewed by jbhateja (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23873#pullrequestreview-2667730286

From vaivanov at openjdk.org  Fri Mar  7 16:16:33 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Mar 2025 16:16:33 GMT
Subject: RFR: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 Mar 2025 15:51:36 GMT, Vladimir Ivanov  wrote:

>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23873#issuecomment-2706855026

From vaivanov at openjdk.org  Fri Mar  7 16:16:33 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Mar 2025 16:16:33 GMT
Subject: Integrated: 8350811: [JMH] test foreign.StrLenTest failed with
 StringIndexOutOfBoundsException for size=451
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 20:24:54 GMT, Vladimir Ivanov  wrote:

> test setup was updated to generate data of requested size.

This pull request has now been integrated.

Changeset: 7c22b814
Author:    Vladimir Ivanov 
URL:       https://git.openjdk.org/jdk/commit/7c22b814d670deda6c2bb93b1e150975c27a165f
Stats:     26 lines in 3 files changed: 15 ins; 0 del; 11 mod

8350811: [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

Reviewed-by: jbhateja, vpaprotski, mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/23873

From qamai at openjdk.org  Fri Mar  7 17:38:13 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 7 Mar 2025 17:38:13 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v6]
In-Reply-To: 
References: 
Message-ID: <-WEuzvT_PM7fZzOpGN5mOklreiP0mK_QQLgltNc8h90=.6fb1f429-3af6-4abb-8e6f-bbbc18796d7a@github.com>

> Hi,
> 
> This patch improves the performance of a typical `Arena::allocate` in several ways:
> 
> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
> - Split the allocation of over-aligned memory to a slow-path method.
> - Align the memory to 8 bytes, allowing faster zeroing.
> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge branch 'master' into segmentallocate
 - revert changes to CallocArena
 - Merge branch 'master' into segmentallocate
 - copyright
 - Merge branch 'master' into segmentallocate
 - wrong init
 - move segment instance creation to SegmentFactories
 - address review
 - improve the implementation of SegmentFactories::allocateSegment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22610/files
  - new: https://git.openjdk.org/jdk/pull/22610/files/f2330067..e82cc493

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22610&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22610&range=04-05

  Stats: 50559 lines in 1797 files changed: 26233 ins; 17065 del; 7261 mod
  Patch: https://git.openjdk.org/jdk/pull/22610.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22610/head:pull/22610

PR: https://git.openjdk.org/jdk/pull/22610

From qamai at openjdk.org  Fri Mar  7 17:42:57 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 7 Mar 2025 17:42:57 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v6]
In-Reply-To: <-WEuzvT_PM7fZzOpGN5mOklreiP0mK_QQLgltNc8h90=.6fb1f429-3af6-4abb-8e6f-bbbc18796d7a@github.com>
References: 
 <-WEuzvT_PM7fZzOpGN5mOklreiP0mK_QQLgltNc8h90=.6fb1f429-3af6-4abb-8e6f-bbbc18796d7a@github.com>
Message-ID: 

On Fri, 7 Mar 2025 17:38:13 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch improves the performance of a typical `Arena::allocate` in several ways:
>> 
>> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
>> - Split the allocation of over-aligned memory to a slow-path method.
>> - Align the memory to 8 bytes, allowing faster zeroing.
>> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
>> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge branch 'master' into segmentallocate
>  - revert changes to CallocArena
>  - Merge branch 'master' into segmentallocate
>  - copyright
>  - Merge branch 'master' into segmentallocate
>  - wrong init
>  - move segment instance creation to SegmentFactories
>  - address review
>  - improve the implementation of SegmentFactories::allocateSegment

@mcimadamore Please review this patch, thanks a lot

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

PR Comment: https://git.openjdk.org/jdk/pull/22610#issuecomment-2707037164

From asemenyuk at openjdk.org  Fri Mar  7 19:55:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Mar 2025 19:55:10 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage
Message-ID: 

Changes to tests:
 - Added more test cases to ErrorTest.
 - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
 - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
 - Removed redundant negative tests/test cases duplicating ErrorTest.
 - Give unique descriptions to macos signing tests.
 
Changes to jpackage:
 - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
 - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
 - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
 - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
 - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.

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

Commit messages:
 - Update copyright year
 - Give unique descriptions to signing tests
 - Ignore default runtime if jpackage command line has `--jlink-options` option.
 - Ran ./bin/blessed-modifier-order.sh
 - Update copyright year
 - DeployParams: replace {"ERR_MissingArgument", "--input"} with "error.no-input-parameter" as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself.
 - CommandLine.parse() doesn't throw `java.io.FileNotFoundException` when command file is no found. Instead it throws `java.nio.file.NoSuchFileException`.
 - Remove negative tests from AppVersionTest. ErrorTest tests invalid app versions better, it verifies error messages in jpackage output, AppVersionTest doesn't.
 - Enhance RuntimePackageTest to test that jpackage can derive package name from the runtime image directory name if `--name` option is not given
 - LinuxResourceTest: use CannedFormattedString
 - ... and 23 more: https://git.openjdk.org/jdk/compare/caaf4098...eda0efec

Changes: https://git.openjdk.org/jdk/pull/23936/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351372
  Stats: 2111 lines in 37 files changed: 1377 ins; 459 del; 275 mod
  Patch: https://git.openjdk.org/jdk/pull/23936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23936/head:pull/23936

PR: https://git.openjdk.org/jdk/pull/23936

From asemenyuk at openjdk.org  Fri Mar  7 19:55:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Mar 2025 19:55:10 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 23:30:09 GMT, Alexey Semenyuk  wrote:

> Changes to tests:
>  - Added more test cases to ErrorTest.
>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>  - Give unique descriptions to macos signing tests.
>  
> Changes to jpackage:
>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/23936#issuecomment-2707285948

From schernyshev at openjdk.org  Fri Mar  7 20:22:04 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 7 Mar 2025 20:22:04 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 7 Mar 2025 04:34:24 GMT, David Holmes  wrote:

>>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
>> 
>> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.
>
> @sercher  your new test is failing in our CI:
> 
> [STDOUT]
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> I will file a new bug - [JDK-8351382](https://bugs.openjdk.org/browse/JDK-8351382)

@dholmes-ora I submitted a fix [here](https://github.com/openjdk/jdk/pull/23948). Could you please re-run the tests in your CI?

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2707344030

From drwhite at openjdk.org  Fri Mar  7 20:36:52 2025
From: drwhite at openjdk.org (Derek White)
Date: Fri, 7 Mar 2025 20:36:52 GMT
Subject: RFR: 8350909: [JMH] test ThreadOnSpinWaitShared failed for 2
 threads config
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Feb 2025 01:20:44 GMT, Vladimir Ivanov  wrote:

> The scope was updated to support multithread configuration (jmh option '-t 2') . No other changes needed.

Looks good!

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

Marked as reviewed by drwhite (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23834#pullrequestreview-2668297121

From liach at openjdk.org  Fri Mar  7 20:38:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Mar 2025 20:38:02 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: 
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 
Message-ID: 

On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang  wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We no longer load DelegateMH as we no longer rebind

Tier 1-3 tests only have 2 unrelated failures. Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23706#issuecomment-2707393715

From liach at openjdk.org  Fri Mar  7 20:38:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Mar 2025 20:38:03 GMT
Subject: Integrated: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant
In-Reply-To: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
Message-ID: 

On Thu, 20 Feb 2025 02:33:59 GMT, Chen Liang  wrote:

> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
> 
> There may need to be additional intrinsic work for MH combinator lf bytecode generation.

This pull request has now been integrated.

Changeset: 8ed6c1d7
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/8ed6c1d7ee3c9914092e7d45087ef61553371b70
Stats:     260 lines in 10 files changed: 86 ins; 117 del; 57 mod

8350607: Consolidate MethodHandles::zero into MethodHandles::constant

Reviewed-by: jrose, redestad, jvernee

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

PR: https://git.openjdk.org/jdk/pull/23706

From liach at openjdk.org  Fri Mar  7 20:39:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Mar 2025 20:39:54 GMT
Subject: RFR: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Mar 2025 19:51:46 GMT, Eric Caspole  wrote:

>> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix header and remove unused Blackhole

Indeed, these tests uses a static non-final field as the sink of work, which should be equivalent to using a blackhole. We can remove this unused blackhole safely.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23917#pullrequestreview-2668307561

From vaivanov at openjdk.org  Fri Mar  7 20:41:01 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Mar 2025 20:41:01 GMT
Subject: Integrated: 8350909: [JMH] test ThreadOnSpinWaitShared failed for 2
 threads config
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 Feb 2025 01:20:44 GMT, Vladimir Ivanov  wrote:

> The scope was updated to support multithread configuration (jmh option '-t 2') . No other changes needed.

This pull request has now been integrated.

Changeset: 4e67ac41
Author:    Vladimir Ivanov 
Committer: Derek White 
URL:       https://git.openjdk.org/jdk/commit/4e67ac41365ecd0c7e919d77e359f77ea602feb9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8350909: [JMH] test ThreadOnSpinWaitShared failed for 2 threads config

Reviewed-by: jbhateja, drwhite

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

PR: https://git.openjdk.org/jdk/pull/23834

From stuart.marks at oracle.com  Fri Mar  7 21:14:40 2025
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 7 Mar 2025 13:14:40 -0800
Subject: Question about IO.println
In-Reply-To: 
References: 
Message-ID: 

Hi,

Our goal with the IO class is to have it add as few mechanisms as possible. Anything 
it can do, one should easily be able to do with existing classes like PrintStream or 
BufferedReader. So, we wouldn't add a varargs method to IO itself without having one 
in PrintStream or something.

Now, should PrintStream have a varargs overload of println? Well, println first 
appeared in JDK 1.0 well before varargs existed and the answer then was to use the + 
string concatenation operator for multiple values. This still works, though there 
are cases where it doesn't work very well.

When varargs was added (5.0) PrintStream got printf with varargs, but println wasn't 
retrofitted with varargs.

And there will be string templates, which will allow one to embed multiple values 
unobtrusively, so there's no need for varargs here. And a string templates should be 
directly usable from IO.println, so it'll come for "free".

Thus I don't see a need to add varargs overloads here.

s'marks



On 3/4/25 5:03 AM, David Alayachew wrote:
> Hello Amber Dev Team and Core Libs Dev Team,
> 
> Another reddit discussion popped up today about IO.println(), and one of the 
> comments mentioned that they wanted something along the lines of this.
> 
> IO.println(num1, num2, num3); //prints out "1 2 3"
> 
> I proposed that maybe a better option would be a String.join overload. So, instead 
> of String.join(String delim, String... elements), there would be String.join(String 
> delim, Object... elements), with each object getting toString() called on it.
> 
> What are your thoughts on either of these ideas? I actually think the IO.println() 
> version is nice, but I felt like String.join made a slightly better compromise.
> 
> Another commentor mentioned that this will be easier with String Templates too, so 
> maybe it is better to wait for that. I don't think String templates are a bad idea 
> here, but it also felt like overkill imo. A library function seems like a better fit.
> 
> Thank you for your time and thoughts.
> David Alayachew


From ecaspole at openjdk.org  Fri Mar  7 21:32:57 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 7 Mar 2025 21:32:57 GMT
Subject: Integrated: 8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH
 fails with -ea
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Mar 2025 15:16:03 GMT, Eric Caspole  wrote:

> The normal SQE process runs all the repo JMH with -ea to get the last bit of extra testing. This DremFrem JMH contained some asserts that would always fire on the correct answer, disturbing this normal SQE process. I removed a lot more asserts from this JMH  which seemed to make it more of a SQE test than a benchmark. We would prefer to keep benchmarks as benchmarks as much as possible and not creep into tests.

This pull request has now been integrated.

Changeset: 76e0f30b
Author:    Eric Caspole 
URL:       https://git.openjdk.org/jdk/commit/76e0f30b15efda86cbb974bbc764ac3fb3f0f054
Stats:     157 lines in 1 file changed: 1 ins; 154 del; 2 mod

8350460: org.openjdk.bench.vm.floatingpoint.DremFrem JMH fails with -ea

Reviewed-by: liach, darcy

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

PR: https://git.openjdk.org/jdk/pull/23917

From duke at openjdk.org  Fri Mar  7 21:49:02 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Mar 2025 21:49:02 GMT
Subject: Withdrawn: 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in
 ZipFS
In-Reply-To: 
References: 
Message-ID: <-5rTLEbAKE-BCvluQCIJvk3JO_3Gi8P-tI3zQRPKLjA=.8f48bf5e-dc7e-4939-8282-bd2575687ce4@github.com>

On Wed, 25 Dec 2024 23:55:18 GMT, Bruno Ploumhans  wrote:

> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882.
> 
> Following discussion in nio-dev a while ago, I have opted to add a new `NOT_INTERRUPTIBLE` open option, superseding `FileChannelImpl#setUninterruptible`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/22882

From kbarrett at openjdk.org  Fri Mar  7 23:23:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 7 Mar 2025 23:23:24 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
Message-ID: 

Please review this revision of a previously puzzling comment intending to
provide the rationale for a bit of non-obvious code.

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

Commit messages:
 - improve comment

Changes: https://git.openjdk.org/jdk/pull/23952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351374
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23952/head:pull/23952

PR: https://git.openjdk.org/jdk/pull/23952

From liach at openjdk.org  Sat Mar  8 00:03:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Mar 2025 00:03:53 GMT
Subject: RFR: 8347472: Correct Attribute traversal and writing for Code
 attributes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Feb 2025 19:25:04 GMT, Chen Liang  wrote:

> Make UnknownAttribute and CustomAttribute delivered in code traversal, and make sure stack maps update the label references after a code transform when it is reused. Other code-bound attributes are not updated as they cannot be supplied to a CodeBuilder.
> 
> Tested the 2 cases in the new AttributesInCodeTest fails on earlier JDKs.
> 
> Testing: JDK tier 1-3 ongoing

Keep-alive; maybe I should crosspost this to classfile api dev.

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

PR Comment: https://git.openjdk.org/jdk/pull/23521#issuecomment-2707750867

From henryjen at openjdk.org  Sat Mar  8 00:33:03 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Sat, 8 Mar 2025 00:33:03 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll
Message-ID: 

JDK-8349989: jlink can use String.replace instead of String.replaceAll

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

Commit messages:
 - JDK-8349989: jlink can use String.replace instead of String.replaceAll
 - JDK-8349984: (jdeps) jdeps can use String.repeat instead of String.replaceAll

Changes: https://git.openjdk.org/jdk/pull/23954/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23954&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349984
  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23954/head:pull/23954

PR: https://git.openjdk.org/jdk/pull/23954

From asemenyuk at openjdk.org  Sat Mar  8 01:01:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 8 Mar 2025 01:01:59 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage
In-Reply-To: 
References: 
Message-ID: <8GP-Zxm3jvOKQW1OTZ6vP05Tft_9OvXIJeLD7Hnn7ZE=.392d8690-39f3-42d9-a8cb-cc28ebfda7ef@github.com>

On Thu, 6 Mar 2025 23:30:09 GMT, Alexey Semenyuk  wrote:

> Changes to tests:
>  - Added more test cases to ErrorTest.
>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>  - Give unique descriptions to macos signing tests.
>  
> Changes to jpackage:
>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.

Filed the CSR by accident.

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

PR Comment: https://git.openjdk.org/jdk/pull/23936#issuecomment-2707820543

From almatvee at openjdk.org  Sat Mar  8 04:31:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 8 Mar 2025 04:31:04 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 23:30:09 GMT, Alexey Semenyuk  wrote:

> Changes to tests:
>  - Added more test cases to ErrorTest.
>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>  - Give unique descriptions to macos signing tests.
>  
> Changes to jpackage:
>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.

Looks good with minor comments.

test/jdk/tools/jpackage/macosx/base/SigningBase.java line 37:

> 35:     enum CertIndex {
> 36:         ASCII_INDEX(0),
> 37:         UNICODE_INDEX(0),

This one should be 1. Looks like we had a bug.

test/jdk/tools/jpackage/share/ErrorTest.java line 333:

> 331:             testSpec().addArgs("--type", "invalid-type")
> 332:                     .error("ERR_InvalidInstallerType", "invalid-type"),
> 333:             // no --input for non-mular app

`non-mular` -> `non-modular`

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

PR Review: https://git.openjdk.org/jdk/pull/23936#pullrequestreview-2668889041
PR Review Comment: https://git.openjdk.org/jdk/pull/23936#discussion_r1985970911
PR Review Comment: https://git.openjdk.org/jdk/pull/23936#discussion_r1985973850

From dl at openjdk.org  Sat Mar  8 12:53:16 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 8 Mar 2025 12:53:16 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v7]
In-Reply-To: 
References: 
Message-ID: 

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 41 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8319447
 - Associate probes with carriers if Virtual (no doc updates yet)
 - Reduce volatile reads
 - Address review comments; reactivation tweak
 - Standardize parameter checking
 - Address review comments; ensure new internal methods can't clash with subclasses
 - Address feedback
 - Misc minor improvements and renamings for clarity
 - Add optional SubmitWithTimeout action
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8319447' into JDK-8319447
 - ... and 31 more: https://git.openjdk.org/jdk/compare/4e495e47...f6709108

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/0c5d22a3..f6709108

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=05-06

  Stats: 44814 lines in 1338 files changed: 20971 ins; 17281 del; 6562 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From duke at openjdk.org  Sat Mar  8 13:39:44 2025
From: duke at openjdk.org (snake66)
Date: Sat, 8 Mar 2025 13:39:44 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: 
References: 
Message-ID: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis 
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

snake66 has updated the pull request incrementally with three additional commits since the last revision:

 - Use shell var syntax in libraries.m4
 - Fix typo PTREAD->PTHREAD
 - Revert changes to make/Hsdis.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23930/files
  - new: https://git.openjdk.org/jdk/pull/23930/files/6a2c0e53..46999723

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23930&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23930&range=00-01

  Stats: 641 lines in 3 files changed: 0 ins; 0 del; 641 mod
  Patch: https://git.openjdk.org/jdk/pull/23930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23930/head:pull/23930

PR: https://git.openjdk.org/jdk/pull/23930

From tschatzl at openjdk.org  Sat Mar  8 19:32:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Sat, 8 Mar 2025 19:32:54 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v15]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:

 - * fix card table verification crashes: in the first refinement phase, when switching the global card tables, we need to re-check whether we are still in the same sweep epoch or not. It might have changed due to a GC interrupting acquiring the Heap_lock. Otherwise new threads will scribble on the refinement table.
   Cause are last-minute changes before making the PR ready to review.
   
     Testing: without the patch, occurs fairly frequently when continuously
   (1 in 20) starting refinement. Does not afterward.
 - * ayang review 3
     * comments
     * minor refactorings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/350a4fa3..93b884f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=13-14

  Stats: 35 lines in 5 files changed: 30 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Sat Mar  8 19:32:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Sat, 8 Mar 2025 19:32:54 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v9]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 4 Mar 2025 10:46:13 GMT, Thomas Schatzl  wrote:

> I got an error while testing java/foreign/TestUpcallStress.java on linuxaarch64 with this PR:

Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2708458459

From rriggs at openjdk.org  Sat Mar  8 20:35:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 8 Mar 2025 20:35:54 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Mar 2025 23:17:53 GMT, Kim Barrett  wrote:

> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.

Nice clear description.  Thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23952#pullrequestreview-2669259653

From alanb at openjdk.org  Sun Mar  9 14:41:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 9 Mar 2025 14:41:07 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 Mar 2025 00:28:15 GMT, Henry Jen  wrote:

> JDK-8349989: jlink can use String.replace instead of String.replaceAll

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java line 794:

> 792:                     log.format("%-40s %s%n",
> 793:                                "-".repeat(internalApiTitle.length()),
> 794:                                "_".repeat(replacementApiTitle.length()));

Using replaceAll to replace all characters with "-" is indeed a bit unusual. Are you sure String::length is what you want, I'm just wondering if you need the number of Unicode code points  here rather than length.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23954#discussion_r1986339411

From swen at openjdk.org  Sun Mar  9 15:40:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 9 Mar 2025 15:40:58 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v9]
In-Reply-To: <9eWh_15ds2-wCAojKrCz2s4SeB-QAPi4Mj12XttS6_8=.5c67c531-ade1-441a-ae0d-2be95bcd1556@github.com>
References: 
 <9eWh_15ds2-wCAojKrCz2s4SeB-QAPi4Mj12XttS6_8=.5c67c531-ade1-441a-ae0d-2be95bcd1556@github.com>
Message-ID: 

On Tue, 4 Feb 2025 23:02:24 GMT, Shaojin Wen  wrote:

>> The following code can reproduce the problem, writing out of bounds causes JVM Crash
>> 
>> 
>>          StringBuilder buf = new StringBuilder();
>>         buf.append('?');
>> 
>>         Thread[] threads = new Thread[40];
>>         final CountDownLatch latch = new CountDownLatch(threads.length);
>>         Runnable r = () -> {
>>             for (int i = 0; i < 1000000; i++) {
>>                 buf.setLength(0);
>>                 buf.trimToSize();
>>                 buf.append(123456789123456789L);
>>             }
>>             latch.countDown();
>>         };
>> 
>>         for (int i = 0; i < threads.length; i++) {
>>             threads[i] = new Thread(r);
>>         }
>>         for (Thread t : threads) {
>>             t.start();
>>         }
>>         latch.await();
>> 
>> 
>> This problem can be avoided by using the value of ensureCapacityInternal directly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Complete the javadoc

keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2708920840

From swen at openjdk.org  Sun Mar  9 15:42:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 9 Mar 2025 15:42:57 GMT
Subject: RFR: 8337279: Optimize format instant [v15]
In-Reply-To: <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
Message-ID: 

On Mon, 3 Feb 2025 22:31:10 GMT, Shaojin Wen  wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @natoj

Keep it alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2708921754

From swen at openjdk.org  Sun Mar  9 15:43:01 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 9 Mar 2025 15:43:01 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 Unsafe.allocateUninitializedArray
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Jan 2025 16:36:24 GMT, Shaojin Wen  wrote:

> The byte[] allocated in Integer/Long.toString is fully filled, so we can use Unsafe.allocateUninitializedArray to create byte[] to improve performance.

Keep it alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2708921634

From swen at openjdk.org  Sun Mar  9 15:43:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 9 Mar 2025 15:43:55 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 Feb 2025 13:39:28 GMT, Shaojin Wen  wrote:

>> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
>> 
>> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
>> 
>> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
>> 
>> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
>> 
>> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more use getInt & add more test

Keep it alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2708922153

From swen at openjdk.org  Sun Mar  9 15:44:03 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 9 Mar 2025 15:44:03 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: 
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 
Message-ID: 

On Sat, 1 Feb 2025 08:42:32 GMT, Shaojin Wen  wrote:

>> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - remove getChars(long, int, char[])
>  - copyright
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - simplify and comments
>  - simplify
>  - simplify
>  - code style
>  - revert change
>  - bug fix
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...f9af0b02

Keep it alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/23310#issuecomment-2708922032

From dl at openjdk.org  Sun Mar  9 17:17:50 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 9 Mar 2025 17:17:50 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v8]
In-Reply-To: 
References: 
Message-ID: 

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Disambiguate caller-runs vs Interruptible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/f6709108..6fe1a3bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=06-07

  Stats: 40 lines in 2 files changed: 12 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From dl at openjdk.org  Sun Mar  9 17:17:51 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 9 Mar 2025 17:17:51 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v6]
In-Reply-To: 
References: 
 
 
 <60IBeWm3452rLJC_2GQEdhY0I_vY0D7UKXCLgxkw5eM=.f728b6a3-bca0-4c4d-bb89-e69626d833db@github.com>
 
Message-ID: 

On Thu, 6 Mar 2025 14:34:00 GMT, Alan Bateman  wrote:

>> Maybe it's worth using java.time.Duration, although it doesn't fit into the API very elegantly.
>
>> I wonder if the variance of the Consumer to this method should be more permissible. Something like:
>> 
>> public ForkJoinTask submitWithTimeout(Callable callable, long timeout, TimeUnit unit, Consumer> timeoutAction) {
> 
> I think this is a good point but it might be more practical to limit it to just a contravariant Consumer, as in ` Consumer>`.

I agree Consumer> is sensible. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1986372835

From liach at openjdk.org  Sun Mar  9 18:13:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Mar 2025 18:13:52 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 9 Mar 2025 14:38:45 GMT, Alan Bateman  wrote:

>> JDK-8349989: jlink can use String.replace instead of String.replaceAll
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java line 794:
> 
>> 792:                     log.format("%-40s %s%n",
>> 793:                                "-".repeat(internalApiTitle.length()),
>> 794:                                "_".repeat(replacementApiTitle.length()));
> 
> Using replaceAll to replace all characters with "-" is indeed a bit unusual. Are you sure String::length is what you want, I'm just wondering if you need the number of Unicode code points  here rather than length.

These seem to be strings from localization, so I think it's unlikely to have 4-byte unicode characters appearing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23954#discussion_r1986384392

From liach at openjdk.org  Sun Mar  9 18:13:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Mar 2025 18:13:53 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 Mar 2025 00:28:15 GMT, Henry Jen  wrote:

> JDK-8349989: jlink can use String.replace instead of String.replaceAll

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 303:

> 301:             }
> 302:             String pkg = removeRadical(path, module + "/");
> 303:             return pkg.replace("/", ".");

With the conversion to `replace`, we can use the char literals `'/'` and `'.'` instead of the string literals, which gives better performance as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23954#discussion_r1986384292

From jwaters at openjdk.org  Sun Mar  9 18:30:01 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 9 Mar 2025 18:30:01 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: 
References: 
 
Message-ID: <6n7W6MsSzG06DWdin8ZYslKSPueuSMB0l5s6hQb2DPg=.f10d6056-9560-4835-8380-0b54df417426@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters  wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Keep open please. I will integrate this as soon as possible when I get approval for all the respective Pull Requests

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2709003672

From pminborg at openjdk.org  Mon Mar 10 06:52:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Mar 2025 06:52:03 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
Message-ID: 

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s  wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @SuppressWarnings (serial)

Hi. I've seen this PR being worked on for a long time. Did you discuss the motivation and objectives for this PR in the relevant mailing list as indicated in the JDK issue? Reviewing this PR seems like a handful and given new features like Valhalla and the Vector API will soon be available, did you consider waiting for those new features rather than pressing forward with this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2709590700

From roland at openjdk.org  Mon Mar 10 09:02:15 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 10 Mar 2025 09:02:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v14]
In-Reply-To: <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
Message-ID: 

On Fri, 7 Mar 2025 06:19:03 GMT, Galder Zamarre?o  wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Add assertion comments
>  - Add simple reduction benchmarks on top of multiply ones
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/07ef652d...1aa690d3

Marked as reviewed by roland (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2670211951

From chagedorn at openjdk.org  Mon Mar 10 09:19:10 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 10 Mar 2025 09:19:10 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v14]
In-Reply-To: <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
Message-ID: 

On Fri, 7 Mar 2025 06:19:03 GMT, Galder Zamarre?o  wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Add assertion comments
>  - Add simple reduction benchmarks on top of multiply ones
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/fd78e706...1aa690d3

Good work and collection of all the data!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2670256931

From ihse at openjdk.org  Mon Mar 10 11:09:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: 
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <2Q8X64gNkTwIahuYztjcdmNpOiwF9imTIUUI-0ASx4k=.4ba096ff-d60b-46fd-93ce-33215b0bc650@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66  wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis 
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

This looks good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670569844

From ihse at openjdk.org  Mon Mar 10 11:09:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: 
 
 
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: 

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes  wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

Another follow-up is if it would hurt to include $LIBPTHREAD for *all* Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710217007

From shade at openjdk.org  Mon Mar 10 12:08:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 12:08:04 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Mar 2025 23:17:53 GMT, Kim Barrett  wrote:

> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23952#pullrequestreview-2670720522

From erikj at openjdk.org  Mon Mar 10 13:04:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 13:04:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: 
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <9NJh2NWuQ_op9oUEpq2qS-64TpkGnIXaT54pdIV8amI=.e65c76d6-bb81-4ce0-b3ee-5d8c975b6ac5@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66  wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis 
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670880262

From jpai at openjdk.org  Mon Mar 10 13:43:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Mar 2025 13:43:16 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v10]
In-Reply-To: 
References: 
 
Message-ID: <9tZW4XmAOAsSOektphQM4vCiddvVp4gspHSstR_ktwA=.6aab831d-394d-421d-a03d-dbad970f901d@github.com>

On Fri, 29 Nov 2024 07:25:23 GMT, Jan Lahoda  wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> Usage: java [java options...]  [application arguments...]
>> 
>> Where  is one of:
>>                   to execute the main method of a compiled main class
>>   -jar .jar         to execute the main class of a JAR archive
>>   -m [/]  to execute the main class of a module
>>   .java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path 
>>     where  is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path 
>>     where  is a list of directories and JAR archives to search for modules, separated by ":"
>>   -version
>>     to print product version to the error stream and exit
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> The full `java -help` with these changes is as follows:
>> 
>> Usage: java [options]  [args...]
>>            (to execute a class)
>>    or  java [options] -jar .jar [args...]
>>            (to execute a jar file)
>>    or  java [options] -m [/] [args...]
>>        java [options] --module [/] [args...]
>>            (to execute the main class in a module)
>>    or  java [options] .java [args]
>>            (to execute a source-file program)
>> 
>>  Arguments following the main class, source file, -jar .jar,
>>  -m or --module / are passed as the arguments to
>>  main class.
>> 
>>  where options include:
>> 
>>     -cp 
>>     -classpath 
>>     --class-path 
>>                   A ":"-separated list of directories, JAR archives,
>>                   and ZIP archives to s...
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Dropping printing of the version.
>  - Dropping the version from the concise help

I just want to note that this has been a very pleasant change. I happened to type just `java` against the JDK mainline and instead of seeing text scroll past a page on my screen, it was very nice to just see this shorter text.

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

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2710634974

From ihse at openjdk.org  Mon Mar 10 13:48:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 13:48:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 6 Mar 2025 13:27:15 GMT, snake66  wrote:

>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
>> 
>> Needs build team approval before integrating.
>
>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
> 
> I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

@snake66 To integrate this, you need to give the command `/integrate` as a comment. Then I (or someone else) with committer permissions can sponsor the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710652078

From vklang at openjdk.org  Mon Mar 10 14:37:04 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 10 Mar 2025 14:37:04 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 9 Mar 2025 17:17:50 GMT, Doug Lea 
 wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disambiguate caller-runs vs Interruptible

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1301:

> 1299:                 if ((room == 0 ||        // pad if no caller-run
> 1300:                      a[m & (s - ((internal || task == null ||
> 1301:                                   task.noUserHelp() == 0) ? 1 : 2))] == null) &&

Not saying that we should, but it would be possible to make this branch-free.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1987424006

From duke at openjdk.org  Mon Mar 10 15:49:55 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Mar 2025 15:49:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: 
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: 

On Sat, 8 Mar 2025 13:39:44 GMT, snake66  wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis 
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

@snake66 
Your change (at version 469997239f26f59cd47df19fb9e836b883687487) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2711042802

From asemenyuk at openjdk.org  Mon Mar 10 15:54:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 10 Mar 2025 15:54:56 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage [v2]
In-Reply-To: 
References: 
Message-ID: 

> Changes to tests:
>  - Added more test cases to ErrorTest.
>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>  - Give unique descriptions to macos signing tests.
>  
> Changes to jpackage:
>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo
 - Fix Unicode signing certificate index

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23936/files
  - new: https://git.openjdk.org/jdk/pull/23936/files/eda0efec..54585147

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23936&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23936&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23936/head:pull/23936

PR: https://git.openjdk.org/jdk/pull/23936

From asemenyuk at openjdk.org  Mon Mar 10 15:54:58 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 10 Mar 2025 15:54:58 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 8 Mar 2025 04:01:41 GMT, Alexander Matveev  wrote:

>> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix typo
>>  - Fix Unicode signing certificate index
>
> test/jdk/tools/jpackage/macosx/base/SigningBase.java line 37:
> 
>> 35:     enum CertIndex {
>> 36:         ASCII_INDEX(0),
>> 37:         UNICODE_INDEX(0),
> 
> This one should be 1. Looks like we had a bug.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23936#discussion_r1987576405

From naoto at openjdk.org  Mon Mar 10 16:16:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Mar 2025 16:16:03 GMT
Subject: RFR: 8351017: ChronoUnit.MONTHS.between() not giving correct
 result when date is in February
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato  wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23937#issuecomment-2711119572

From naoto at openjdk.org  Mon Mar 10 16:16:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Mar 2025 16:16:04 GMT
Subject: Integrated: 8351017: ChronoUnit.MONTHS.between() not giving correct
 result when date is in February
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato  wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

This pull request has now been integrated.

Changeset: 32f2c2d8
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/32f2c2d80894552b8c5329cfa51c7e836314901f
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8351017: ChronoUnit.MONTHS.between() not giving correct result when date is in February

Reviewed-by: scolebourne, rriggs

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

PR: https://git.openjdk.org/jdk/pull/23937

From henryjen at openjdk.org  Mon Mar 10 17:17:00 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 10 Mar 2025 17:17:00 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 9 Mar 2025 18:11:07 GMT, Chen Liang  wrote:

>> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java line 794:
>> 
>>> 792:                     log.format("%-40s %s%n",
>>> 793:                                "-".repeat(internalApiTitle.length()),
>>> 794:                                "_".repeat(replacementApiTitle.length()));
>> 
>> Using replaceAll to replace all characters with "-" is indeed a bit unusual. Are you sure String::length is what you want, I'm just wondering if you need the number of Unicode code points  here rather than length.
>
> These seem to be strings from localization, so I think it's unlikely to have 4-byte unicode characters appearing.

To have exactly same behavior, I think Alan is correct to use code point count here. Although unlikely as @liach pointed out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23954#discussion_r1987712203

From rriggs at openjdk.org  Mon Mar 10 18:11:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Mar 2025 18:11:26 GMT
Subject: RFR: 8351567: Jar Manifest test ValueUtf8Coding produces misleading
 diagnostic output
Message-ID: 

Remove misleading/invalid diagnostic output from the JAR manifest test ValueUtf8Coding.java.

The Manifest binary stream is not a well formed UTF-8 string due to the inserted continuation characters used for lines longer than 70 characters..

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

Commit messages:
 - 8351567: Jar Manifest test ValueUtf8Coding produces misleading diagnostic output

Changes: https://git.openjdk.org/jdk/pull/23971/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351567
  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23971/head:pull/23971

PR: https://git.openjdk.org/jdk/pull/23971

From rgiulietti at openjdk.org  Mon Mar 10 18:12:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 10 Mar 2025 18:12:01 GMT
Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in
 FloatingDecimal [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Jan 2025 10:55:16 GMT, Raffaello Giulietti  wrote:

>> See the JBS bug for some details.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8343829
>  - Redacted comments.
>  - Merge branch 'master' into 8343829
>  - Minors in comments.
>  - Removed repeated comment.
>  - Refactoring some code and comments.
>  - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal

Ping

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

PR Comment: https://git.openjdk.org/jdk/pull/22737#issuecomment-2711427725

From duke at openjdk.org  Mon Mar 10 18:39:59 2025
From: duke at openjdk.org (kabutz)
Date: Mon, 10 Mar 2025 18:39:59 GMT
Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
In-Reply-To: 
References: 
Message-ID: 

On Wed, 5 Feb 2025 15:36:15 GMT, kabutz  wrote:

> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

Should we drop this PR or continue with it?

I noticed that the timed offer() and poll() methods are consistent with the way that LinkedBlockingQueue works, in other words, they throw the InterruptedException as soon as we enter the methods. They use lock.lockInterruptibly(), which I was suggesting we use for put() and take().


import java.util.concurrent.*;

public class OfferPollLBD {
    public static void main(String... args) {
        var lbd = new LinkedBlockingDeque();
        Thread.currentThread().interrupt();
        System.out.println(lbd.offer(1)); // should work
        System.out.println(lbd.add(2)); // should work
        try {
            System.out.println(lbd.offer(3, 10, TimeUnit.SECONDS)); // throws IE
        } catch (InterruptedException e) {
            System.out.println("Interrupted");
            Thread.currentThread().interrupt();
        }
        try {
            lbd.put(4); // IMHO should throw IE, but doesn't
            System.out.println("put(4) succeeded");
        } catch (InterruptedException e) {
            System.out.println("Interrupted");
            Thread.currentThread().interrupt();
        }

        System.out.println("lbd = " + lbd);

        System.out.println(lbd.poll()); // should work
        System.out.println(lbd.remove()); // should work
        try {
            System.out.println(lbd.poll(10, TimeUnit.SECONDS)); // throws IE
        } catch (InterruptedException e) {
            System.out.println("Interrupted");
            Thread.currentThread().interrupt();
        }
        try {
            System.out.println(lbd.take());
        } catch (InterruptedException e) {
            System.out.println("Interrupted");
            Thread.currentThread().interrupt();
        }
        System.out.println("lbd = " + lbd);
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/23464#issuecomment-2711493965

From lancea at openjdk.org  Mon Mar 10 18:48:59 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Mar 2025 18:48:59 GMT
Subject: RFR: 8351567: Jar Manifest test ValueUtf8Coding produces
 misleading diagnostic output
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:06:43 GMT, Roger Riggs  wrote:

> Remove misleading/invalid diagnostic output from the JAR manifest test ValueUtf8Coding.java.
> 
> The Manifest binary stream is not a well formed UTF-8 string due to the inserted continuation characters used for lines longer than 70 characters..

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23971#pullrequestreview-2671905294

From bpb at openjdk.org  Mon Mar 10 18:54:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Mar 2025 18:54:53 GMT
Subject: RFR: 8351567: Jar Manifest test ValueUtf8Coding produces
 misleading diagnostic output
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:06:43 GMT, Roger Riggs  wrote:

> Remove misleading/invalid diagnostic output from the JAR manifest test ValueUtf8Coding.java.
> 
> The Manifest binary stream is not a well formed UTF-8 string due to the inserted continuation characters used for lines longer than 70 characters..

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23971#pullrequestreview-2671919160

From duke at openjdk.org  Mon Mar 10 19:09:10 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Mon, 10 Mar 2025 19:09:10 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
 
Message-ID: 

On Mon, 10 Mar 2025 06:48:49 GMT, Per Minborg  wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add @SuppressWarnings (serial)
>
> Hi. I've seen this PR being worked on for a long time. Did you discuss the motivation and objectives for this PR in the relevant mailing list as indicated in the JDK issue? Reviewing this PR seems like a handful and given new features like Valhalla and the Vector API will soon be available, did you consider waiting for those new features rather than pressing forward with this PR?

Hi @minborg,

Thank you for your comments!

You're right, this is a long period of activity, please see the short history of it.

Dual-Pivot Quicksort was suggested and integrated into JDK 7 by Josh Bloch, John Bentley and me in September-November 2009. Later I improved the sorting several times faster in JDK 7, 8 and 14.

In April 2021 Laurent Bourges suggested adding Radix sort which is several times faster than Quicksort on a large array of random data. In May 2021 I created my PR, but my account was not enabled very fast, so I continued optimization. Later we had to move to Laurent's PR with new portions of optimizations.

As we discussed with Alan Bateman and Paul Sandoz, Radix sort will be applied to parallel sort only. Even though Radix sort is not called for sequential sorting, Dual-Pivot Quicksort became faster for many data types, like double/float, char/byte/short, on various inputs (both, sequential and parallel cases).

In August 2023 Vamsi Parsa improved the sorting using AVX512 instructions. It made sorting faster on Linux on Intel processors with AVX512. I can say my current changes speedup this AVX512-ed version, it happens due to different types of optimizations (algorithmic vs. instruction). My algorithmic changes don't correlate with new features (Valhalla / Vector API / etc.) and can be developed / integrated independently.

Now I have the final version of Dual-Pivot Quicksort with fine benchmarking results. I need time to check test coverage. I plan to create new PR under my account and publish updated classes and benchmarks within one month. I hope it makes sense.

@minborg, what do you think, what is your vision?

Best regards,
Vladimir

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2711567092

From iris at openjdk.org  Mon Mar 10 19:20:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Mar 2025 19:20:52 GMT
Subject: RFR: 8351567: Jar Manifest test ValueUtf8Coding produces
 misleading diagnostic output
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:06:43 GMT, Roger Riggs  wrote:

> Remove misleading/invalid diagnostic output from the JAR manifest test ValueUtf8Coding.java.
> 
> The Manifest binary stream is not a well formed UTF-8 string due to the inserted continuation characters used for lines longer than 70 characters..

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23971#pullrequestreview-2671975916

From almatvee at openjdk.org  Mon Mar 10 20:35:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 10 Mar 2025 20:35:53 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Mar 2025 15:54:56 GMT, Alexey Semenyuk  wrote:

>> Changes to tests:
>>  - Added more test cases to ErrorTest.
>>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>>  - Give unique descriptions to macos signing tests.
>>  
>> Changes to jpackage:
>>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo
>  - Fix Unicode signing certificate index

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23936#pullrequestreview-2672136165

From asemenyuk at openjdk.org  Mon Mar 10 20:48:42 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 10 Mar 2025 20:48:42 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage [v3]
In-Reply-To: 
References: 
Message-ID: 

> Changes to tests:
>  - Added more test cases to ErrorTest.
>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>  - Give unique descriptions to macos signing tests.
>  
> Changes to jpackage:
>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Use Executor.trace() instead of TKit.trace()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23936/files
  - new: https://git.openjdk.org/jdk/pull/23936/files/54585147..3fdf653e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23936&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23936&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23936/head:pull/23936

PR: https://git.openjdk.org/jdk/pull/23936

From henryjen at openjdk.org  Mon Mar 10 22:08:06 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 10 Mar 2025 22:08:06 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll [v2]
In-Reply-To: 
References: 
Message-ID: 

> JDK-8349989: jlink can use String.replace instead of String.replaceAll

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedbacks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23954/files
  - new: https://git.openjdk.org/jdk/pull/23954/files/ba991ea5..512e0b9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23954&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23954&range=00-01

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23954/head:pull/23954

PR: https://git.openjdk.org/jdk/pull/23954

From almatvee at openjdk.org  Mon Mar 10 22:08:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 10 Mar 2025 22:08:57 GMT
Subject: RFR: 8351372: Improve negative tests coverage of jpackage [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Mar 2025 20:48:42 GMT, Alexey Semenyuk  wrote:

>> Changes to tests:
>>  - Added more test cases to ErrorTest.
>>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>>  - Give unique descriptions to macos signing tests.
>>  
>> Changes to jpackage:
>>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Executor.trace() instead of TKit.trace()

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23936#pullrequestreview-2672304801

From bpb at openjdk.org  Mon Mar 10 22:23:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Mar 2025 22:23:04 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v11]
In-Reply-To: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
References: 
 <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
Message-ID: <0gRIhH2kkir2ojZFQ_JwXoo5K6TQ_6jM1jS_9kkzgU8=.2cd33484-171a-4443-834b-76ddd45b6b72@github.com>

On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter  wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge
>  - Merge
>  - Merge
>  - 8337143: Minor makefile tweak
>  - 8337143: Clean up to address reviewer comments
>  - Merge
>  - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to /native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2711976367

From rriggs at openjdk.org  Mon Mar 10 23:07:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Mar 2025 23:07:56 GMT
Subject: Integrated: 8351567: Jar Manifest test ValueUtf8Coding produces
 misleading diagnostic output
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:06:43 GMT, Roger Riggs  wrote:

> Remove misleading/invalid diagnostic output from the JAR manifest test ValueUtf8Coding.java.
> 
> The Manifest binary stream is not a well formed UTF-8 string due to the inserted continuation characters used for lines longer than 70 characters..

This pull request has now been integrated.

Changeset: ffa63409
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/ffa63409884e9a2d41f5223ab5962980edbb008c
Stats:     6 lines in 1 file changed: 0 ins; 4 del; 2 mod

8351567: Jar Manifest test ValueUtf8Coding produces misleading diagnostic output

Reviewed-by: lancea, bpb, iris

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

PR: https://git.openjdk.org/jdk/pull/23971

From bchristi at openjdk.org  Mon Mar 10 23:16:54 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 10 Mar 2025 23:16:54 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Mar 2025 23:17:53 GMT, Kim Barrett  wrote:

> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 142:

> 140:                 // while there are registered cleanables for other objects.
> 141:                 // If the application cleans all remaining cleanables, there
> 142:                 // won't be any references enqueued to unblock this.  Using a

I agree that calling `queue.remove()` with a timeout is the right approach.
But I have a question:
In the case where the Cleaner's `CleanerCleanable` has already run, and we get to processing the last registered cleanable on `activeList`:
When we do the `ref.clean()`, the `activeList` becomes empty, and we'll drop out of the `while()` loop. So I'm not seeing how we would attempt another `queue.remove()` in this case.
What am I missing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23952#discussion_r1988140719

From fyang at openjdk.org  Tue Mar 11 03:25:55 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 11 Mar 2025 03:25:55 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 8 Mar 2025 19:32:54 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - * fix card table verification crashes: in the first refinement phase, when switching the global card tables, we need to re-check whether we are still in the same sweep epoch or not. It might have changed due to a GC interrupting acquiring the Heap_lock. Otherwise new threads will scribble on the refinement table.
>    Cause are last-minute changes before making the PR ready to review.
>    
>      Testing: without the patch, occurs fairly frequently when continuously
>    (1 in 20) starting refinement. Does not afterward.
>  - * ayang review 3
>      * comments
>      * minor refactorings

Tier1-3 test good on linux-riscv64 platform. And I have prepared an add-on change which implements the barrier method to write cards for a reference array for this platform. Do you want to have it in this PR? Thanks.
[23739-riscv-addon.txt](https://github.com/user-attachments/files/19174898/23739-riscv-addon.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2712469306

From alanb at openjdk.org  Tue Mar 11 09:39:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 09:39:54 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Mar 2025 22:08:06 GMT, Henry Jen  wrote:

>> JDK-8349989: jlink can use String.replace instead of String.replaceAll
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

I think this looks okay, I assume you'll bump the copyright headers before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23954#pullrequestreview-2673613618

From tschatzl at openjdk.org  Tue Mar 11 09:51:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 11 Mar 2025 09:51:53 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v16]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * optimized RISCV gen_write_ref_array_post_barrier() implementation contributed by @RealFYang

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/93b884f1..758fac01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=14-15

  Stats: 36 lines in 1 file changed: 28 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Tue Mar 11 09:54:05 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 11 Mar 2025 09:54:05 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v15]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 11 Mar 2025 03:22:52 GMT, Fei Yang  wrote:

> Tier1-3 test good on linux-riscv64 platform. And I have prepared an add-on change which implements the barrier method to write cards for a reference array for this platform. Do you want to have it in this PR? Thanks.

I added your changes, thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2713415911

From pminborg at openjdk.org  Tue Mar 11 12:52:20 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Mar 2025 12:52:20 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
 
 
Message-ID: 

On Mon, 10 Mar 2025 19:06:27 GMT, Vladimir Yaroslavskiy  wrote:

>> Hi. I've seen this PR being worked on for a long time. Did you discuss the motivation and objectives for this PR in the relevant mailing list as indicated in the JDK issue? Reviewing this PR seems like a handful and given new features like Valhalla and the Vector API will soon be available, did you consider waiting for those new features rather than pressing forward with this PR?
>
> Hi @minborg,
> 
> Thank you for your comments!
> 
> You're right, this is a long period of activity, please see the short history of it.
> 
> Dual-Pivot Quicksort was suggested and integrated into JDK 7 by Josh Bloch, John Bentley and me in September-November 2009. Later I improved the sorting several times faster in JDK 7, 8 and 14.
> 
> In April 2021 Laurent Bourges suggested adding Radix sort which is several times faster than Quicksort on a large array of random data. In May 2021 I created my PR, but my account was not enabled very fast, so I continued optimization. Later we had to move to Laurent's PR with new portions of optimizations.
> 
> As we discussed with Alan Bateman and Paul Sandoz, Radix sort will be applied to parallel sort only. Even though Radix sort is not called for sequential sorting, Dual-Pivot Quicksort became faster for many data types, like double/float, char/byte/short, on various inputs (both, sequential and parallel cases).
> 
> In August 2023 Vamsi Parsa improved the sorting using AVX512 instructions. It made sorting faster on Linux on Intel processors with AVX512. I can say my current changes speedup this AVX512-ed version, it happens due to different types of optimizations (algorithmic vs. instruction). My algorithmic changes don't correlate with new features (Valhalla / Vector API / etc.) and can be developed / integrated independently.
> 
> Now I have the final version of Dual-Pivot Quicksort with fine benchmarking results. I need time to check test coverage. I plan to create new PR under my account and publish updated classes and benchmarks within one month. I hope it makes sense.
> 
> @minborg, what do you think, what is your vision?
> 
> Best regards,
> Vladimir

Thanks for the update @iaroslavski . I am a bit worried that it will be difficult to find reviewers for this PR since it has a relatively large spanning scope. But I might be wrong about that.

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2714080883

From vklang at openjdk.org  Tue Mar 11 13:50:08 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 11 Mar 2025 13:50:08 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v8]
In-Reply-To: 
References: 
 
 
Message-ID: <1d1ZRw0a3t-wbC1p2g4wAWXH2bj6yn6NTaYFFedWCB0=.9ccce271-4ea9-4ec6-93e6-3e3539c1436e@github.com>

On Mon, 10 Mar 2025 14:34:42 GMT, Viktor Klang  wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disambiguate caller-runs vs Interruptible
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1301:
> 
>> 1299:                 if ((room == 0 ||        // pad if no caller-run
>> 1300:                      a[m & (s - ((internal || task == null ||
>> 1301:                                   task.noUserHelp() == 0) ? 1 : 2))] == null) &&
> 
> Not saying that we should, but it would be possible to make this branch-free.

Something like `1 + (task.noUserHelp() >>> 24)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1989317149

From jpai at openjdk.org  Tue Mar 11 14:28:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 14:28:36 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile access
 with non-UTF8 charset
Message-ID: 

Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.

ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.

The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.

The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.

In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.

The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`, thus allowing a separate `ZipCoder` instance per `ZipFile`. The `Source` when being constructed and when parsing the entries, will use a method local `ZipCoder` instance as and when needed.

The change that was done in Java 15 was a performance optimization. I have verified that the current proposed change in this PR doesn't degrade the performance and yet fixes the reported issue. A new jtreg test has been introduced to reproduce the issue and verify the fix. Local testing with this change passed. tier testing is currently in progress.

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

Commit messages:
 - 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset

Changes: https://git.openjdk.org/jdk/pull/23986/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347712
  Stats: 240 lines in 3 files changed: 188 ins; 13 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/23986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23986/head:pull/23986

PR: https://git.openjdk.org/jdk/pull/23986

From jpai at openjdk.org  Tue Mar 11 14:28:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 14:28:36 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset
In-Reply-To: 
References: 
Message-ID: <0-8KfMt72J6Lu-ng9IVFrl5AN4RgrUi8jC7to-h_ldk=.7e6c1f64-6f34-4c8b-8be6-dc85450ed077@github.com>

On Tue, 11 Mar 2025 14:23:02 GMT, Jaikiran Pai  wrote:

> The change that was done in Java 15 was a performance optimization. I have verified that the current proposed change in this PR doesn't degrade the performance and yet fixes the reported issue.

The `test/micro/org/openjdk/bench/java/util/zip/ZipFileGetEntry.java` micro benchmark was introduced in Java 15, when that change was done. I have run that benchmark locally on macos before and after the fix proposed in this current PR and I don't see any noticeable difference (which is a good thing):


Before the change in the current PR:

Benchmark                             (size)  Mode  Cnt   Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15  32.636 ? 1.169  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15  36.082 ? 1.437  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  51.132 ? 1.241  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  53.466 ? 2.568  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   9.151 ? 0.560  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   9.330 ? 0.538  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15  18.173 ? 1.016  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15  21.209 ? 1.264  ns/op



After the change in the current PR:

Benchmark                             (size)  Mode  Cnt   Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15  32.278 ? 0.565  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15  35.998 ? 1.807  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  54.884 ? 3.452  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  52.919 ? 1.621  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   8.898 ? 0.050  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   9.184 ? 0.048  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15  18.388 ? 0.708  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15  21.448 ? 0.848  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2714515521

From alanb at openjdk.org  Tue Mar 11 14:35:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 14:35:52 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset
In-Reply-To: 
References: 
Message-ID: <8EmcrMETQOdPlKHRPsTFwy39RJZDid47IfalaSoMPOc=.24ace49b-11d3-4c8c-b083-8d51554726c4@github.com>

On Tue, 11 Mar 2025 14:23:02 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
> 
> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
> 
> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
> 
> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
> 
> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
> 
> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,...

This is going to require careful review. Can you ensure that this has at least 2 reviewers?

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

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2714543570

From jpai at openjdk.org  Tue Mar 11 14:40:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 14:40:53 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset
In-Reply-To: <8EmcrMETQOdPlKHRPsTFwy39RJZDid47IfalaSoMPOc=.24ace49b-11d3-4c8c-b083-8d51554726c4@github.com>
References: 
 <8EmcrMETQOdPlKHRPsTFwy39RJZDid47IfalaSoMPOc=.24ace49b-11d3-4c8c-b083-8d51554726c4@github.com>
Message-ID: 

On Tue, 11 Mar 2025 14:31:48 GMT, Alan Bateman  wrote:

> This is going to require careful review. Can you ensure that this has at least 2 reviewers?

Agreed. I've officially marked this as requiring 2 reviewers. @LanceAndersen, @cl4es, I would specially like your reviews for this change, when you get a chance.

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

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2714568133

From jpai at openjdk.org  Tue Mar 11 14:46:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 14:46:40 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: 
References: 
Message-ID: 

> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
> 
> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
> 
> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
> 
> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
> 
> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
> 
> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  tiny typo fix in newly introduced documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23986/files
  - new: https://git.openjdk.org/jdk/pull/23986/files/d0518e7c..b9734fa4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23986/head:pull/23986

PR: https://git.openjdk.org/jdk/pull/23986

From duke at openjdk.org  Tue Mar 11 15:14:04 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 15:14:04 GMT
Subject: Integrated: 8351322: Parameterize link option for pthreads
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 Mar 2025 10:39:27 GMT, snake66  wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis 
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

This pull request has now been integrated.

Changeset: b957e5ed
Author:    Harald Eilertsen 
URL:       https://git.openjdk.org/jdk/commit/b957e5ed1a8b77e01aad1bb574e4914131cdbfa6
Stats:     660 lines in 9 files changed: 9 ins; 0 del; 651 mod

8351322: Parameterize link option for pthreads

Reviewed-by: erikj, ihse, dholmes

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

PR: https://git.openjdk.org/jdk/pull/23930

From eirbjo at openjdk.org  Tue Mar 11 16:08:56 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 11 Mar 2025 16:08:56 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: 
References: 
 
Message-ID: <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>

On Tue, 11 Mar 2025 14:46:40 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny typo fix in newly introduced documentation

@jaikiran I looked over this and added some comments. Some or most may be personal preference, take whatever you find useful. (Not a Reviewer)

src/java.base/share/classes/java/util/zip/ZipFile.java line 86:

> 84:     private final String fileName;     // name of the file
> 85:     // the ZipCoder instance is derived from the Charset passed to the ZipFile constructor
> 86:     // and will be used for decoding the non-UTF-8 entry names and the ZIP file comment.

Maybe a personal preference, and perhaps I'm too intimitely familiar with this code, but I feel this field comment is overly verbose. 

Not sure how useful it is to document what the instance is derived from, it's not something we do for other fields and maintainers can always inspect the constructor to find out how it's being assigned.

The "non-UTF-8" part is correct, but I feel this information belongs closer to where that decision is made, not here.

The ZipCoder is used when decoding entry comments as well, so the current comment is not fully correct.

Perhaps something like "Used for decoding binary encoded names and comments into strings" would do?

src/java.base/share/classes/java/util/zip/ZipFile.java line 87:

> 85:     // the ZipCoder instance is derived from the Charset passed to the ZipFile constructor
> 86:     // and will be used for decoding the non-UTF-8 entry names and the ZIP file comment.
> 87:     private final ZipCoder entryNameCommentCoder;

Since we do not have separate ZipCoders for decoding the differnt ZIP values, I'm not sure it's useful to put the field names ("name"/"comment") into the instance field name here. Especially if the comment already has this information.

Could we call this just `zc` or `zipCoder`?

src/java.base/share/classes/java/util/zip/ZipFile.java line 87:

> 85:     // the ZipCoder instance is derived from the Charset passed to the ZipFile constructor
> 86:     // and will be used for decoding the non-UTF-8 entry names and the ZIP file comment.
> 87:     private final ZipCoder entryNameCommentCoder;

The Source `ZipCoder` field had a `@Stable` annotation. Any reason why this did not survive the move?

src/java.base/share/classes/java/util/zip/ZipFile.java line 376:

> 374:      * @param pos the entry position
> 375:      */
> 376:     private static boolean useUTF8Coder(final byte[] cen, final int pos) {

This seems mostly used to determine which `ZipCoder` to pick. Could we fold this into the method, calling it `zipCoderForPos` and make it just return the `ZipCoder`, like we had in `Source`?

If it needs to be static, then the non-UTF8 ZipCoder could be passed as a parameter?

If a method to determine whether a CEN entry uses UTF-8 is still needed, then I think it would be more appropriately named  `isUTF8Entry`.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1222:

> 1220:                 table[hsh] = index;
> 1221:                 // Record the CEN offset and the name hash in our hash cell.
> 1222:                 entries[index] = hash;

Seems unrelated to the issue at hand. Perhaps better left for a separate PR, backed by a benchmark.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1426:

> 1424:             private final Charset entryNameCommentCharset;
> 1425: 
> 1426:             public Key(File file, BasicFileAttributes attrs, Charset entryNameCommentCharset) {

I feel this parameter and the field it is assigned to could also just be called `charset`. The comment has the information about what it's used for.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1434:

> 1432:             @Override
> 1433:             public int hashCode() {
> 1434:                 long t = entryNameCommentCharset.hashCode();

This represents a behavioral change, right? Is a CSR warranted?

src/java.base/share/classes/java/util/zip/ZipFile.java line 1744:

> 1742: 
> 1743:                 int entryPos = pos + CENHDR;
> 1744:                 final ZipCoder entryZipCoder;

If you want to construct this lazily, then I think a comment documenting that purpose would be useful here.

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

PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2675038945
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989545209
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989552146
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989553775
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989558136
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989562779
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989564232
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989566059
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1989622836

From eirbjo at openjdk.org  Tue Mar 11 16:11:52 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 11 Mar 2025 16:11:52 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset
In-Reply-To: 
References: 
 <8EmcrMETQOdPlKHRPsTFwy39RJZDid47IfalaSoMPOc=.24ace49b-11d3-4c8c-b083-8d51554726c4@github.com>
 
Message-ID: 

On Tue, 11 Mar 2025 14:37:34 GMT, Jaikiran Pai  wrote:

> Agreed. I've officially marked this as requiring 2 reviewers.

Did you mean to do `/reviewers 2 reviewer` ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2714917964

From henryjen at openjdk.org  Tue Mar 11 16:27:52 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 11 Mar 2025 16:27:52 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll [v3]
In-Reply-To: 
References: 
Message-ID: 

> JDK-8349989: jlink can use String.replace instead of String.replaceAll

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23954/files
  - new: https://git.openjdk.org/jdk/pull/23954/files/512e0b9d..5fe09659

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23954&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23954&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23954/head:pull/23954

PR: https://git.openjdk.org/jdk/pull/23954

From alanb at openjdk.org  Tue Mar 11 17:54:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 17:54:51 GMT
Subject: RFR: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll [v3]
In-Reply-To: 
References: 
 
Message-ID: <6p3pSlcK14mYDFMOcyQtwOENvyPgeKMb56TYO5JgQv0=.8492ab11-865c-46ae-adb0-4e09e8eb1383@github.com>

On Tue, 11 Mar 2025 16:27:52 GMT, Henry Jen  wrote:

>> JDK-8349989: jlink can use String.replace instead of String.replaceAll
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23954#pullrequestreview-2675585136

From naoto at openjdk.org  Tue Mar 11 18:37:28 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Mar 2025 18:37:28 GMT
Subject: RFR: 8351435: Change JLine Console implementation back to opt-in
Message-ID: 

JDK has been using JLine based Console implementation, in JDK20 as opt-in, then in JDK22 as the default. While it has been providing rich functionality for Console, it is increasingly difficult to maintain as a Console implementation. In light of the on-ramp feature (https://bugs.openjdk.org/browse/JDK-8344699), which proposes switching `java.lang.IO` class to use `System.in` and `System.out` instead of Console, reverting the default Console implementation to JDK's built-in one in the java.base module is considered desirable. Some tests are modified along with this change, among them test/jdk/java/io/Console/ConsolePromptTest.java changes were contributed by @lahodaj (thanks!)

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

Commit messages:
 - Test fix provided by @lahodaj
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/23993/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23993&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351435
  Stats: 113 lines in 9 files changed: 55 ins; 8 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/23993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23993/head:pull/23993

PR: https://git.openjdk.org/jdk/pull/23993

From liach at openjdk.org  Tue Mar 11 18:54:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Mar 2025 18:54:55 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Feb 2025 02:26:57 GMT, Chen Liang  wrote:

> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
> 
> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.

Keep alive; no one is responding on the classfile-api-dev list...

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

PR Comment: https://git.openjdk.org/jdk/pull/23548#issuecomment-2715401502

From duke at openjdk.org  Tue Mar 11 19:32:10 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Mar 2025 19:32:10 GMT
Subject: Withdrawn: 8347471: Provide valid flags and mask in
 AccessFlag.Location
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Jan 2025 07:38:30 GMT, Chen Liang  wrote:

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set flags()`
> - `int flagsMask()`
> - `Set flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23095

From rriggs at openjdk.org  Tue Mar 11 19:48:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Mar 2025 19:48:58 GMT
Subject: RFR: 8351045: ClassValue::remove cannot ensure computation
 observes up-to-date state [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 5 Mar 2025 15:19:27 GMT, Chen Liang  wrote:

>> After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a remove happened, and proceed to install an outdated value onto a CV.
>> 
>> The fix is simple - to force computation to retry when a remove has happened, so the retry can observe the up-to-date states from the remove. (finishEntry and removeEntry are both synchronized on the object monitor of the ClassValueMap instance)
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Improve docs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-remove
>  - 8351045: ClassValue::remove cannot ensure computation observes up-to-date state

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23866#pullrequestreview-2675920565

From liach at openjdk.org  Tue Mar 11 19:54:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Mar 2025 19:54:59 GMT
Subject: RFR: 8351045: ClassValue::remove cannot ensure computation
 observes up-to-date state [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 5 Mar 2025 15:19:27 GMT, Chen Liang  wrote:

>> After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a remove happened, and proceed to install an outdated value onto a CV.
>> 
>> The fix is simple - to force computation to retry when a remove has happened, so the retry can observe the up-to-date states from the remove. (finishEntry and removeEntry are both synchronized on the object monitor of the ClassValueMap instance)
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Improve docs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-remove
>  - 8351045: ClassValue::remove cannot ensure computation observes up-to-date state

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23866#issuecomment-2715533581

From liach at openjdk.org  Tue Mar 11 19:54:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Mar 2025 19:54:59 GMT
Subject: Integrated: 8351045: ClassValue::remove cannot ensure computation
 observes up-to-date state
In-Reply-To: 
References: 
Message-ID: <20Mkax8oZkn0stGIGyrnDVFq4bG3NC5k4QsGVdHwTqs=.6b8e6bdf-edd6-4e2b-ac2a-04338d25abfa@github.com>

On Mon, 3 Mar 2025 15:24:05 GMT, Chen Liang  wrote:

> After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a remove happened, and proceed to install an outdated value onto a CV.
> 
> The fix is simple - to force computation to retry when a remove has happened, so the retry can observe the up-to-date states from the remove. (finishEntry and removeEntry are both synchronized on the object monitor of the ClassValueMap instance)

This pull request has now been integrated.

Changeset: e71f3274
Author:    Chen Liang 
URL:       https://git.openjdk.org/jdk/commit/e71f3274a9de4006bc8cdfe4ba1bd12a8867a11a
Stats:     81 lines in 2 files changed: 61 ins; 3 del; 17 mod

8351045: ClassValue::remove cannot ensure computation observes up-to-date state

Reviewed-by: rriggs, jrose

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

PR: https://git.openjdk.org/jdk/pull/23866

From dl at openjdk.org  Tue Mar 11 20:29:20 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 11 Mar 2025 20:29:20 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v9]
In-Reply-To: 
References: 
Message-ID: 

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Use SharedSecrets for ThreadLocalRandomProbe; other tweaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/6fe1a3bd..9cc670bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=07-08

  Stats: 60 lines in 5 files changed: 19 ins; 17 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From dl at openjdk.org  Tue Mar 11 20:29:20 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 11 Mar 2025 20:29:20 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v8]
In-Reply-To: <1d1ZRw0a3t-wbC1p2g4wAWXH2bj6yn6NTaYFFedWCB0=.9ccce271-4ea9-4ec6-93e6-3e3539c1436e@github.com>
References: 
 
 
 <1d1ZRw0a3t-wbC1p2g4wAWXH2bj6yn6NTaYFFedWCB0=.9ccce271-4ea9-4ec6-93e6-3e3539c1436e@github.com>
Message-ID: 

On Tue, 11 Mar 2025 13:46:52 GMT, Viktor Klang  wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1301:
>> 
>>> 1299:                 if ((room == 0 ||        // pad if no caller-run
>>> 1300:                      a[m & (s - ((internal || task == null ||
>>> 1301:                                   task.noUserHelp() == 0) ? 1 : 2))] == null) &&
>> 
>> Not saying that we should, but it would be possible to make this branch-free.
>
> Something like `1 + (task.noUserHelp() >>> 24)`

Right; thanks. Also moving the (nonvolatile) read up seems slightly better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1990080545

From jpai at openjdk.org  Wed Mar 12 06:30:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:30:11 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v3]
In-Reply-To: 
References: 
Message-ID: 

> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
> 
> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
> 
> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
> 
> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
> 
> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
> 
> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  rename field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23986/files
  - new: https://git.openjdk.org/jdk/pull/23986/files/b9734fa4..b6486e7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=01-02

  Stats: 28 lines in 1 file changed: 7 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/23986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23986/head:pull/23986

PR: https://git.openjdk.org/jdk/pull/23986

From jpai at openjdk.org  Wed Mar 12 06:34:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:34:52 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
References: 
 
 <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
Message-ID: 

On Tue, 11 Mar 2025 15:28:59 GMT, Eirik Bj?rsn?s  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tiny typo fix in newly introduced documentation
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 87:
> 
>> 85:     // the ZipCoder instance is derived from the Charset passed to the ZipFile constructor
>> 86:     // and will be used for decoding the non-UTF-8 entry names and the ZIP file comment.
>> 87:     private final ZipCoder entryNameCommentCoder;
> 
> The Source `ZipCoder` field had a `@Stable` annotation. Any reason why this did not survive the move?

Hello Eirik, the `ZipCoder` field here is `final` so it's doesn't require a `@Stable` annotation. I realize this field in `Source` too was `final` and yet it was annotated `@Stable`, but my understanding is that, that was redundant and unnecessary. The documentation of `@Stable` states that a `@Stable` for `final` fields is only relevant when the field is a array type, which it isn't in the case here.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 87:
> 
>> 85:     // the ZipCoder instance is derived from the Charset passed to the ZipFile constructor
>> 86:     // and will be used for decoding the non-UTF-8 entry names and the ZIP file comment.
>> 87:     private final ZipCoder entryNameCommentCoder;
> 
> Since we do not have separate ZipCoders for decoding the different ZIP values, I'm not sure it's useful to put the field names ("name"/"comment") into the instance field name here. Especially if the comment already has this information.
> 
> Could we call this just `zc` or `zipCoder`?

I have now renamed the field to `zipCoder`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1990700514
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1990700773

From jpai at openjdk.org  Wed Mar 12 06:40:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:40:57 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
References: 
 
 <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
Message-ID: 

On Tue, 11 Mar 2025 15:32:53 GMT, Eirik Bj?rsn?s  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tiny typo fix in newly introduced documentation
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1222:
> 
>> 1220:                 table[hsh] = index;
>> 1221:                 // Record the CEN offset and the name hash in our hash cell.
>> 1222:                 entries[index] = hash;
> 
> Seems unrelated to the issue at hand. Perhaps better left for a separate PR, backed by a benchmark.

This isn't a performance related change. I merely marked the method parameters as `final` and the `index` method parameter was being updated here.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1426:
> 
>> 1424:             private final Charset entryNameCommentCharset;
>> 1425: 
>> 1426:             public Key(File file, BasicFileAttributes attrs, Charset entryNameCommentCharset) {
> 
> I feel this parameter and the field it is assigned to could also just be called `charset`. The comment has the information about what it's used for.

I've updated the PR to rename this to `charset`.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1434:
> 
>> 1432:             @Override
>> 1433:             public int hashCode() {
>> 1434:                 long t = entryNameCommentCharset.hashCode();
> 
> This represents a behavioral change, right? Is a CSR warranted?
> 
> EDIT: Scratch that, I guess the caching mechanism here is unspecified and and more of implementation detail.

This is an internal implementation detail, so doesn't require a CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1990706483
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1990704378
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1990704708

From jpai at openjdk.org  Wed Mar 12 06:50:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:50:08 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset
In-Reply-To: 
References: 
 <8EmcrMETQOdPlKHRPsTFwy39RJZDid47IfalaSoMPOc=.24ace49b-11d3-4c8c-b083-8d51554726c4@github.com>
 
 
Message-ID: <9en2Wch4PqTjqdikK57Gk68BmQvJaPUITd1dm1NBJQ8=.aaee8778-81d9-487c-9109-d1441b937b38@github.com>

On Tue, 11 Mar 2025 16:09:37 GMT, Eirik Bj?rsn?s  wrote:

> > Agreed. I've officially marked this as requiring 2 reviewers.
> 
> Did you mean to do `/reviewers 2 reviewer` ?

I didn't know there was a difference, but reading through the skara command documentation, it appears there is. So I've now marked this PR appropriately.

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

PR Comment: https://git.openjdk.org/jdk/pull/23986#issuecomment-2716712118

From jpai at openjdk.org  Wed Mar 12 06:50:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:50:09 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
References: 
 
 <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
Message-ID: 

On Tue, 11 Mar 2025 15:31:09 GMT, Eirik Bj?rsn?s  wrote:

> This seems mostly used to determine which ZipCoder to pick. Could we fold this into the method, calling it zipCoderForPos and make it just return the ZipCoder, like we had in Source?

I intentionally removed the `zipCoderForPos()` method and instead introduced this static method to avoid the case where the code ends up calling this method and then stores the returned `ZipCoder` (like was being done in `Source`). Instead with this new method, it now allows the call sites to determine if a UTF8 `ZipCoder` is needed or a non-UTF8 one and then decide where to get the non-UTF8 `ZipCoder` from. If the call site is a instance method in `ZipFile`, then it was use the `ZipFile`'s `zipCoder` field and if the call site is within `Source`, when the `Source` is being instantiated then it constructs a non-UTF8 `ZipCoder` afresh. That level of detail is better dealt at the call site instead of a method like `zipCoderForPos()`.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1744:
> 
>> 1742: 
>> 1743:                 int entryPos = pos + CENHDR;
>> 1744:                 final ZipCoder entryZipCoder;
> 
> If you want to construct this lazily, then I think a comment documenting that purpose would be useful here.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1990711952
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1990713465

From jpai at openjdk.org  Wed Mar 12 06:50:08 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:50:08 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v4]
In-Reply-To: 
References: 
Message-ID: 

> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
> 
> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
> 
> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
> 
> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
> 
> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
> 
> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now maintained in the `ZipFile`,...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add code comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23986/files
  - new: https://git.openjdk.org/jdk/pull/23986/files/b6486e7a..935b04ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23986&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23986/head:pull/23986

PR: https://git.openjdk.org/jdk/pull/23986

From jpai at openjdk.org  Wed Mar 12 07:16:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 07:16:01 GMT
Subject: RFR: 8351435: Change JLine Console implementation back to opt-in
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Mar 2025 18:32:10 GMT, Naoto Sato  wrote:

> JDK has been using JLine based Console implementation, in JDK20 as opt-in, then in JDK22 as the default. While it has been providing rich functionality for Console, it is increasingly difficult to maintain as a Console implementation. In light of the on-ramp feature (https://bugs.openjdk.org/browse/JDK-8344699), which proposes switching `java.lang.IO` class to use `System.in` and `System.out` instead of Console, reverting the default Console implementation to JDK's built-in one in the java.base module is considered desirable. Some tests are modified along with this change, among them test/jdk/java/io/Console/ConsolePromptTest.java changes were contributed by @lahodaj (thanks!)

test/jdk/java/io/Console/ConsolePromptTest.java line 77:

> 75:         var expect = Paths.get("/usr/bin/expect");
> 76:         if (!Files.exists(expect) || !Files.isExecutable(expect)) {
> 77:             System.out.println("'expect' command not found. Test ignored.");

Hello Naoto, I think throwing a `jtreg.SkippedException` might be better here so that it's clear that the test was skipped. There have been recent reporting improvements too which make it easier to notice such skipped tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23993#discussion_r1990775475

From mcimadamore at openjdk.org  Wed Mar 12 11:19:05 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Mar 2025 11:19:05 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v6]
In-Reply-To: <-WEuzvT_PM7fZzOpGN5mOklreiP0mK_QQLgltNc8h90=.6fb1f429-3af6-4abb-8e6f-bbbc18796d7a@github.com>
References: 
 <-WEuzvT_PM7fZzOpGN5mOklreiP0mK_QQLgltNc8h90=.6fb1f429-3af6-4abb-8e6f-bbbc18796d7a@github.com>
Message-ID: <2JJ0sJ1MGtr-vye3gnti4amFtXj2G0cY3k0vVR1PLfg=.3e2164b5-36b4-4c01-8946-47f8b7bbdce3@github.com>

On Fri, 7 Mar 2025 17:38:13 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch improves the performance of a typical `Arena::allocate` in several ways:
>> 
>> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
>> - Split the allocation of over-aligned memory to a slow-path method.
>> - Align the memory to 8 bytes, allowing faster zeroing.
>> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
>> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge branch 'master' into segmentallocate
>  - revert changes to CallocArena
>  - Merge branch 'master' into segmentallocate
>  - copyright
>  - Merge branch 'master' into segmentallocate
>  - wrong init
>  - move segment instance creation to SegmentFactories
>  - address review
>  - improve the implementation of SegmentFactories::allocateSegment

Looks good - just left a minor (optional) stylistic comment

test/micro/org/openjdk/bench/java/lang/foreign/AllocTest.java line 26:

> 24: package org.openjdk.bench.java.lang.foreign;
> 25: 
> 26: import java.lang.foreign.*;

I believe it would be better to leave the imports alone -- as all the other benchmarks also use the "more explicit" style.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22610#pullrequestreview-2678029020
PR Review Comment: https://git.openjdk.org/jdk/pull/22610#discussion_r1991245773

From tschatzl at openjdk.org  Wed Mar 12 11:58:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 12 Mar 2025 11:58:45 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v17]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * optimized RISCV gen_write_ref_array_post_barrier() implementation contributed by @RealFYang
 - * fix card table verification crashes: in the first refinement phase, when switching the global card tables, we need to re-check whether we are still in the same sweep epoch or not. It might have changed due to a GC interrupting acquiring the Heap_lock. Otherwise new threads will scribble on the refinement table.
   Cause are last-minute changes before making the PR ready to review.
   
     Testing: without the patch, occurs fairly frequently when continuously
   (1 in 20) starting refinement. Does not afterward.
 - * ayang review 3
     * comments
     * minor refactorings
 - * iwalulya review
     * renaming
     * fix some includes, forward declaration
 - * fix whitespace
   * additional whitespace between log tags
   * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename
 - ayang review
     * renamings
     * refactorings
 - iwalulya review
     * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
     * predicate for determining whether the refinement has been disabled
     * some other typos/comment improvements
     * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
 - * ayang review - fix comment
 - * iwalulya review 2
     * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
     * some additional documentation
 - ... and 14 more: https://git.openjdk.org/jdk/compare/f77fa17b...aec95051

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/758fac01..aec95051

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=15-16

  Stats: 78123 lines in 1539 files changed: 36243 ins; 29177 del; 12703 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From ayang at openjdk.org  Wed Mar 12 13:33:59 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Mar 2025 13:33:59 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v14]
In-Reply-To: <5w6qUwzDQadxseocRl6rRF0AllyeukWTpYl2XjAfiTE=.fb62a50e-e308-4d08-8057-67e70e13ccbb@github.com>
References: 
 
 <5w6qUwzDQadxseocRl6rRF0AllyeukWTpYl2XjAfiTE=.fb62a50e-e308-4d08-8057-67e70e13ccbb@github.com>
Message-ID: 

On Fri, 7 Mar 2025 13:14:02 GMT, Albert Mingkun Yang  wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * iwalulya review
>>     * renaming
>>     * fix some includes, forward declaration
>
> src/hotspot/share/gc/g1/g1CardTable.hpp line 76:
> 
>> 74:     g1_card_already_scanned = 0x1,
>> 75:     g1_to_cset_card = 0x2,
>> 76:     g1_from_remset_card = 0x4
> 
> Could you outline the motivation for this more precise info? Is it for optimization or essentially for correctness?

OK, it's for better performance, not correctness. How much is the improvement? As I understand it, this more precise info is largely independent of the new barrier logic. I wonder if it makes sense to extract this out to its own ticket to better assess its impact on perf and impl complexity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1991375754

From ayang at openjdk.org  Wed Mar 12 13:34:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Mar 2025 13:34:04 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v17]
In-Reply-To: 
References: 
 
Message-ID: <0w7seS1tIFhUxnmStxQySISWVfpBBsRmUtx7EoTy9a4=.509a3d5e-56d0-4fd8-8896-51835b14302b@github.com>

On Wed, 12 Mar 2025 11:58:45 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>  - * optimized RISCV gen_write_ref_array_post_barrier() implementation contributed by @RealFYang
>  - * fix card table verification crashes: in the first refinement phase, when switching the global card tables, we need to re-check whether we are still in the same sweep epoch or not. It might have changed due to a GC interrupting acquiring the Heap_lock. Otherwise new threads will scribble on the refinement table.
>    Cause are last-minute changes before making the PR ready to review.
>    
>      Testing: without the patch, occurs fairly frequently when continuously
>    (1 in 20) starting refinement. Does not afterward.
>  - * ayang review 3
>      * comments
>      * minor refactorings
>  - * iwalulya review
>      * renaming
>      * fix some includes, forward declaration
>  - * fix whitespace
>    * additional whitespace between log tags
>    * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename
>  - ayang review
>      * renamings
>      * refactorings
>  - iwalulya review
>      * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>      * predicate for determining whether the refinement has been disabled
>      * some other typos/comment improvements
>      * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
>  - * ayang review - fix comment
>  - * iwalulya review 2
>      * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
>      * some additional documentation
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/53a66058...aec95051

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 217:

> 215: 
> 216:   {
> 217:     SuspendibleThreadSetLeaver sts_leave;

Can you add some comment on why leaving the set is required? It's not obvious to me why. I'd expect handshake to work out of the box...

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 263:

> 261: 
> 262:     SuspendibleThreadSetLeaver sts_leave;
> 263:     VMThread::execute(&op);

Can you elaborate what synchronization this VM op is trying to achieve?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1991489399
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1991382024

From tschatzl at openjdk.org  Wed Mar 12 14:00:15 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 12 Mar 2025 14:00:15 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v17]
In-Reply-To: <0w7seS1tIFhUxnmStxQySISWVfpBBsRmUtx7EoTy9a4=.509a3d5e-56d0-4fd8-8896-51835b14302b@github.com>
References: 
 
 <0w7seS1tIFhUxnmStxQySISWVfpBBsRmUtx7EoTy9a4=.509a3d5e-56d0-4fd8-8896-51835b14302b@github.com>
Message-ID: 

On Wed, 12 Mar 2025 12:23:50 GMT, Albert Mingkun Yang  wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - * optimized RISCV gen_write_ref_array_post_barrier() implementation contributed by @RealFYang
>>  - * fix card table verification crashes: in the first refinement phase, when switching the global card tables, we need to re-check whether we are still in the same sweep epoch or not. It might have changed due to a GC interrupting acquiring the Heap_lock. Otherwise new threads will scribble on the refinement table.
>>    Cause are last-minute changes before making the PR ready to review.
>>    
>>      Testing: without the patch, occurs fairly frequently when continuously
>>    (1 in 20) starting refinement. Does not afterward.
>>  - * ayang review 3
>>      * comments
>>      * minor refactorings
>>  - * iwalulya review
>>      * renaming
>>      * fix some includes, forward declaration
>>  - * fix whitespace
>>    * additional whitespace between log tags
>>    * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename
>>  - ayang review
>>      * renamings
>>      * refactorings
>>  - iwalulya review
>>      * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>>      * predicate for determining whether the refinement has been disabled
>>      * some other typos/comment improvements
>>      * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
>>  - * ayang review - fix comment
>>  - * iwalulya review 2
>>      * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
>>      * some additional documentation
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/5727f166...aec95051
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 263:
> 
>> 261: 
>> 262:     SuspendibleThreadSetLeaver sts_leave;
>> 263:     VMThread::execute(&op);
> 
> Can you elaborate what synchronization this VM op is trying to achieve?

Memory visibility for refinement threads for the references written to the heap. Without them, they may not have received the most recent values.
This is the same as the `StoreLoad` barriers synchronization between mutator and refinement threads imo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1991561707

From vaivanov at openjdk.org  Wed Mar 12 15:59:26 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 12 Mar 2025 15:59:26 GMT
Subject: RFR: 8351593: [JMH] test PhoneCode.Bulk reports NPE exception
Message-ID: 

the test output was cleanup for common execution.

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

Commit messages:
 - JDK-8351593 [JMH] test PhoneCode.Bulk reports NPE exception

Changes: https://git.openjdk.org/jdk/pull/24011/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24011&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351593
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24011/head:pull/24011

PR: https://git.openjdk.org/jdk/pull/24011

From sgehwolf at openjdk.org  Wed Mar 12 16:45:14 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Mar 2025 16:45:14 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 20 Feb 2025 14:22:20 GMT, Severin Gehwolf  wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Fix missing imports
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Add exclusive access dirs directive for systemd tests
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/e1d0a9c8...74abae5b

Keep open, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2718491360

From naoto at openjdk.org  Wed Mar 12 17:02:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Mar 2025 17:02:02 GMT
Subject: RFR: 8351435: Change JLine Console implementation back to opt-in
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <93JkbRKTW8GXjaqsCy0cuC3-co2uIruLZOKbFNJJ-Ho=.c5a3ffad-bf72-4060-9f46-f9b8acb4e107@github.com>

On Wed, 12 Mar 2025 07:13:19 GMT, Jaikiran Pai  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comment
>
> test/jdk/java/io/Console/ConsolePromptTest.java line 77:
> 
>> 75:         var expect = Paths.get("/usr/bin/expect");
>> 76:         if (!Files.exists(expect) || !Files.isExecutable(expect)) {
>> 77:             System.out.println("'expect' command not found. Test ignored.");
> 
> Hello Naoto, I think throwing a `jtreg.SkippedException` might be better here so that it's clear that the test was skipped. There have been recent reporting improvements too which make it easier to notice such skipped tests.

Good point. Modified the piece (w/ some other minor changes)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23993#discussion_r1991925846

From naoto at openjdk.org  Wed Mar 12 17:02:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Mar 2025 17:02:01 GMT
Subject: RFR: 8351435: Change JLine Console implementation back to opt-in
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> JDK has been using JLine based Console implementation, in JDK20 as opt-in, then in JDK22 as the default. While it has been providing rich functionality for Console, it is increasingly difficult to maintain as a Console implementation. In light of the on-ramp feature (https://bugs.openjdk.org/browse/JDK-8344699), which proposes switching `java.lang.IO` class to use `System.in` and `System.out` instead of Console, reverting the default Console implementation to JDK's built-in one in the java.base module is considered desirable. Some tests are modified along with this change, among them test/jdk/java/io/Console/ConsolePromptTest.java changes were contributed by @lahodaj (thanks!)

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23993/files
  - new: https://git.openjdk.org/jdk/pull/23993/files/960e6dc5..92c9a344

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23993&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23993&range=00-01

  Stats: 19 lines in 1 file changed: 10 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23993/head:pull/23993

PR: https://git.openjdk.org/jdk/pull/23993

From tschatzl at openjdk.org  Wed Mar 12 17:44:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 12 Mar 2025 17:44:01 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v17]
In-Reply-To: <0w7seS1tIFhUxnmStxQySISWVfpBBsRmUtx7EoTy9a4=.509a3d5e-56d0-4fd8-8896-51835b14302b@github.com>
References: 
 
 <0w7seS1tIFhUxnmStxQySISWVfpBBsRmUtx7EoTy9a4=.509a3d5e-56d0-4fd8-8896-51835b14302b@github.com>
Message-ID: 

On Wed, 12 Mar 2025 13:20:25 GMT, Albert Mingkun Yang  wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - * optimized RISCV gen_write_ref_array_post_barrier() implementation contributed by @RealFYang
>>  - * fix card table verification crashes: in the first refinement phase, when switching the global card tables, we need to re-check whether we are still in the same sweep epoch or not. It might have changed due to a GC interrupting acquiring the Heap_lock. Otherwise new threads will scribble on the refinement table.
>>    Cause are last-minute changes before making the PR ready to review.
>>    
>>      Testing: without the patch, occurs fairly frequently when continuously
>>    (1 in 20) starting refinement. Does not afterward.
>>  - * ayang review 3
>>      * comments
>>      * minor refactorings
>>  - * iwalulya review
>>      * renaming
>>      * fix some includes, forward declaration
>>  - * fix whitespace
>>    * additional whitespace between log tags
>>    * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename
>>  - ayang review
>>      * renamings
>>      * refactorings
>>  - iwalulya review
>>      * comments for variables tracking to-collection-set and just dirtied cards after GC/refinement
>>      * predicate for determining whether the refinement has been disabled
>>      * some other typos/comment improvements
>>      * renamed _has_xxx_ref to _has_ref_to_xxx to be more consistent with naming
>>  - * ayang review - fix comment
>>  - * iwalulya review 2
>>      * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSweepState
>>      * some additional documentation
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/0c7b5abb...aec95051
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 217:
> 
>> 215: 
>> 216:   {
>> 217:     SuspendibleThreadSetLeaver sts_leave;
> 
> Can you add some comment on why leaving the set is required? It's not obvious to me why. I'd expect handshake to work out of the box...

It isn't apparently. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1991999476

From tschatzl at openjdk.org  Wed Mar 12 17:59:51 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 12 Mar 2025 17:59:51 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v18]
In-Reply-To: 
References: 
Message-ID: <3KOwgdzYn_vXQVWisVUEY-0i1gtZEfZhcD1-id3epYE=.17aa84bc-a7ec-4dda-b596-7a1016d710fc@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * ayang review
    * remove unnecessary STSleaver
    * some more documentation around to_collection_card card color

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/aec95051..3766b76c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=16-17

  Stats: 18 lines in 2 files changed: 5 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From eirbjo at openjdk.org  Wed Mar 12 18:26:00 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 12 Mar 2025 18:26:00 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: 
References: 
 
 <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
 
Message-ID: <9t0wyVnW-ITY2BrsnpvMCnrWuNt3RaP8wUo9VBycq2A=.fb616b79-c1cf-4234-9c7a-5b9af5f23410@github.com>

On Wed, 12 Mar 2025 06:42:43 GMT, Jaikiran Pai  wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 376:
>> 
>>> 374:      * @param pos the entry position
>>> 375:      */
>>> 376:     private static boolean useUTF8Coder(final byte[] cen, final int pos) {
>> 
>> This seems mostly used to determine which `ZipCoder` to pick. Could we fold this into the method, calling it `zipCoderForPos` and make it just return the `ZipCoder`, like we had in `Source`?
>> 
>> If it needs to be static, then the non-UTF8/fallback ZipCoder could be passed as a parameter?
>> 
>> If a method to determine whether a CEN entry uses UTF-8 is still needed, then I think it would be more appropriately named  `isUTF8Entry`.
>
>> This seems mostly used to determine which ZipCoder to pick. Could we fold this into the method, calling it zipCoderForPos and make it just return the ZipCoder, like we had in Source?
> 
> I intentionally removed the `zipCoderForPos()` method and instead introduced this static method to avoid the case where the code ends up calling this method and then stores the returned `ZipCoder` (like was being done in `Source`). Instead with this new method, it now allows the call sites to determine if a UTF8 `ZipCoder` is needed or a non-UTF8 one and then decide where to get the non-UTF8 `ZipCoder` from. If the call site is a instance method in `ZipFile`, then it was use the `ZipFile`'s `zipCoder` field and if the call site is within `Source`, when the `Source` is being instantiated then it constructs a non-UTF8 `ZipCoder` afresh. That level of detail is better dealt at the call site instead of a method like `zipCoderForPos()`.

Hello Jaikiran,

I'm not convinced dropping `zipCoderForPos` is a step forward:

* `zipCoderForPos` included a short-circuit optimization logic which skipped reading the CENFLG field in the case where the opening charset was UTF-8 (which it commonly is, and always for JarFile). This optimization seems lost in the currrent state of this PR and could impact lookup performance. It would be strange to repeat this optimization at all call sites.
* The only thing differing between callsites seems to be which ZipCoder to use as a "fallback" when it's not UTF-8. This ZipCoder instance can easilly be passed in as a parameter, and will de-duplicate logic at the call sites.
* The only "cumbersome" call site seems to be `initCEN`, caused by the lazy initialization of the non-UTF-8 ZipCoder. But that lazy initialization seems questionable: First, ZipCoder is already lazy in the way it initializes encoders and decoders. An unused ZipCoder is just a thin wrapper around a Charset and should not incur significant cost until it gets used. Second, the `ZipFile` constructor actually constructs a `ZipCoder` instance, would it not be better to just pass this down to initCEN as a parameter? That would avoid the cost of initializing encoders and decoders twice for the common case of single-threaded `ZipFile` access, once for initCEN, then again on the first lookup.  

Here's a patch for a quick implementation of the above on top of your PR. (Code speeks better than words some times :-)

This retains the CENFLG optimization, simplifies logic at call sites and prevents duplicated initialization of ZipCoder beteween initCEN and lookups:


Index: src/java.base/share/classes/java/util/zip/ZipFile.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java
--- a/src/java.base/share/classes/java/util/zip/ZipFile.java	(revision 935b04ed00522aa92105292baa0693c55b1356ae)
+++ b/src/java.base/share/classes/java/util/zip/ZipFile.java	(date 1741800197915)
@@ -201,8 +201,8 @@
         this.fileName = file.getName();
         long t0 = System.nanoTime();
 
-        this.res = new CleanableResource(this, charset, file, mode);
         this.zipCoder = ZipCoder.get(charset);
+        this.res = new CleanableResource(this, charset, zipCoder, file, mode);
 
         PerfCounter.getZipFileOpenTime().addElapsedTimeFrom(t0);
         PerfCounter.getZipFileCount().increment();
@@ -368,13 +368,19 @@
     }
 
     /**
-     * {@return true if the ZIP entry corresponding to the given {@code pos} uses UTF-8
-     * for entry name and comment field encoding, false otherwise}
+     * {@return a ZipCoder for decoding name and comment fields for the given CEN entry position}
      * @param cen the CEN
      * @param pos the entry position
+     * @param fallback the ZipCoder to return when the entry is not flagged as UTF-8
      */
-    private static boolean useUTF8Coder(final byte[] cen, final int pos) {
-        return (CENFLG(cen, pos) & USE_UTF8) != 0;
+    private static ZipCoder zipCoderFor(final byte[] cen, final int pos, ZipCoder fallback) {
+        if (fallback.isUTF8()) {
+            return ZipCoder.UTF8;
+        }
+        if ((CENFLG(cen, pos) & USE_UTF8) != 0) {
+            return ZipCoder.UTF8;
+        }
+        return fallback;
     }
 
     private static class InflaterCleanupAction implements Runnable {
@@ -575,7 +581,7 @@
     private String getEntryName(int pos) {
         byte[] cen = res.zsrc.cen;
         int nlen = CENNAM(cen, pos);
-        ZipCoder zc = useUTF8Coder(cen, pos) ? ZipCoder.UTF8 : zipCoder;
+        ZipCoder zc = zipCoderFor(cen, pos, zipCoder);
         return zc.toString(cen, pos + CENHDR, nlen);
     }
 
@@ -646,7 +652,7 @@
         }
         if (clen != 0) {
             int start = pos + CENHDR + nlen + elen;
-            ZipCoder zc = useUTF8Coder(cen, pos) ? ZipCoder.UTF8 : zipCoder;
+            ZipCoder zc = zipCoderFor(cen, pos, zipCoder);
             e.comment = zc.toString(cen, start, clen);
         }
         lastEntryName = e.name;
@@ -678,11 +684,11 @@
 
         Source zsrc;
 
-        CleanableResource(ZipFile zf, Charset charset, File file, int mode) throws IOException {
+        CleanableResource(ZipFile zf, Charset charset, ZipCoder zipCoder, File file, int mode) throws IOException {
             this.cleanable = CleanerFactory.cleaner().register(zf, this);
             this.istreams = Collections.newSetFromMap(new WeakHashMap<>());
             this.inflaterCache = new ArrayDeque<>();
-            this.zsrc = Source.get(file, (mode & OPEN_DELETE) != 0, charset);
+            this.zsrc = Source.get(file, (mode & OPEN_DELETE) != 0, charset, zipCoder);
         }
 
         void clean() {
@@ -1472,7 +1478,7 @@
         private static final java.nio.file.FileSystem builtInFS =
                 DefaultFileSystemProvider.theFileSystem();
 
-        static Source get(File file, boolean toDelete, Charset charset) throws IOException {
+        static Source get(File file, boolean toDelete, Charset charset, ZipCoder zipCoder) throws IOException {
             final Key key;
             try {
                 key = new Key(file,
@@ -1489,7 +1495,7 @@
                     return src;
                 }
             }
-            src = new Source(key, toDelete);
+            src = new Source(key, toDelete, zipCoder);
 
             synchronized (files) {
                 Source prev = files.putIfAbsent(key, src);
@@ -1511,7 +1517,7 @@
             }
         }
 
-        private Source(Key key, boolean toDelete) throws IOException {
+        private Source(Key key, boolean toDelete, ZipCoder zipCoder) throws IOException {
             this.key = key;
             if (toDelete) {
                 if (OperatingSystem.isWindows()) {
@@ -1525,7 +1531,7 @@
                 this.zfile = new RandomAccessFile(key.file, "r");
             }
             try {
-                initCEN(-1);
+                initCEN(-1, zipCoder);
                 byte[] buf = new byte[4];
                 readFullyAt(buf, 0, 4, 0);
                 this.startsWithLoc = (LOCSIG(buf) == LOCSIG);
@@ -1680,7 +1686,7 @@
         }
 
         // Reads ZIP file central directory.
-        private void initCEN(int knownTotal) throws IOException {
+        private void initCEN(int knownTotal, ZipCoder zipCoder) throws IOException {
             // Prefer locals for better performance during startup
             byte[] cen;
             if (knownTotal == -1) {
@@ -1736,31 +1742,19 @@
             int idx = 0; // Index into the entries array
             int pos = 0;
             manifestNum = 0;
-            ZipCoder zipCoder = null;
             int limit = cen.length - CENHDR;
             while (pos <= limit) {
                 if (idx >= entriesLength) {
                     // This will only happen if the ZIP file has an incorrect
                     // ENDTOT field, which usually means it contains more than
                     // 65535 entries.
-                    initCEN(countCENHeaders(cen));
+                    initCEN(countCENHeaders(cen), zipCoder);
                     return;
                 }
 
                 int entryPos = pos + CENHDR;
-                // the ZipCoder for any non-UTF8 entries
-                final ZipCoder entryZipCoder;
-                if (useUTF8Coder(cen, pos)) {
-                    // entry name explicitly wants UTF-8 Charset
-                    entryZipCoder = ZipCoder.UTF8;
-                } else {
-                    // use the ZipCoder corresponding to the Charset that
-                    // was provided when constructing the ZipFile
-                    if (zipCoder == null) {
-                        zipCoder = ZipCoder.get(key.charset);
-                    }
-                    entryZipCoder = zipCoder;
-                }
+                // the ZipCoder for this entry
+                final ZipCoder entryZipCoder = zipCoderFor(cen, pos, zipCoder);
                 // Checks the entry and adds values to entries[idx ... idx+2]
                 int nlen = checkAndAddEntry(pos, idx, entryZipCoder);
                 idx += 3;
@@ -1853,15 +1847,7 @@
                     int noff = pos + CENHDR;
                     int nlen = CENNAM(cen, pos);
 
-                    final ZipCoder zc;
-                    if (useUTF8Coder(cen, pos)) {
-                        // entry name explicitly wants UTF-8 Charset
-                        zc = ZipCoder.UTF8;
-                    } else {
-                        // use the ZipCoder corresponding to the Charset that
-                        // was provided when constructing the ZipFile
-                        zc = zipCoder;
-                    }
+                    final ZipCoder zc = zipCoderFor(cen, pos, zipCoder);
                     // Compare the lookup name with the name encoded in the CEN
                     switch (zc.compare(name, cen, noff, nlen, addSlash)) {
                         case ZipCoder.EXACT_MATCH:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1992069024

From kbarrett at openjdk.org  Wed Mar 12 19:59:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Mar 2025 19:59:52 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 Mar 2025 23:14:23 GMT, Brent Christian  wrote:

>> Please review this revision of a previously puzzling comment intending to
>> provide the rationale for a bit of non-obvious code.
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 142:
> 
>> 140:                 // while there are registered cleanables for other objects.
>> 141:                 // If the application cleans all remaining cleanables, there
>> 142:                 // won't be any references enqueued to unblock this.  Using a
> 
> I agree that calling `queue.remove()` with a timeout is the right approach.
> But I have a question:
> In the case where the Cleaner's `CleanerCleanable` has already run, and we get to processing the last registered cleanable on `activeList`:
> When we do the `ref.clean()`, the `activeList` becomes empty, and we'll drop out of the `while()` loop. So I'm not seeing how we would attempt another `queue.remove()` in this case.
> What am I missing?

You are missing that this loop is not the only place that potentially removes
references from `activeList`. The application may also do so, when directly
cleaning (as part of a `close()` operation or the like). So the cleaner's
cleanable may be dropped, removed, and cleaned but with live entries still in
`activeList`, and this loop ends up blocked in `remove` because there's
nothing for it to do.  The application later closes all of the remaining
entries in the `activeList`, which doesn't cause anything to be enqueued on
the cleaner's queue, so the cleaner thread remains blocked in `remove`.  But
now `activeList` is empty and will never be added to, and the queue is also
empty, and the thread is blocked in `remove` with nothing (other than the
timeout) to break it out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23952#discussion_r1992205243

From duke at openjdk.org  Wed Mar 12 21:37:03 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Mar 2025 21:37:03 GMT
Subject: Withdrawn: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com>
References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com>
Message-ID: 

On Mon, 13 Jan 2025 16:28:52 GMT, Viktor Klang  wrote:

> Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23081

From acobbs at openjdk.org  Thu Mar 13 01:26:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 13 Mar 2025 01:26:38 GMT
Subject: RFR: 8351897: Extra closing curly brace typos in Javadoc
Message-ID: 

This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

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

Commit messages:
 - Fix minor Javadoc typos.

Changes: https://git.openjdk.org/jdk/pull/24022/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24022&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351897
  Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24022/head:pull/24022

PR: https://git.openjdk.org/jdk/pull/24022

From naoto at openjdk.org  Thu Mar 13 01:38:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Mar 2025 01:38:52 GMT
Subject: RFR: 8351897: Extra closing curly brace typos in Javadoc
In-Reply-To: 
References: 
Message-ID: 

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs  wrote:

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

The change in `MessageFormat.java` looks good

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

PR Review: https://git.openjdk.org/jdk/pull/24022#pullrequestreview-2680224832

From iris at openjdk.org  Thu Mar 13 01:50:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 13 Mar 2025 01:50:52 GMT
Subject: RFR: 8351897: Extra closing curly brace typos in Javadoc
In-Reply-To: 
References: 
Message-ID: 

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs  wrote:

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

src/java.base/share/classes/java/text/MessageFormat.java line 327:

> 325:  *       {@code unit}
> 326:  *       {@link ListFormat#getInstance(Locale, ListFormat.Type, ListFormat.Style)
> 327:  *       ListFormat.getInstance}{@code (getLocale()}, {@link ListFormat.Type#UNIT}, {@link ListFormat.Style#FULL})

The new ')' at the end of the line.  Where's the matching '('?  I'm guessing that the IDE thinks it's the one immediately before the `getLocale()`, but I suspect that javadoc won't agree with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24022#discussion_r1992525288

From acobbs at openjdk.org  Thu Mar 13 01:59:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 13 Mar 2025 01:59:51 GMT
Subject: RFR: 8351897: Extra closing curly brace typos in Javadoc
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 01:46:53 GMT, Iris Clark  wrote:

> Where's the matching `(`?  I'm guessing that the IDE thinks it's the one immediately before the `getLocale()`, but I suspect that javadoc won't agree with that.

You are correct - the matching `(` is the one preceding `getLocale()`.

I'm not sure what you mean by "I suspect that javadoc won't agree with that". This change is simply making this row of the table consistent with the ones above it. You can see how they currently appear [here](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/text/MessageFormat.html). In this row, the closing `}` should have been a `)`.

Thanks for taking a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24022#discussion_r1992531755

From qamai at openjdk.org  Thu Mar 13 05:46:44 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 05:46:44 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v7]
In-Reply-To: 
References: 
Message-ID: <0_1SZd0VVSYj61Zc71DqxZMrfRWIgfrmCPou_AS2DYc=.9156ec5f-fac3-4ff3-9261-f576414372fc@github.com>

> Hi,
> 
> This patch improves the performance of a typical `Arena::allocate` in several ways:
> 
> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
> - Split the allocation of over-aligned memory to a slow-path method.
> - Align the memory to 8 bytes, allowing faster zeroing.
> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  expand wildcard imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22610/files
  - new: https://git.openjdk.org/jdk/pull/22610/files/e82cc493..dba7ae14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22610&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22610&range=05-06

  Stats: 17 lines in 1 file changed: 14 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22610.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22610/head:pull/22610

PR: https://git.openjdk.org/jdk/pull/22610

From qamai at openjdk.org  Thu Mar 13 09:07:58 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 09:07:58 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v6]
In-Reply-To: <2JJ0sJ1MGtr-vye3gnti4amFtXj2G0cY3k0vVR1PLfg=.3e2164b5-36b4-4c01-8946-47f8b7bbdce3@github.com>
References: 
 <-WEuzvT_PM7fZzOpGN5mOklreiP0mK_QQLgltNc8h90=.6fb1f429-3af6-4abb-8e6f-bbbc18796d7a@github.com>
 <2JJ0sJ1MGtr-vye3gnti4amFtXj2G0cY3k0vVR1PLfg=.3e2164b5-36b4-4c01-8946-47f8b7bbdce3@github.com>
Message-ID: 

On Wed, 12 Mar 2025 11:15:29 GMT, Maurizio Cimadamore  wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - Merge branch 'master' into segmentallocate
>>  - revert changes to CallocArena
>>  - Merge branch 'master' into segmentallocate
>>  - copyright
>>  - Merge branch 'master' into segmentallocate
>>  - wrong init
>>  - move segment instance creation to SegmentFactories
>>  - address review
>>  - improve the implementation of SegmentFactories::allocateSegment
>
> test/micro/org/openjdk/bench/java/lang/foreign/AllocTest.java line 26:
> 
>> 24: package org.openjdk.bench.java.lang.foreign;
>> 25: 
>> 26: import java.lang.foreign.*;
> 
> I believe it would be better to leave the imports alone -- as all the other benchmarks also use the "more explicit" style.

I have expanded the import section, please reapprove this PR, thanks a lot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22610#discussion_r1993069941

From dfuchs at openjdk.org  Thu Mar 13 10:18:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Mar 2025 10:18:08 GMT
Subject: RFR: 8351897: Extra closing curly brace typos in Javadoc
In-Reply-To: 
References: 
Message-ID: 

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs  wrote:

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/24022#pullrequestreview-2681298904

From jpai at openjdk.org  Thu Mar 13 11:06:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Mar 2025 11:06:07 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v2]
In-Reply-To: <9t0wyVnW-ITY2BrsnpvMCnrWuNt3RaP8wUo9VBycq2A=.fb616b79-c1cf-4234-9c7a-5b9af5f23410@github.com>
References: 
 
 <1aDEYvZqhjpU8GKqVGAZXqqL9wSY711AF_sfCmhUD68=.b98c6bf3-5b78-49a1-b934-93b135395a15@github.com>
 
 <9t0wyVnW-ITY2BrsnpvMCnrWuNt3RaP8wUo9VBycq2A=.fb616b79-c1cf-4234-9c7a-5b9af5f23410@github.com>
Message-ID: 

On Wed, 12 Mar 2025 18:22:57 GMT, Eirik Bj?rsn?s  wrote:

>>> This seems mostly used to determine which ZipCoder to pick. Could we fold this into the method, calling it zipCoderForPos and make it just return the ZipCoder, like we had in Source?
>> 
>> I intentionally removed the `zipCoderForPos()` method and instead introduced this static method to avoid the case where the code ends up calling this method and then stores the returned `ZipCoder` (like was being done in `Source`). Instead with this new method, it now allows the call sites to determine if a UTF8 `ZipCoder` is needed or a non-UTF8 one and then decide where to get the non-UTF8 `ZipCoder` from. If the call site is a instance method in `ZipFile`, then it was use the `ZipFile`'s `zipCoder` field and if the call site is within `Source`, when the `Source` is being instantiated then it constructs a non-UTF8 `ZipCoder` afresh. That level of detail is better dealt at the call site instead of a method like `zipCoderForPos()`.
>
> Hello Jaikiran,
> 
> I'm not convinced dropping `zipCoderForPos` is a step forward:
> 
> * `zipCoderForPos` included a short-circuit optimization logic which skipped reading the CENFLG field in the case where the opening charset was UTF-8 (which it commonly is, and always for JarFile). This optimization seems lost in the currrent state of this PR and could impact lookup performance. It would be strange to repeat this optimization at all call sites.
> * The only thing differing between callsites seems to be which ZipCoder to use as a "fallback" when it's not UTF-8. This ZipCoder instance can easilly be passed in as a parameter, and will de-duplicate logic at the call sites.
> * The only "cumbersome" call site seems to be `initCEN`, caused by the lazy initialization of the non-UTF-8 ZipCoder. But that lazy initialization seems questionable: First, ZipCoder is already lazy in the way it initializes encoders and decoders. An unused ZipCoder is just a thin wrapper around a Charset and should not incur significant cost until it gets used. Second, the `ZipFile` constructor actually constructs a `ZipCoder` instance, would it not be better to just pass this down to initCEN as a parameter? That would avoid the cost of initializing encoders and decoders twice for the common case of single-threaded `ZipFile` access, once for initCEN, then again on the first lookup.  
> 
> Here's a patch for a quick implementation of the above on top of your PR. (Code speeks better than words some times :-)
> 
> This retains the CENFLG optimization, simplifies logic at call sites and prevents duplicated initialization of ZipCoder beteween initCEN and lookups:
> 
> 
> Index: src/java.base/share/classes/java/util/zip/ZipFile.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java
> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java	(revision 935b04ed00522aa92105292baa0693c55b1356ae)
> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java	(date 1741800197915)
> @@ -201,8 +201,8 @@
>          this.fileName = file.getName();
>          long t0 = System.nanoTime();
>  
> -        this.res = new CleanableResource(this, charset, file, mode);
>          this.zipCoder = ZipCoder.get(charset);
> +        this.res = new CleanableResource(this, charset, zipCoder, file, mode);
>  
>          PerfCounter...

Hello Eirik,

> zipCoderForPos included a short-circuit optimization logic which skipped reading the CENFLG field in the case where the opening charset was UTF-8 (which it commonly is, and always for JarFile). This optimization seems lost in the currrent state of this PR

That's a good point. I'll update this PR shortly, borrowing from your proposed diff/patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1993283080

From pminborg at openjdk.org  Thu Mar 13 11:20:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg  wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Here are the current benchmarks for Mac M1:


Benchmark                                     Mode  Cnt  Score   Error  Units
StableFunctionBenchmark.function              avgt   10  4.071 ? 0.252  ns/op
StableFunctionBenchmark.stable                avgt   10  4.107 ? 0.065  ns/op
StableFunctionBenchmark.staticIntFunction     avgt   10  2.688 ? 1.647  ns/op
StableFunctionBenchmark.staticStable          avgt   10  1.708 ? 0.278  ns/op
StableIntFunctionBenchmark.intFunction        avgt   10  1.528 ? 0.040  ns/op
StableIntFunctionBenchmark.stable             avgt   10  1.515 ? 0.019  ns/op
StableIntFunctionBenchmark.staticIntFunction  avgt   10  1.047 ? 0.023  ns/op
StableIntFunctionBenchmark.staticStable       avgt   10  1.056 ? 0.045  ns/op
StableSupplierBenchmark.stable                avgt   10  1.411 ? 0.127  ns/op
StableSupplierBenchmark.supplier              avgt   10  1.676 ? 0.055  ns/op
StableValueBenchmark.atomic                   avgt   10  1.404 ? 0.061  ns/op
StableValueBenchmark.dcl                      avgt   10  1.398 ? 0.037  ns/op
StableValueBenchmark.refSupplier              avgt   10  0.498 ? 0.077  ns/op
StableValueBenchmark.stable                   avgt   10  1.406 ? 0.053  ns/op
StableValueBenchmark.stableNull               avgt   10  1.279 ? 0.062  ns/op
StableValueBenchmark.staticAtomic             avgt   10  1.228 ? 0.060  ns/op
StableValueBenchmark.staticDcl                avgt   10  0.342 ? 0.005  ns/op
StableValueBenchmark.staticHolder             avgt   10  0.342 ? 0.006  ns/op
StableValueBenchmark.staticStable             avgt   10  0.348 ? 0.015  ns/op

``

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2713007259

From pminborg at openjdk.org  Thu Mar 13 11:20:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
Message-ID: 

Implement JEP 502.

The PR passes tier1-tier3 tests.

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

Commit messages:
 - Use acquire semantics for reading rather than volatile semantics
 - Add missing null check
 - Simplify handling of sentinel, wrap, and unwrap
 - Fix JavaDoc issues
 - Fix members in StableEnumFunction
 - Address some comments in the PR
 - Merge branch 'master' into implement-jep502
 - Revert change
 - Fix copyright issues
 - Update JEP number
 - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351565
  Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From liach at openjdk.org  Thu Mar 13 11:20:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
Message-ID: <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg  wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

FYI we don't usually drop the benchmark scores in the PR description; we usually leave them in comments to indicate which revision the bench results apply to.

src/hotspot/share/ci/ciField.cpp line 255:

> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
> 254:   return signature == vmSymbols::java_lang_StableValue_signature() ||
> 255:          signature == vmSymbols::java_lang_StableValue_array_signature();

This is dubious - a user can declare a `final StableValue[] array;` and modify the array elements, which is totally compliant to the language and the VM rules. Don't know what this serves.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2711648215
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1987920134

From pminborg at openjdk.org  Thu Mar 13 11:20:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>
References: 
 <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>
Message-ID: 

On Mon, 10 Mar 2025 19:45:53 GMT, Chen Liang  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/hotspot/share/ci/ciField.cpp line 255:
> 
>> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
>> 254:   return signature == vmSymbols::java_lang_StableValue_signature() ||
>> 255:          signature == vmSymbols::java_lang_StableValue_array_signature();
> 
> This is dubious - a user can declare a `final StableValue[] array;` and modify the array elements, which is totally compliant to the language and the VM rules. Don't know what this serves.

Fair comment. We should at least remove the array signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988609781

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg  wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/lang/StableValue.java line 79:

> 77:  *            logger.trySet(Logger.create(Component.class));
> 78:  *        }
> 79:  *         return logger.orThrow();

Suggestion:

 *         return logger.orElseThrow();

src/java.base/share/classes/java/lang/StableValue.java line 127:

> 125:  * evaluated only once, even when {@code logger.orElseSet()} is invoked concurrently.
> 126:  * This property is crucial as evaluation of the supplier may have side effects,
> 127:  * e.g., the call above to {@code Logger.getLogger()} may result in storage resources

Suggestion:

 * e.g., the call above to {@code Logger.create()} may result in storage resources

src/java.base/share/classes/java/lang/StableValue.java line 344:

> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
> 343:  * content perpetually.
> 344:  * 


Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.

src/java.base/share/classes/java/lang/StableValue.java line 423:

> 421:      * {@snippet lang=java:
> 422:      * if (stable.isSet()) {
> 423:      *     return stable.get();

Suggestion:

     *     return stable.orElseThrow();

src/java.base/share/classes/java/lang/StableValue.java line 547:

> 545:                                           IntFunction original) {
> 546:         if (size < 0) {
> 547:             throw new IllegalArgumentException();

This exceptions isn't documented, same for `StableValue.list()`

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:

> 110:         final Class enumType = (Class)inputs.iterator().next().getClass();
> 111:         return (Function) new StableEnumFunction(enumType, min, StableValueFactories.array(size), (Function) original);
> 112:     }

If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:

> 139:                 ? "(this StableValue)"
> 140:                 : "StableValue" + renderWrapped(t);
> 141:     }

Are deeper cycles of concern? I was thinking of this:

var a = StableValue.of();
var b = StableValue.of();
a.trySet(b);
b.trySet(a);
System.out.println(a);


This would solve deeper cycles for `StableValueImpl`:

@Override
public String toString() {
    final StringBuilder sb = new StringBuilder("StableValue");
    int depth = 0;
    Object t = value;
    while (t instanceof StableValueImpl s) {
        if (s == this) {
            t = "(this StableValue)";
            break;
        }
        sb.append("[StableValue");
        depth++;
        t = s.value;
    }
    sb.append(renderWrapped(t));
    while (depth-- > 0) sb.append(']');
    return sb.toString();
}

This might also apply to stable functions and collections, I haven't thought it through for them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989143787
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989165612
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989265489
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989377859
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989504117
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988064795
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988092230

From liach at openjdk.org  Thu Mar 13 11:20:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
Message-ID: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>

On Tue, 11 Mar 2025 13:22:20 GMT, Luca Kellermann  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/lang/StableValue.java line 344:
> 
>> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
>> 343:  * content perpetually.
>> 344:  * 

> 
> Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.

The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:
> 
>> 110:         final Class enumType = (Class)inputs.iterator().next().getClass();
>> 111:         return (Function) new StableEnumFunction(enumType, min, StableValueFactories.array(size), (Function) original);
>> 112:     }
> 
> If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?

Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:
> 
>> 139:                 ? "(this StableValue)"
>> 140:                 : "StableValue" + renderWrapped(t);
>> 141:     }
> 
> Are deeper cycles of concern? I was thinking of this:
> 
> var a = StableValue.of();
> var b = StableValue.of();
> a.trySet(b);
> b.trySet(a);
> System.out.println(a);
> 
> 
> This would solve deeper cycles for `StableValueImpl`:
> 
> @Override
> public String toString() {
>     final StringBuilder sb = new StringBuilder("StableValue");
>     int depth = 0;
>     Object t = value;
>     while (t instanceof StableValueImpl s) {
>         if (s == this) {
>             t = "(this StableValue)";
>             break;
>         }
>         sb.append("[StableValue");
>         depth++;
>         t = s.value;
>     }
>     sb.append(renderWrapped(t));
>     while (depth-- > 0) sb.append(']');
>     return sb.toString();
> }
> 
> This might also apply to stable functions and collections, I haven't thought it through for them.

I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989965200
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988159371
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988154881

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: 
 
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: 

On Tue, 11 Mar 2025 19:04:39 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/StableValue.java line 344:
>> 
>>> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
>>> 343:  * content perpetually.
>>> 344:  * 

>> 
>> Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.
>
> The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:
>> 
>>> 139:                 ? "(this StableValue)"
>>> 140:                 : "StableValue" + renderWrapped(t);
>>> 141:     }
>> 
>> Are deeper cycles of concern? I was thinking of this:
>> 
>> var a = StableValue.of();
>> var b = StableValue.of();
>> a.trySet(b);
>> b.trySet(a);
>> System.out.println(a);
>> 
>> 
>> This would solve deeper cycles for `StableValueImpl`:
>> 
>> @Override
>> public String toString() {
>>     final StringBuilder sb = new StringBuilder("StableValue");
>>     int depth = 0;
>>     Object t = value;
>>     while (t instanceof StableValueImpl s) {
>>         if (s == this) {
>>             t = "(this StableValue)";
>>             break;
>>         }
>>         sb.append("[StableValue");
>>         depth++;
>>         t = s.value;
>>     }
>>     sb.append(renderWrapped(t));
>>     while (depth-- > 0) sb.append(']');
>>     return sb.toString();
>> }
>> 
>> This might also apply to stable functions and collections, I haven't thought it through for them.
>
> I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.

The `toString()` function for stable value is inspired by `Optional` and some of the collections.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990919074
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988637468

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 
Message-ID: 

On Wed, 12 Mar 2025 08:16:50 GMT, Per Minborg  wrote:

>> The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)
>
> This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.

> (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

You mean [this](https://github.com/openjdk/jdk/blob/a05717d8da8f804003cfb8d6d25b8a5b6cecd473/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L117-L120) is missing `Objects.requireNonNull(supplier);`, right?

>> I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.
>
> The `toString()` function for stable value is inspired by `Optional` and some of the collections.

`Optional` doesn't have the issue of containing itself.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991649915
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989329168

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 
 
Message-ID: <9eaXze3gUOvuO_dJhn31evFsyUO6zw9z9Dneexn8WKw=.7bd9d254-d8ea-44a5-a57d-a98173ba536f@github.com>

On Wed, 12 Mar 2025 14:38:28 GMT, Luca Kellermann  wrote:

>> This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.
>
>> (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)
> 
> You mean [this](https://github.com/openjdk/jdk/blob/a05717d8da8f804003cfb8d6d25b8a5b6cecd473/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L117-L120) is missing `Objects.requireNonNull(supplier);`, right?

Fixed `Objects.requireNonNull()` now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993279982

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
 
Message-ID: 

On Tue, 11 Mar 2025 07:48:40 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
>> 
>>> 770: 
>>> 771:     @jdk.internal.ValueBased
>>> 772:     static final class StableList extends AbstractImmutableList {
>> 
>> Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.
>
> This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.

Using the regular AbstractList as a base would also get you implementations of those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989875430

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
Message-ID: <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg  wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/util/ImmutableCollections.java line 772:

> 770: 
> 771:     @jdk.internal.ValueBased
> 772:     static final class StableList extends AbstractImmutableList {

Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1462:

> 1460: 
> 1461:     static final class StableMap
> 1462:             extends AbstractImmutableMap {

Same question about whether StableMap needs to go here. Though there?s more stuff going on for maps than lists here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988220230
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988222063

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
References: 
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
Message-ID: 

On Tue, 11 Mar 2025 01:20:16 GMT, Johannes Graham  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
> 
>> 770: 
>> 771:     @jdk.internal.ValueBased
>> 772:     static final class StableList extends AbstractImmutableList {
> 
> Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.

This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.

> src/java.base/share/classes/java/util/ImmutableCollections.java line 1462:
> 
>> 1460: 
>> 1461:     static final class StableMap
>> 1462:             extends AbstractImmutableMap {
> 
> Same question about whether StableMap needs to go here. Though there?s more stuff going on for maps than lists here.

Same argument as for `StableList`. This allows reuse of several classes including `AbstractImmutableMap`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988605709
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988607732

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg  wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/util/ImmutableCollections.java line 777:

> 775:         private final IntFunction mapper;
> 776:         @Stable
> 777:         private final StableValueImpl[] backing;

You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:

> 63:     //
> 64:     @Stable
> 65:     private volatile Object value;

Can we use `acquire`/`release` semantics instead of `volatile`?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:

> 126:             final T newValue = supplier.get();
> 127:             // The mutex is reentrant so we need to check if the value was actually set.
> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();

Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:

> 157:     private boolean wrapAndCas(Object value) {
> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));

There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 168:

> 166:     // Wraps `null` values into a sentinel value
> 167:     @ForceInline
> 168:     private static  T wrap(T t) {

Suggestion:

    private static  Object wrap(T t) {

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 181:

> 179:     @SuppressWarnings("unchecked")
> 180:     @ForceInline
> 181:     private static  T nullSentinel() {

Suggestion:

    private static Object nullSentinel() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988608920
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988612784
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993081551
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988616943
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993110162
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993111723

From liach at openjdk.org  Thu Mar 13 11:20:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
 
 
Message-ID: 

On Tue, 11 Mar 2025 18:08:47 GMT, Johannes Graham  wrote:

>> This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.
>
> Using the regular AbstractList as a base would also get you implementations of those.

`AbstractList` has non-final fields, which makes it not suitable for `@ValueBased`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989947965

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 11 Mar 2025 07:50:38 GMT, Quan Anh Mai  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 777:
> 
>> 775:         private final IntFunction mapper;
>> 776:         @Stable
>> 777:         private final StableValueImpl[] backing;
> 
> You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.

Can you please elaborate a bit more on your proposal @merykitty?

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:
> 
>> 63:     //
>> 64:     @Stable
>> 65:     private volatile Object value;
> 
> Can we use `acquire`/`release` semantics instead of `volatile`?

Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:
> 
>> 126:             final T newValue = supplier.get();
>> 127:             // The mutex is reentrant so we need to check if the value was actually set.
>> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();
> 
> Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`

StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:
> 
>> 157:     private boolean wrapAndCas(Object value) {
>> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
>> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));
> 
> There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.

This is more of a belt and suspenders solution. It is true that it is redundant. A set volatile would suffice here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989016337
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988630199
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993142117
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988634451

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 11 Mar 2025 11:19:13 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 777:
>> 
>>> 775:         private final IntFunction mapper;
>>> 776:         @Stable
>>> 777:         private final StableValueImpl[] backing;
>> 
>> You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.
>
> Can you please elaborate a bit more on your proposal @merykitty?

If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:

    ReentrantLock[] locks;

    T get(int idx) {
        Object x = backing[idx];
        if (x == null) {
            return compute(idx);
        }
        return unwrap(x);
    }

    T compute(int idx) {
        ReentrantLock lock = locks[idx];
        lock.lock();
        try {
            Object x = backing[idx];
            if (x != null) {
                return unwrap(x);
            }
            T obj = ...;
            backing[idx] = wrap(obj);
            return obj;
        } finally {
            lock.unlock();
        }
    }

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:
>> 
>>> 63:     //
>>> 64:     @Stable
>>> 65:     private volatile Object value;
>> 
>> Can we use `acquire`/`release` semantics instead of `volatile`?
>
> Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.

You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989664004
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990989622

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 11 Mar 2025 16:15:10 GMT, Quan Anh Mai  wrote:

>> Can you please elaborate a bit more on your proposal @merykitty?
>
> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
> 
>     ReentrantLock[] locks;
> 
>     T get(int idx) {
>         Object x = backing[idx];
>         if (x == null) {
>             return compute(idx);
>         }
>         return unwrap(x);
>     }
> 
>     T compute(int idx) {
>         ReentrantLock lock = locks[idx];
>         lock.lock();
>         try {
>             Object x = backing[idx];
>             if (x != null) {
>                 return unwrap(x);
>             }
>             T obj = ...;
>             backing[idx] = wrap(obj);
>             return obj;
>         } finally {
>             lock.unlock();
>         }
>     }

What would be the difference between `@Stable StableValueImpl[] backing` and `@Stable Object[] backing`?

>> Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.
>
> You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.

Yeah. Maybe that could strike a balance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990908235
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991599680

From mcimadamore at openjdk.org  Thu Mar 13 11:20:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 12 Mar 2025 08:09:04 GMT, Per Minborg  wrote:

>> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
>> 
>>     ReentrantLock[] locks;
>> 
>>     T get(int idx) {
>>         Object x = backing[idx];
>>         if (x == null) {
>>             return compute(idx);
>>         }
>>         return unwrap(x);
>>     }
>> 
>>     T compute(int idx) {
>>         ReentrantLock lock = locks[idx];
>>         lock.lock();
>>         try {
>>             Object x = backing[idx];
>>             if (x != null) {
>>                 return unwrap(x);
>>             }
>>             T obj = ...;
>>             backing[idx] = wrap(obj);
>>             return obj;
>>         } finally {
>>             lock.unlock();
>>         }
>>     }
>
> What would be the difference between `@Stable StableValueImpl[] backing` and `@Stable Object[] backing`?

It's true that the storage can be flatter here -- that said, this can also be done as a later refactoring. One advantage of doing things the way @minborg did it here, is that it's fairly easy to prove that the code below is correct -- which makes the initial review easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991505367

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <7hEWpE3GTKhCa15FRQBf6_tzHUsr9mbzv6zh1HeZlXY=.1800d27a-33d9-41de-b8bd-31fd82a3661b@github.com>

On Wed, 12 Mar 2025 08:09:04 GMT, Per Minborg  wrote:

>> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
>> 
>>     ReentrantLock[] locks;
>> 
>>     T get(int idx) {
>>         Object x = backing[idx];
>>         if (x == null) {
>>             return compute(idx);
>>         }
>>         return unwrap(x);
>>     }
>> 
>>     T compute(int idx) {
>>         ReentrantLock lock = locks[idx];
>>         lock.lock();
>>         try {
>>             Object x = backing[idx];
>>             if (x != null) {
>>                 return unwrap(x);
>>             }
>>             T obj = ...;
>>             backing[idx] = wrap(obj);
>>             return obj;
>>         } finally {
>>             lock.unlock();
>>         }
>>     }
>
> What would be the difference between `@Stable StableValueImpl[] backing` and `@Stable Object[] backing`?

For an `Object[]`, you only need to load the object from the array and it is probably what you need. For a `StableValueImpl[]`, you need to load the `StableValueImpl` from the array, and load the value from that `StableValueImpl`, which is 2 levels of indirections.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990993459

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <8eLNHYCb3NOjDPJhbTd2sT_MxAhlPjI9fC4mr0sSWOU=.51260d3f-6585-4fbb-a367-43f26bc225fb@github.com>

On Wed, 12 Mar 2025 13:28:12 GMT, Maurizio Cimadamore  wrote:

>> What would be the difference between `@Stable StableValueImpl[] backing` and `@Stable Object[] backing`?
>
> It's true that the storage can be flatter here -- that said, this can also be done as a later refactoring. One advantage of doing things the way @minborg did it here, is that it's fairly easy to prove that the code below is correct -- which makes the initial review easier.

Ahh. Now I see what you mean. This is something we did in a handful of prototypes we explored. While it is true that there will be one indirection less, the complexity of the code is going to grow. Also, if the element is constant folded, it does not matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991597981

From duke at openjdk.org  Thu Mar 13 11:20:14 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: 
 
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: 

On Mon, 10 Mar 2025 23:42:06 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:
>> 
>>> 110:         final Class enumType = (Class)inputs.iterator().next().getClass();
>>> 111:         return (Function) new StableEnumFunction(enumType, min, StableValueFactories.array(size), (Function) original);
>>> 112:     }
>> 
>> If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?
>
> Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.

What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.

Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988195668

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 
Message-ID: 

On Tue, 11 Mar 2025 00:40:31 GMT, Johannes Graham  wrote:

>> Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.
>
> What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.
> 
> Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?

Thanks for spotting this glitch. I have fixed the issue and added a test for member sets with "holes".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988707099

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 
 
Message-ID: 

On Tue, 11 Mar 2025 08:44:51 GMT, Per Minborg  wrote:

>> What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.
>> 
>> Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?
>
> Thanks for spotting this glitch. I have fixed the issue and added a test for member sets with "holes".

It might be worth exploring using a stable int function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991590911

From alanb at openjdk.org  Thu Mar 13 11:20:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Mar 2025 11:20:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg  wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/jdk.unsupported/share/classes/sun/misc/Unsafe.java line 983:

> 981: 
> 982:     @ForceInline
> 983:     private static void assertNotTrusted(Field f) {

I don't think this can be named assertXXX, needs to something like ensureNotTrusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1987836045

From pminborg at openjdk.org  Thu Mar 13 11:20:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <1O-QKtK9LBw8YzDDGzJxtBTwYBD3jnoKfXFJYiY1sp4=.dea93da7-bfcd-42ca-98c8-f8e0705bac07@github.com>

On Wed, 12 Mar 2025 14:14:59 GMT, Per Minborg  wrote:

>> You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.
>
> Yeah. Maybe that could strike a balance.

On an M1 Mac:

Volatile:


StableValueBenchmark.stable        avgt   10  1.373 ? 0.057  ns/op
StableValueBenchmark.stableNull    avgt   10  1.245 ? 0.074  ns/op


Acquire:


StableValueBenchmark.stable        avgt   10  1.339 ? 0.044  ns/op
StableValueBenchmark.stableNull    avgt   10  1.241 ? 0.090  ns/op


We would have to examine the difference on other platforms as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993284760

From jvernee at openjdk.org  Thu Mar 13 11:55:09 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 13 Mar 2025 11:55:09 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v7]
In-Reply-To: <0_1SZd0VVSYj61Zc71DqxZMrfRWIgfrmCPou_AS2DYc=.9156ec5f-fac3-4ff3-9261-f576414372fc@github.com>
References: 
 <0_1SZd0VVSYj61Zc71DqxZMrfRWIgfrmCPou_AS2DYc=.9156ec5f-fac3-4ff3-9261-f576414372fc@github.com>
Message-ID: 

On Thu, 13 Mar 2025 05:46:44 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch improves the performance of a typical `Arena::allocate` in several ways:
>> 
>> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
>> - Split the allocation of over-aligned memory to a slow-path method.
>> - Align the memory to 8 bytes, allowing faster zeroing.
>> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
>> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   expand wildcard imports

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22610#pullrequestreview-2681600835

From duke at openjdk.org  Thu Mar 13 12:03:11 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 12:03:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 13 Mar 2025 09:45:22 GMT, Per Minborg  wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:
>> 
>>> 126:             final T newValue = supplier.get();
>>> 127:             // The mutex is reentrant so we need to check if the value was actually set.
>>> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();
>> 
>> Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`
>
> StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

There is also `Thread.holdsLock()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993371561

From pminborg at openjdk.org  Thu Mar 13 12:45:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 12:45:50 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v2]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework reenterant logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/09ca44e6..1cd1cdb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00-01

  Stats: 67 lines in 4 files changed: 56 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Thu Mar 13 12:52:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 12:52:32 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v3]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename method and fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/1cd1cdb2..8f6d6bc0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=01-02

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From pminborg at openjdk.org  Thu Mar 13 13:01:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 13:01:58 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v4]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/8f6d6bc0..c648ea2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=02-03

  Stats: 23 lines in 6 files changed: 1 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From tschatzl at openjdk.org  Thu Mar 13 13:07:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 13 Mar 2025 13:07:29 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v19]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * when aborting refinement during full collection, the global card table and the per-thread card table might not be in sync. Roll forward during abort of the refinement in these situations.
  * additional verification
  * added some missing ResourceMarks in asserts
  * added variant of ArrayJuggle2 that crashes fairly quickly without these changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/3766b76c..78611173

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=17-18

  Stats: 111 lines in 11 files changed: 82 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From dchuyko at openjdk.org  Thu Mar 13 13:40:33 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 13 Mar 2025 13:40:33 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
Message-ID: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>

Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.

The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.

[1] https://bugs.openjdk.org/browse/JDK-8134852
[2] https://bugs.openjdk.org/browse/JDK-8330017

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

Commit messages:
 - RC_MASK and TC_MASK instead of UMASK

Changes: https://git.openjdk.org/jdk/pull/24034/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24034&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351933
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24034.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24034/head:pull/24034

PR: https://git.openjdk.org/jdk/pull/24034

From weijun at openjdk.org  Thu Mar 13 13:49:17 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 13:49:17 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters  wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Actually, you can remove those lines in `security.cpp`. The whole method is for debugging use during my developing work. While the method could still be valuable but those lines are completely useless now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2721318729

From galder at openjdk.org  Thu Mar 13 13:50:14 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 13 Mar 2025 13:50:14 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: 
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 
 
 
 <63F-0aHgMthexL0b2DFmkW8_QrJeo8OOlCaIyZApfpY=.4744070d-9d56-4031-8684-be14cf66d1e5@github.com>
 
 
Message-ID: 

On Fri, 7 Mar 2025 13:17:29 GMT, Emanuel Peter  wrote:

>>> As for possible solutions. In all Regression 1-3 cases, it seems the issue is scalar cmove. So actually in all cases a possible solution is using branching code (i.e. `cmp+mov`). So to me, these are the follow-up RFE's:
>>> 
>>> * Detect "extreme" probability scalar cmove, and replace them with branching code. This should take care of all regressions here. This one has high priority, as it fixes the regression caused by this patch here. But it would also help to improve performance for the `Integer.min/max` cases, which have the same issue.
>> 
>> I've created [JDK-8351409](https://bugs.openjdk.org/browse/JDK-8351409) to address this.
>
> @galderz Excellent. Testing looks all good on our side. Yes I think what you saw was unrelated.
> @rwestrel Could give this a last quick scan and then I think you can integrate :)

Thanks @eme64 @rwestrel @chhagedorn for your patience with this!

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2721319344

From duke at openjdk.org  Thu Mar 13 13:50:22 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Mar 2025 13:50:22 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v14]
In-Reply-To: <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <9c34YjVjK0BMclNqFWMSitBV2YTcu_jmgWVitjRgvF0=.0f225af6-5888-4160-9a54-09baa696da1c@github.com>
Message-ID: 

On Fri, 7 Mar 2025 06:19:03 GMT, Galder Zamarre?o  wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Add assertion comments
>  - Add simple reduction benchmarks on top of multiply ones
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/c836c5b7...1aa690d3

@galderz 
Your change (at version 1aa690d391ef3536d422ba93c33d0fc273a911c6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2721323015

From pminborg at openjdk.org  Thu Mar 13 13:52:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 13:52:24 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v5]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Clean up exception messages and fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/c648ea2b..2fe5b0f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=03-04

  Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From galder at openjdk.org  Thu Mar 13 13:57:23 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 13 Mar 2025 13:57:23 GMT
Subject: Integrated: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: 

On Tue, 9 Jul 2024 12:07:37 GMT, Galder Zamarre?o  wrote:

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

This pull request has now been integrated.

Changeset: 4e51a8c9
Author:    Galder Zamarre?o 
URL:       https://git.openjdk.org/jdk/commit/4e51a8c9ad4e5345d05cf32ce1e82b7158f80e93
Stats:     844 lines in 9 files changed: 725 ins; 107 del; 12 mod

8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long)

Reviewed-by: roland, epeter, chagedorn, darcy

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

PR: https://git.openjdk.org/jdk/pull/20098

From tschatzl at openjdk.org  Thu Mar 13 14:16:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 13 Mar 2025 14:16:07 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v19]
In-Reply-To: 
References: 
 
Message-ID: <-ys7CbBNU4hCmEgYQyZpmBQ_rso4i2_KoFHLPNv73sI=.bd715b1d-b9fd-48b7-bb06-d6673ab2dbfc@github.com>

On Thu, 13 Mar 2025 13:07:29 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * when aborting refinement during full collection, the global card table and the per-thread card table might not be in sync. Roll forward during abort of the refinement in these situations.
>   * additional verification
>   * added some missing ResourceMarks in asserts
>   * added variant of ArrayJuggle2 that crashes fairly quickly without these changes

Commit https://github.com/openjdk/jdk/pull/23739/commits/786111735c306583af5bc75f7653f0da67d52adb fixes an issue with full gc interrupting refinement while the global card table and the JavaThread's card table changes.

Testing: tier1-7 with changes, tier1-5 with changes stressing refinement similar to the ones added to the new test.

The new variant of `ArrayJuggle2` fails >50% of all times in our CI without the patch (verified 700 or so executions of that not failing with patch).

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2721413659

From alanb at openjdk.org  Thu Mar 13 14:20:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Mar 2025 14:20:02 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 11 Mar 2025 20:29:20 GMT, Doug Lea 
 wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SharedSecrets for ThreadLocalRandomProbe; other tweaks

src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java line 193:

> 191: 
> 192:     /**
> 193:      * Returns the ThreadLocalRandom probe value for the current thread.

I suppose this shouldn't say "current thread" anymore, and advanceProbe uses "the given thread" then it really means the current carrier thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1993631347

From alanb at openjdk.org  Thu Mar 13 14:23:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Mar 2025 14:23:07 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 11 Mar 2025 20:29:20 GMT, Doug Lea 
 wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SharedSecrets for ThreadLocalRandomProbe; other tweaks

I've done testing with the latest changes (to commit 9cc670bc2cdf35c1055d6f469d4210d27d26bffc), and with the VirtualThread implementation changed to use it (pull/24030) and all looking good.

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

PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2721435851

From pminborg at openjdk.org  Thu Mar 13 15:21:33 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 15:21:33 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: 
References: 
Message-ID: 

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
> 
> 
> Adapted system call:
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> ```        
> Explicit allocation:
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> ```        
> Thread Local allocation:
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> ```        
> The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. ...

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge master
 - Add test for woven allocation
 - Merge branch 'master' into errno-util3
 - Use lazy initialization of method handles
 - Clean up visibility
 - Merge branch 'master' into errno-util3
 - Add @ForceInline annotations
 - Add out of order test for VTs
 - Allow memory reuse for several arenas
 - Remove file
 - ... and 24 more: https://git.openjdk.org/jdk/compare/4e51a8c9...6d782a84

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

Changes: https://git.openjdk.org/jdk/pull/23765/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=02
  Stats: 1913 lines in 13 files changed: 1901 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23765/head:pull/23765

PR: https://git.openjdk.org/jdk/pull/23765

From pminborg at openjdk.org  Thu Mar 13 15:22:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 15:22:43 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
Message-ID: 

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:

 - Merge branch 'master' into implement-jep502
 - Clean up exception messages and fix comments
 - Rename field
 - Rename method and fix comment
 - Rework reenterant logic
 - Use acquire semantics for reading rather than volatile semantics
 - Add missing null check
 - Simplify handling of sentinel, wrap, and unwrap
 - Fix JavaDoc issues
 - Fix members in StableEnumFunction
 - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

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

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=05
  Stats: 4040 lines in 30 files changed: 4009 ins; 18 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

PR: https://git.openjdk.org/jdk/pull/23972

From mcimadamore at openjdk.org  Thu Mar 13 15:39:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:39:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/hotspot/share/ci/ciField.cpp line 254:

> 252: 
> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
> 254:   return signature == vmSymbols::java_lang_StableValue_signature();

Just a note that we will need to decide whether to keep this or not...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993795795

From mcimadamore at openjdk.org  Thu Mar 13 15:52:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:52:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 45:

> 43: 
> 44: /**
> 45:  * A stable value is a shallowly immutable holder of deferred content.

Is this terminology a leftover from previous JEP iterations? The JEP now says: 
>  stable values, which are objects that hold immutable data.

src/java.base/share/classes/java/lang/StableValue.java line 283:

> 281:  * the {@code Foo} does not already exist.
> 282:  * 

> 283:  * Here is another example where a more complex dependency graph is created in which

I wonder if just leaving the fibonacci example would be enough here -- as that has a nice dependency graph

src/java.base/share/classes/java/lang/StableValue.java line 330:

> 328:  * thread safe and guarantee at-most-once-per-input invocation.
> 329:  *
> 330:  * 
Miscellaneous


I'm dubious about a section called "misc" :-)

src/java.base/share/classes/java/lang/StableValue.java line 331:

> 329:  *
> 330:  * 
Miscellaneous

> 331:  * Except for a StableValue's content itself, an {@linkplain #orElse(Object) orElse(other)}

missing `{@code}`

src/java.base/share/classes/java/lang/StableValue.java line 335:

> 333:  * parameters must be non-null or a {@link NullPointerException} will be thrown.
> 334:  * 

> 335:  * Stable functions and collections are not {@link Serializable} as this would require

Not sure this belongs here. Perhaps the comment on these functions not being serializable should be on their factories. And the point on security vulnerability seems specific and vague at the same time -- better remove it.

src/java.base/share/classes/java/lang/StableValue.java line 339:

> 337:  * which would introduce security vulnerabilities.
> 338:  * 

> 339:  * As objects can be set via stable values but never removed, this can be a source

It feels like this could probably be expanded upon -- also covering stable functions (and morphed into a new section)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993819611
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993803509
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993810862
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993805209
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993808888
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993812118

From mcimadamore at openjdk.org  Thu Mar 13 15:52:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:52:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 13 Mar 2025 15:48:25 GMT, Maurizio Cimadamore  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/java/lang/StableValue.java line 45:
> 
>> 43: 
>> 44: /**
>> 45:  * A stable value is a shallowly immutable holder of deferred content.
> 
> Is this terminology a leftover from previous JEP iterations? The JEP now says: 
>>  stable values, which are objects that hold immutable data.

Maybe: `A stable value in an holder for shallowly immutable content`.

> src/java.base/share/classes/java/lang/StableValue.java line 330:
> 
>> 328:  * thread safe and guarantee at-most-once-per-input invocation.
>> 329:  *
>> 330:  * 
Miscellaneous

> 
> I'm dubious about a section called "misc" :-)

We can probably move out some of the contents (I left some suggestions) - then move the remaining into api notes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993822111
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993815323

From mcimadamore at openjdk.org  Thu Mar 13 15:57:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:57:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 497:

> 495: 
> 496:     /**
> 497:      * {@return a new unset stable supplier}

Should we say "unset" here?

src/java.base/share/classes/java/lang/StableValue.java line 526:

> 524: 
> 525:     /**
> 526:      * {@return a new unset stable int function}

Should we say "unset" here?

src/java.base/share/classes/java/lang/StableValue.java line 564:

> 562: 
> 563:     /**
> 564:      * {@return a new unset stable function}

Should we say "unset" here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993828637
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993829241
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993831680

From mcimadamore at openjdk.org  Thu Mar 13 15:57:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:57:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 13 Mar 2025 15:52:37 GMT, Maurizio Cimadamore  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/java/lang/StableValue.java line 497:
> 
>> 495: 
>> 496:     /**
>> 497:      * {@return a new unset stable supplier}
> 
> Should we say "unset" here?

E.g. we do not define the term "unset supplier" anywhere -- we just define what a stable supplier is -- IMHO that's enough. Also... whether unset or set, that's not really visible by the user?

> src/java.base/share/classes/java/lang/StableValue.java line 564:
> 
>> 562: 
>> 563:     /**
>> 564:      * {@return a new unset stable function}
> 
> Should we say "unset" here?

Same with all the other lazy XYZ factories

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993830847
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993832264

From mcimadamore at openjdk.org  Thu Mar 13 16:07:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 16:07:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 74:

> 72:     @Override
> 73:     public boolean trySet(T value) {
> 74:         if (wrappedContentAcquire() != null) {

IMHO, if our goal is to do:

Object content = this.content;
if (context != null) return content:
synchronized (...) {
    if (context != null) return content:
    this.context = ...
}


Then we might just use a volatile field and synchronized blocks. I don't see an immediate need for using acquire/release semantics -- especially when using a monitor. E.g. this should look more like a classic double checked locking idiom. (but with a stable field to make the first volatile read more efficient in case the field is already set)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993850760

From mcimadamore at openjdk.org  Thu Mar 13 16:24:07 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 16:24:07 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v7]
In-Reply-To: <0_1SZd0VVSYj61Zc71DqxZMrfRWIgfrmCPou_AS2DYc=.9156ec5f-fac3-4ff3-9261-f576414372fc@github.com>
References: 
 <0_1SZd0VVSYj61Zc71DqxZMrfRWIgfrmCPou_AS2DYc=.9156ec5f-fac3-4ff3-9261-f576414372fc@github.com>
Message-ID: <_IZBYKPqsgElXJ5jJANnee0ujmsnbDY5_En0LN15TW4=.dd7659bd-264b-42d9-b0f8-f88cd2ec2738@github.com>

On Thu, 13 Mar 2025 05:46:44 GMT, Quan Anh Mai  wrote:

>> Hi,
>> 
>> This patch improves the performance of a typical `Arena::allocate` in several ways:
>> 
>> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
>> - Split the allocation of over-aligned memory to a slow-path method.
>> - Align the memory to 8 bytes, allowing faster zeroing.
>> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
>> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   expand wildcard imports

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22610#pullrequestreview-2682620023

From henryjen at openjdk.org  Thu Mar 13 16:47:06 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 13 Mar 2025 16:47:06 GMT
Subject: Integrated: 8349984: (jdeps) jdeps can use String.repeat instead of
 String.replaceAll
In-Reply-To: 
References: 
Message-ID: <_4Z8y_-dHFFmt19CF34Uc7Lh2sQdXM6KT2j0XemdmAY=.56fe72ff-a95b-4474-aa2f-b7530482dce4@github.com>

On Sat, 8 Mar 2025 00:28:15 GMT, Henry Jen  wrote:

> JDK-8349989: jlink can use String.replace instead of String.replaceAll

This pull request has now been integrated.

Changeset: 0ff1c083
Author:    Henry Jen 
URL:       https://git.openjdk.org/jdk/commit/0ff1c0832e7d2ca70f344e933d86a5d16fdcabe0
Stats:     8 lines in 3 files changed: 0 ins; 0 del; 8 mod

8349984: (jdeps) jdeps can use String.repeat instead of String.replaceAll

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/23954

From dl at openjdk.org  Thu Mar 13 17:49:58 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 13 Mar 2025 17:49:58 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 13 Mar 2025 14:17:29 GMT, Alan Bateman  wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SharedSecrets for ThreadLocalRandomProbe; other tweaks
>
> src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java line 193:
> 
>> 191: 
>> 192:     /**
>> 193:      * Returns the ThreadLocalRandom probe value for the current thread.
> 
> I suppose this shouldn't say "current thread" anymore, and advanceProbe uses "the given thread" then it really means the current carrier thread.

Thanks. Added "carrier" here and in advanceProbe

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1994044096

From dl at openjdk.org  Thu Mar 13 18:04:24 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 13 Mar 2025 18:04:24 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v10]
In-Reply-To: 
References: 
Message-ID: 

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Reword javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/9cc670bc..172a235b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From hannesw at openjdk.org  Thu Mar 13 18:19:02 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 13 Mar 2025 18:19:02 GMT
Subject: RFR: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 5 Mar 2025 18:07:11 GMT, Jonathan Gibbons  wrote:

>> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
>> 
>> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
>> 
>> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
>> 
>> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
>> 
>> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
>> 
>> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element
>
> As you indicated, there are two problems being addressed here, which might indicate the need for two separate patches. These issues are:
> 
> 1. The leading 1-space problem.
> 2. The trailing newline-after-
 problem
> 
> For the first, it is unduly hard work to fix this just for `
` blocks. I still think that an overall better long-term solution would be to apply a conceptual `stripIndent` to the entire doc comment. This would bring traditional comments into line with the new Markdown comments, and can be done in just a few lines in `DocCommentParser`, and doing it there in DCP means you need not update `Elements.getDocComment`. If nothing else, I would suggest doing the experiment and comparing the generated docs, to verify there are no unexpected side effects. If there are any significant unexpected side effects, then your approach might deserve a second look. You could also make this a JDK-version-specific change if you wanted: meaning the new behavior does not apply to older JDK versions, although that is not a policy we have adhered to in the past.
> 
> For the second, I just feel that is a step too far, using JavaScript to clean up what some might consider to be bad input. Authors should either write HTML according to the HTML (and CSS?) specs, so that `javadoc` is just a "pass-through" layer, or authors should use a suitable construct, like `{@snippet...}`, that is "pleasing" to look at in source form while still generating the desired output.

After discussion with @jonathan-gibbons we have agreed that the two issues in this PR should be handled separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/23868#issuecomment-2722311586

From hannesw at openjdk.org  Thu Mar 13 18:19:03 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 13 Mar 2025 18:19:03 GMT
Subject: Withdrawn: 8346118: Improve whitespace normalization in preformatted
 text
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Mar 2025 16:41:18 GMT, Hannes Walln?fer  wrote:

> Please review an enhancement to make `DocCommentParser` normalize whitespace inside `
` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line starts with a space character, which is commonly the case in traditional doc comments. If so, a single leading space is removed in block content (top level text and `{@code}`/`{@literal}` tags) when parsing within HTML `
` tags.
> 
> This fixes the incidental one-space indentation in the vast majority of JDK code samples using `
` alone or in combination with `` or `{@code}`. In fact, I only found one code sample in JDK code that isn't solved by this change, for which I included a fix in this PR (it's in `String.startsWith(String, int)`, where I replaced the 10 char indentation and trailing line with a `
`). 
> 
> The many added `boolean inBlockContent` arguments pased around in `DocCommentParser` are to make sure the removal is not applied to multiline inline content, which is maybe a bit fussy considering there is not a lot of multiline inline content in `
` tags and it usually would not mind about removal of a non-essential space character, but I wanted to keep the change minimal. There are few javadoc tests that had to be adapted, most of the testing is done in `test/langtools/tools/javac/doctree`. 
> 
> If the exact number of leading whitespace in `
` tags is important to any javadoc user the old output can be restored by increasing the indentation by 1. There will be a release note for this of course. 
> 
> Unfortunately, there is another whitespace problem that can't be solved as easily, and that is a leading blank line caused by `
\n` open tags. Browsers will [ignore a newline immediately following a `
` tag][1], but not if there is a `` tag in between. There are hundreds of occurrences of this in JDK code, including variants with space characters mixed in. The fix in javadoc proper would be too complex, so I decided to solve it with 3 lines of JavaScript and a regex to reverse the order of `\n` at the beginning of `
` tags while removing any intermediary space. Script operation is indiscernible and it solves the problem.
> 
> [1]: https://html.spec.whatwg.org/#the-pre-element:the-pre-element

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23868

From joehw at openjdk.org  Thu Mar 13 19:06:03 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 13 Mar 2025 19:06:03 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
Message-ID: 

Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.

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

Commit messages:
 - 8351969: Add Public Identifiers to the JDK built-in Catalog

Changes: https://git.openjdk.org/jdk/pull/24039/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24039&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351969
  Stats: 286 lines in 4 files changed: 70 ins; 142 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/24039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24039/head:pull/24039

PR: https://git.openjdk.org/jdk/pull/24039

From eirbjo at openjdk.org  Thu Mar 13 19:51:57 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 13 Mar 2025 19:51:57 GMT
Subject: RFR: 8347712: IllegalStateException on multithreaded ZipFile
 access with non-UTF8 charset [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 Mar 2025 06:50:08 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to fix an issue `java.util.zip.ZipFile` which would cause failures when multiple instances of `ZipFile` using non-UTF8 `Charset` were operating against the same underlying ZIP file? This addresses https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> ZIP file specification allows for ZIP entries to mark a `UTF-8` flag to indicate that the entry name and comment are encoded using UTF8. A `java.util.zip.ZipFile` can be constructed by passing it a `Charset`. This `Charset` (which defaults to UTF-8) gets used for decoding entry names and comments for non-UTF8 entries.
>> 
>> The internal implementation of `ZipFile` uses a `ZipCoder` (backed by `java.nio.charset.CharsetEncoder/CharsetDecoder` instance) for the given `Charset`. Except for UTF8 `ZipCoder`, other `ZipCoder`s are not thread safe.
>> 
>> The internal implementation of `ZipFile` maintains a cache of `ZipFile$Source`. A `Source` corresponds to the underlying ZIP file and during construction, uses a `ZipCoder` for parsing the ZIP entries and once constructed holds on to the parsed ZIP structure. Multiple instances of a `ZipFile` which all correspond to the same ZIP file on the filesystem, share a single instance of `Source` (after the `Source` has been constructed and cached). Although `ZipFile` instances aren't expected to be thread-safe, the fact that multiple different instances of `ZipFile` could be sharing the same instance of `Source` in concurrent threads, mandates that the `Source` must be thread-safe.
>> 
>> In Java 15, we did a performance optimization through https://bugs.openjdk.org/browse/JDK-8243469. As part of that change, we started holding on to the `ZipCoder` instance (corresponding to the `Charset` provided during `ZipFile` construction) in the `Source`. This stored `ZipCoder` was then used for `ZipFile` operations when working with the ZIP entries. As noted previously, any non-UTF8 `ZipCoder` is not thread-safe and as a result, any usages of `ZipCoder` in the `Source` makes `Source` not thread-safe too. That effectively violates the requirement that `Source` must be thread-safe to allow for its usage in multiple different `ZipFile` instances concurrently. This then causes `ZipFile` usages to fail in unexpected ways like the one shown in the linked https://bugs.openjdk.org/browse/JDK-8347712.
>> 
>> The commit in this PR addresses the issue by not maintaining `ZipCoder` as a instance field of `Source`. Instead the `ZipCoder` is now mainta...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add code comment

I made a pass over the test, adding some comments.

test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 78:

> 76: 
> 77:     /**
> 78:      * Creates multiple instances of java.util.zip.ZipFile with the given {@code entryNameCharset}

This comment could be interpreted as saying that the construction of the ZipFile instances happens up-front, on the main test thread. However, looking at the actual code, the construction of the ZipFile instance AND the enumeration happens concurrently.

Perhaps we could trim the "how" part here, and instad just say that the test verifies that concurrent construction and enumeration of  java.util.zip.ZipFile instances backed by a the same ZIP file does not cause unexpected encoding-related concurrency failures?

test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 86:

> 84:     @ParameterizedTest
> 85:     @MethodSource("charsets")
> 86:     void testMultipleZipFileInstances(final Charset entryNameCommentCharset) throws Exception {

The Charset parameter could be renamed to `charset`.

test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 111:

> 109:         private final CountDownLatch startLatch;
> 110: 
> 111:         private ZipEntryIteratingTask(final Path file, final Charset entryNameCharset,

The Charset parameter/field could be renamed to `charset`.

test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 127:

> 125:             try (final ZipFile zf = new ZipFile(this.file.toFile(), this.entryNameCharset)) {
> 126:                 final var entries = zf.entries();
> 127:                 while (entries.hasMoreElements()) {

I think it would be good to include a call to `ZipFile::getEntry` here as well, since that exercises a separate code path.

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

PR Review: https://git.openjdk.org/jdk/pull/23986#pullrequestreview-2683167953
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1994186951
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1994208216
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1994206617
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r1994204441

From bchristi at openjdk.org  Thu Mar 13 19:57:57 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 13 Mar 2025 19:57:57 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
In-Reply-To: 
References: 
Message-ID: 

On Fri, 7 Mar 2025 23:17:53 GMT, Kim Barrett  wrote:

> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.

Changes requested by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23952#pullrequestreview-2683222409

From bchristi at openjdk.org  Thu Mar 13 19:57:58 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 13 Mar 2025 19:57:58 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 Mar 2025 19:57:23 GMT, Kim Barrett  wrote:

>> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 142:
>> 
>>> 140:                 // while there are registered cleanables for other objects.
>>> 141:                 // If the application cleans all remaining cleanables, there
>>> 142:                 // won't be any references enqueued to unblock this.  Using a
>> 
>> I agree that calling `queue.remove()` with a timeout is the right approach.
>> But I have a question:
>> In the case where the Cleaner's `CleanerCleanable` has already run, and we get to processing the last registered cleanable on `activeList`:
>> When we do the `ref.clean()`, the `activeList` becomes empty, and we'll drop out of the `while()` loop. So I'm not seeing how we would attempt another `queue.remove()` in this case.
>> What am I missing?
>
> You are missing that this loop is not the only place that potentially removes
> references from `activeList`. The application may also do so, when directly
> cleaning (as part of a `close()` operation or the like). So the cleaner's
> cleanable may be dropped, removed, and cleaned but with live entries still in
> `activeList`, and this loop ends up blocked in `remove` because there's
> nothing for it to do.  The application later closes all of the remaining
> entries in the `activeList`, which doesn't cause anything to be enqueued on
> the cleaner's queue, so the cleaner thread remains blocked in `remove`.  But
> now `activeList` is empty and will never be added to, and the queue is also
> empty, and the thread is blocked in `remove` with nothing (other than the
> timeout) to break it out.

Got it, thanks.

I'd like to suggest a small update:
_If the application explicitly calls clean() on all remaining Cleanables, there..._

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23952#discussion_r1994219044

From duke at openjdk.org  Thu Mar 13 21:41:52 2025
From: duke at openjdk.org (Jie Lu (George))
Date: Thu, 13 Mar 2025 21:41:52 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

Hi Dmitry. Thank you for putting up the pull request.

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

Marked as reviewed by Lujie1996 at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/24034#pullrequestreview-2683424851

From liach at openjdk.org  Fri Mar 14 00:06:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Mar 2025 00:06:24 GMT
Subject: RFR: 8351996: Alternative way to ensure no stale values for
 ClassValue::remove
Message-ID: 

The recent patch #23866 violated a long standing contract that calling `ClassValue::remove()` from `ClassValue::computeValue()` should be no-op and exit normally. This behavior caters to a very niche case (why do you remove if you know you are currently computing this item?), but is tested and is required to ensure compatibility.

To resolve the issue found in [JDK-8351045](https://bugs.openjdk.org/browse/JDK-8351045), I discovered that calling `ClassValue::get` between the setup of new input values for `computeValue` and the call to `ClassValue::remove` can serve as a barrier to prevent such a stale value, as described in the `ClassValue::remove` specification:


     * This does not remove the threat of a stale value, since there is a window of time
     * between the return of {@code computeValue} in {@code T} and the installation
     * of the new value.  No user synchronization is possible during this time.


I have added API notes on the method to describe this race and the solution.  The original test to verify the old fix is also updated to use the new call pattern, and indeed the pattern eliminates that race.  Otherwise, the code is effectively reverted to before #23866.

This patch does not intend to undergo CSR review. The usage notes belong to the API notes and don't require a CSR review in theory. Please inform me if you think this needs a CSR.

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

Commit messages:
 - 8351996: Alternative way to ensure no stale values for ClassValue::remove

Changes: https://git.openjdk.org/jdk/pull/24043/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351996
  Stats: 93 lines in 2 files changed: 62 ins; 15 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043

From vaivanov at openjdk.org  Fri Mar 14 01:10:49 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 14 Mar 2025 01:10:49 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v3]
In-Reply-To: 
References: 
Message-ID: 

> The synchronized scope was reduced from whole methods to sections that need hash map access control. The tier1 and jaxp tests are OK. The score of the specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported scores are:
> original: 1vCPU - 148.4, 112vCPU - 12743.4, 224vCPU - 13481.31 ops/m
> patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m
> 
> According to the JFR the locking time for XMLReader object reduced from ~27sec to ~20sec for 224vCPU run.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  8346230 [perf] scalability issue for the specjvm2008::xml.transform workload

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23185/files
  - new: https://git.openjdk.org/jdk/pull/23185/files/90c25906..95590eb6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=01-02

  Stats: 42 lines in 1 file changed: 0 ins; 20 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23185/head:pull/23185

PR: https://git.openjdk.org/jdk/pull/23185

From vaivanov at openjdk.org  Fri Mar 14 01:28:34 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 14 Mar 2025 01:28:34 GMT
Subject: RFR: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload [v4]
In-Reply-To: 
References: 
Message-ID: 

> The synchronized scope was reduced from whole methods to sections that need hash map access control. The tier1 and jaxp tests are OK. The score of the specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported scores are:
> original: 1vCPU - 148.4, 112vCPU - 12743.4, 224vCPU - 13481.31 ops/m
> patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m
> 
> According to the JFR the locking time for XMLReader object reduced from ~27sec to ~20sec for 224vCPU run.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  8346230 [perf] scalability issue for the specjvm2008::xml.transform workload

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23185/files
  - new: https://git.openjdk.org/jdk/pull/23185/files/95590eb6..9864851b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=02-03

  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23185/head:pull/23185

PR: https://git.openjdk.org/jdk/pull/23185

From iklam at openjdk.org  Fri Mar 14 05:33:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Mar 2025 05:33:04 GMT
Subject: RFR: 8352001: AOT cache should not contain classes injected into
 built-in class loaders
Message-ID: 

During an application's training run, it's possible to inject classes into the built-in platform/app class loaders with reflection calls. 

- Before [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), only the names of these classes were recorded in the AOT config file. When the AOT cache is generated, these classes are automatically filtered out.
- Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), these classes are stored as parsed InstanceKlasses in the AOT config file, and will be transferred into the AOT cache. This new behavior may cause some applications to fail, as they may inject bytecodes that have environment dependencies.

For safety, this PR filters out such injected classes from the AOT config file.

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

Commit messages:
 - 8352001: AOT cache should not contain classes injected into built-in class loaders

Changes: https://git.openjdk.org/jdk/pull/24046/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24046&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352001
  Stats: 238 lines in 10 files changed: 233 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24046/head:pull/24046

PR: https://git.openjdk.org/jdk/pull/24046

From dl at openjdk.org  Fri Mar 14 09:36:43 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 14 Mar 2025 09:36:43 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v11]
In-Reply-To: 
References: 
Message-ID: 

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Use TC_MASK in accord with https://bugs.openjdk.org/browse/JDK-8330017 (Unnecessarily for now.)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/172a235b..9b51b7a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=09-10

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From mbaesken at openjdk.org  Fri Mar 14 11:20:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Mar 2025 11:20:52 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
Message-ID: 

On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

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

Commit messages:
 - JDK-8352015

Changes: https://git.openjdk.org/jdk/pull/24054/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352015
  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24054/head:pull/24054

PR: https://git.openjdk.org/jdk/pull/24054

From mbaesken at openjdk.org  Fri Mar 14 11:20:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Mar 2025 11:20:52 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken  wrote:

> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

Example lib sizes in jdk head opt build on Linux x86_64 with gcc 13.2.0  are  68K without the patch and 72K with the patch, so fortunately no large size increase is seen.

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

PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724370568

From ihse at openjdk.org  Fri Mar 14 11:36:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Mar 2025 11:36:58 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken  wrote:

> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

What testing have you run?

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

PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724411872

From jkern at openjdk.org  Fri Mar 14 11:52:40 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 14 Mar 2025 11:52:40 GMT
Subject: RFR: 8352046: AIX: Test testEcoFriendly() in
 /jdk/tools/launcher/ExecutionEnvironment.java makes no sense for aix and musl
Message-ID: 

The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. So we skip this sub test for aix and musl.

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

Commit messages:
 - JDK-8352046

Changes: https://git.openjdk.org/jdk/pull/24055/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352046
  Stats: 32 lines in 1 file changed: 7 ins; 13 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24055/head:pull/24055

PR: https://git.openjdk.org/jdk/pull/24055

From alanb at openjdk.org  Fri Mar 14 11:55:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Mar 2025 11:55:56 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken  wrote:

> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

In addition to testing, I assume this will require dig into why compile/other issue was being worked around at the time.

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

PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724448874

From ihse at openjdk.org  Fri Mar 14 12:05:08 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Mar 2025 12:05:08 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 11:53:33 GMT, Alan Bateman  wrote:

>> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
>> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.
>
> In addition to testing, I assume this will require dig into why compile/other issue was being worked around at the time.

@AlanBateman This seems to be part of the same change which introduced "Full Debug Symbols" (FDS), and which took a conservative approach. See Erik's comment https://github.com/openjdk/jdk/pull/23966#issuecomment-2714883676.

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

PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724480497

From clanger at openjdk.org  Fri Mar 14 12:36:34 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 14 Mar 2025 12:36:34 GMT
Subject: RFR: 8351842: Test issues on Windows with combination of
 --enable-linkable-runtime and --with-external-symbols-in-bundles=public
Message-ID: 

Alternative approach to #24012

This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink.

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

Commit messages:
 - JDK-8351842

Changes: https://git.openjdk.org/jdk/pull/24057/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24057&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351842
  Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24057/head:pull/24057

PR: https://git.openjdk.org/jdk/pull/24057

From mbaesken at openjdk.org  Fri Mar 14 12:47:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Mar 2025 12:47:57 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 11:34:08 GMT, Magnus Ihse Bursie  wrote:

> What testing have you run?

I put it into our testing queue, this runs jtreg tier 1 - 4 and some more stuff over the weekend on all our platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724577126

From alanb at openjdk.org  Fri Mar 14 13:41:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Mar 2025 13:41:55 GMT
Subject: RFR: 8351842: Test issues on Windows with combination of
 --enable-linkable-runtime and --with-external-symbols-in-bundles=public
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer  wrote:

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 226:

> 224:                             if (Files.exists(strippedPath)) {
> 225:                                 path = strippedPath;
> 226:                             }

This is super weird to put here. I could imagine introducing a Windows specific plugin or option for jlink to help with this setup but I don't think we should rush into a change to JRTArchive to workaround this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995601023

From ihse at openjdk.org  Fri Mar 14 13:57:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Mar 2025 13:57:51 GMT
Subject: RFR: 8351842: Test issues on Windows with combination of
 --enable-linkable-runtime and --with-external-symbols-in-bundles=public
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 13:38:51 GMT, Alan Bateman  wrote:

>> Alternative approach to #24012
>> 
>> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
>> 
>> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 226:
> 
>> 224:                             if (Files.exists(strippedPath)) {
>> 225:                                 path = strippedPath;
>> 226:                             }
> 
> This is super weird to put here. I could imagine introducing a Windows specific plugin or option for jlink to help with this setup but I don't think we should rush into a change to JRTArchive to workaround this.

A jlink plugin sounds like a reasonable approach to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995629113

From sgehwolf at openjdk.org  Fri Mar 14 14:16:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Mar 2025 14:16:55 GMT
Subject: RFR: 8351842: Test issues on Windows with combination of
 --enable-linkable-runtime and --with-external-symbols-in-bundles=public
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer  wrote:

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

Could we change the synopsis of the bug to something like `Handle Windows specific combination of JEP 493 and --with-external-symbols-in-bundles=public`?

make/Bundles.gmk line 248:

> 246:           %.stripped.pdb, \
> 247:           $(call FindFiles, $(SYMBOLS_IMAGE_DIR)) \
> 248:       )

Why filter *.stripped.pdb? Because they are useless for debugging? Then it should be mentioned as a comment.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 220:

> 218:                         // Read from the base JDK image.
> 219:                         Path path = BASE.resolve(m.resPath);
> 220:                         // special case to handle stripped pdb files, e.g. --with-external-symbols-in-bundles=public

Suggestion:

                        // Windows debug symbols special case to handle stripped pdb files. For example builds
                        // configured with --with-external-symbols-in-bundles=public

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 224:

> 222:                             String strippedFile = m.resPath.substring(0, m.resPath.lastIndexOf(".pdb")) + ".stripped.pdb";
> 223:                             Path strippedPath = BASE.resolve(strippedFile);
> 224:                             if (Files.exists(strippedPath)) {

Suggestion:

                            // With --with-external-symbols-in-bundles=public configuration, stripped
                            // pdb files will be present in the image *in addition* to non-stripped pdb
                            // files. Since the JMODs at build time only include stripped pdb files
                            // (without '.stripped.' in their name), we need to do the same here so that
                            // actually the same file content gets checked. Remember: *.stripped.pdb
                            // files will only exist for builds configured with
                            // --with-external-symbols-in-bundles=public configured builds. Exists check
                            // is present to allow for regular windows builds as well.
                            if (Files.exists(strippedPath)) {

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

PR Review: https://git.openjdk.org/jdk/pull/24057#pullrequestreview-2685668451
PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995654219
PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995652710
PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995642566

From tschatzl at openjdk.org  Fri Mar 14 14:28:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 14 Mar 2025 14:28:57 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v17]
In-Reply-To: 
References: 
 
 <0w7seS1tIFhUxnmStxQySISWVfpBBsRmUtx7EoTy9a4=.509a3d5e-56d0-4fd8-8896-51835b14302b@github.com>
 
Message-ID: <58jXaIS3TNN9Y9xWGSKWM7B4C0dbZ6YxRWjPMmBeFnY=.506b75a0-12a4-424c-869c-8358195947d9@github.com>

On Wed, 12 Mar 2025 13:56:57 GMT, Thomas Schatzl  wrote:

>> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 263:
>> 
>>> 261: 
>>> 262:     SuspendibleThreadSetLeaver sts_leave;
>>> 263:     VMThread::execute(&op);
>> 
>> Can you elaborate what synchronization this VM op is trying to achieve?
>
> Memory visibility for refinement threads for the references written to the heap. Without them, they may not have received the most recent values.
> This is the same as the `StoreLoad` barriers synchronization between mutator and refinement threads imo.

There has been a discussion about whether this is actually needed. Initially we thought that this could be removed because it's only the refinement worker threads that would need memory synchronization, and the memory synchronization is handled by just starting up the refinement threads.

However the rebuild remsets process (marking threads) also access the global card table reference to mark the to-collection-set cards and its value must be synchronized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1995683088

From tschatzl at openjdk.org  Fri Mar 14 14:37:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 14 Mar 2025 14:37:27 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v20]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * ayang review
    * re-add STS leaver for java thread handshake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/78611173..51a9eed8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=18-19

  Stats: 15 lines in 1 file changed: 5 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From sgehwolf at openjdk.org  Fri Mar 14 14:58:53 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Mar 2025 14:58:53 GMT
Subject: RFR: 8351842: Test issues on Windows with combination of
 --enable-linkable-runtime and --with-external-symbols-in-bundles=public
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 14 Mar 2025 13:55:26 GMT, Magnus Ihse Bursie  wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 226:
>> 
>>> 224:                             if (Files.exists(strippedPath)) {
>>> 225:                                 path = strippedPath;
>>> 226:                             }
>> 
>> This is super weird to put here. I could imagine introducing a Windows specific plugin or option for jlink to help with this setup but I don't think we should rush into a change to JRTArchive to workaround this.
>
> A jlink plugin sounds like a reasonable approach to me.

I don't see how a jlink plugin could help with this. The plugin-pipeline runs after the archive resources have been processed (i.e. the latter feed into the former). If archive processing fails you won't get to plugin processing.

With that said, I agree with Alan, this isn't a good place to deal with this. We'd have two special cases - 1) in the build system that copies over full pdb files 2) here in jlink to deal with the result of (1).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1995732524

From jkern at openjdk.org  Fri Mar 14 15:47:25 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 14 Mar 2025 15:47:25 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
Message-ID: 

After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.

Now with this change we can enable the statically linked launcher target again.
There are 3 things to do.
1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

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

Commit messages:
 - JDK-8352064

Changes: https://git.openjdk.org/jdk/pull/24062/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352064
  Stats: 66 lines in 5 files changed: 60 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

PR: https://git.openjdk.org/jdk/pull/24062

From myankelevich at openjdk.org  Fri Mar 14 15:55:59 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 14 Mar 2025 15:55:59 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
In-Reply-To: 
References: 
Message-ID: <-KaqHKLWJTwsD-p4RwASOCTTiv3FHlq59aj1_jHx98I=.8b310628-fbb9-46fd-9bba-49ae7ea5c56b@github.com>

On Thu, 13 Mar 2025 19:01:03 GMT, Joe Wang  wrote:

> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.

Looks good to me, just a few very minor questions. Thank you

test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 51:

> 49:  * @test
> 50:  * @bug 8344800 8345353 8351969
> 51:  * @modules java.xml/jdk.xml.internal

I know that this is not a part of your change, but this (line 56) doesn't seem to be used at all. Could you please remove it if there will be another revision? If not it's ok as is ? 
`static String CLS_DIR = System.getProperty("test.classes");`

test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 71:

> 69:     static final String ROOT_ELEMENT = "{{rootElement}}";
> 70: 
> 71:     Catalog jdkCatalog;

Nitpick: if this will stay as a global var I'd personally make it private and move to the top of the file. What do you think?

test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 78:

> 76:      */
> 77:     @DataProvider(name = "DTDsInJDKCatalog")
> 78:     public Object[][] getDTDsInJDKCatalog() throws Exception {

Nit: Don't think `throw exception` is doing anything here.

test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 143:

> 141:         // initialize JDKCatalog
> 142:         JdkCatalog.init("continue");
> 143:         jdkCatalog = JdkCatalog.catalog;

This seems to be a set up just for 1 test. Do you think it might be better to have this logic in the beginning of the `testDTDsInJDKCatalog`?

test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 155:

> 153:     @Test(dataProvider = "DTDsInJDKCatalog")
> 154:     public void testDTDsInJDKCatalog(String publicId, String systemId)
> 155:             throws Exception {

Nit: Don't think `throw exception` is doing anything here.

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

PR Review: https://git.openjdk.org/jdk/pull/24039#pullrequestreview-2685934886
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r1995807656
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r1995788572
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r1995810396
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r1995785004
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r1995810329

From ihse at openjdk.org  Fri Mar 14 16:09:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Mar 2025 16:09:02 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
Message-ID: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>

We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

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

Commit messages:
 - 8352044: Add --with-import-jvms to configure

Changes: https://git.openjdk.org/jdk/pull/24063/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352044
  Stats: 79 lines in 4 files changed: 70 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24063/head:pull/24063

PR: https://git.openjdk.org/jdk/pull/24063

From shade at openjdk.org  Fri Mar 14 16:34:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 14 Mar 2025 16:34:58 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie  wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

This change copies `libjvm.so` _and_ sibling `.jsa` files, right?

If so, then one thing is missing: regenerating CDS archives that have opinions on `modules` filesizes/dates for fingerprinting their CDS archives. My frankensteining scripts do that by invoking new JVM explicitly with `-Xshare:dump`. But build system should already know how to do that, as it does it at the end of the build.

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

PR Review: https://git.openjdk.org/jdk/pull/24063#pullrequestreview-2686128808

From tschatzl at openjdk.org  Fri Mar 14 16:35:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 14 Mar 2025 16:35:38 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v21]
In-Reply-To: 
References: 
Message-ID: <1bH6bLmIYx6eVtZ4IPlFtdYpdCAwSaNB6w0uNljTSJE=.8a4a88c7-2f66-493c-91dd-6fc6c744c08f@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' into 8342381-card-table-instead-of-dcq
 - * ayang review
     * re-add STS leaver for java thread handshake
 - * when aborting refinement during full collection, the global card table and the per-thread card table might not be in sync. Roll forward during abort of the refinement in these situations.
   * additional verification
   * added some missing ResourceMarks in asserts
   * added variant of ArrayJuggle2 that crashes fairly quickly without these changes
 - * ayang review
     * remove unnecessary STSleaver
     * some more documentation around to_collection_card card color
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * optimized RISCV gen_write_ref_array_post_barrier() implementation contributed by @RealFYang
 - * fix card table verification crashes: in the first refinement phase, when switching the global card tables, we need to re-check whether we are still in the same sweep epoch or not. It might have changed due to a GC interrupting acquiring the Heap_lock. Otherwise new threads will scribble on the refinement table.
   Cause are last-minute changes before making the PR ready to review.
   
     Testing: without the patch, occurs fairly frequently when continuously
   (1 in 20) starting refinement. Does not afterward.
 - * ayang review 3
     * comments
     * minor refactorings
 - * iwalulya review
     * renaming
     * fix some includes, forward declaration
 - * fix whitespace
   * additional whitespace between log tags
   * rename G1ConcurrentRefineWorkTask -> ...SweepTask to conform to the other similar rename
 - ... and 18 more: https://git.openjdk.org/jdk/compare/7f428041...b0730176

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=20
  Stats: 6761 lines in 99 files changed: 2368 ins; 3464 del; 929 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From erikj at openjdk.org  Fri Mar 14 17:38:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 14 Mar 2025 17:38:58 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern  wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

make/StaticLibs.gmk line 116:

> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \

The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:

Suggestion:

#    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \


You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1996001131

From ihse at openjdk.org  Fri Mar 14 18:35:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Mar 2025 18:35:12 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com>
Message-ID: 

On Fri, 14 Mar 2025 16:32:39 GMT, Aleksey Shipilev  wrote:

> This change copies `libjvm.so` _and_ sibling `.jsa` files, right?

No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm.

Maybe we should point to an import JVM directory, and copy it with all its files, and not just try to single out the libjvm.so. That will allow imported JVMs to tag along any kind of files they want.

> Try to import a JVM and do `java -Xshare:on Hello`?

The problem is that we can't really count on -Xshare being supported on an imported JVM.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725393724
PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725396677

From shade at openjdk.org  Fri Mar 14 18:35:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 14 Mar 2025 18:35:13 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: 
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com>
 
Message-ID: 

On Fri, 14 Mar 2025 17:57:31 GMT, Magnus Ihse Bursie  wrote:

> No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm.

Aha. Importing CDS archives without regenerating them is futile, IIRC: they would never load properly, CDS would get disabled, and we would just carry dead weight.

> Maybe we should point to an import JVM directory, and copy it with all its files, and not just try to single out the libjvm.so. That will allow imported JVMs to tag along any kind of files they want.

Yes. There are also debuginfo files that you certainly want.

> The problem is that we can't really count on -Xshare being supported on an imported JVM.

This is suggestion for testing CDS support. We don't need to do `-Xshare:on` tests from a build system.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725450392

From joehw at openjdk.org  Fri Mar 14 18:35:22 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 14 Mar 2025 18:35:22 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update the test: change variables and etc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24039/files
  - new: https://git.openjdk.org/jdk/pull/24039/files/c423ef99..4482d590

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24039&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24039&range=00-01

  Stats: 41 lines in 1 file changed: 8 ins; 23 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24039/head:pull/24039

PR: https://git.openjdk.org/jdk/pull/24039

From joehw at openjdk.org  Fri Mar 14 18:37:58 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 14 Mar 2025 18:37:58 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
In-Reply-To: 
References: 
Message-ID: <1QNFmbAQK8Q_F1sOPLf3XQSUQ8enU4tpNfctudsYu74=.54ca3f1f-3745-456a-b22b-de50aacebf3f@github.com>

On Thu, 13 Mar 2025 19:01:03 GMT, Joe Wang  wrote:

> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.

Thanks for review. Updated the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/24039#issuecomment-2725473314

From rriggs at openjdk.org  Fri Mar 14 18:39:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Mar 2025 18:39:38 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
Message-ID: 

Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

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

Commit messages:
 - 8351970: Retire JavaLangAccess::exit

Changes: https://git.openjdk.org/jdk/pull/24066/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351970
  Stats: 13 lines in 3 files changed: 0 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24066/head:pull/24066

PR: https://git.openjdk.org/jdk/pull/24066

From rgiulietti at openjdk.org  Fri Mar 14 19:03:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 14 Mar 2025 19:03:51 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: 
References: 
Message-ID: <4kjDoe01Av7cEkYrTuBsXVxrFScbCsyhWPkc44GpNb4=.8b0fbb2d-71ed-4533-8280-17d4b18cedf1@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs  wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Looks fine.

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2686559418

From rriggs at openjdk.org  Fri Mar 14 19:47:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Mar 2025 19:47:52 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs  wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

There are other non-recoverable errors that occur in the runtime that throw InternalError or AssertionError instead of calling System.exit. Calling System.exit seems like overkill. 
I did not find any discussion in the review of 8304265: Implementation of Foreign Function and Memory API with respect to that necessity. (https://git.openjdk.org/jdk/pull/13079)

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

PR Comment: https://git.openjdk.org/jdk/pull/24066#issuecomment-2725605716

From dholmes at openjdk.org  Fri Mar 14 21:01:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Mar 2025 21:01:52 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: 
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <1TtWqb5V75a8IDeaWnUO847ytcG09nuHF47Phi0grD4=.155cccfb-9158-4134-bbb1-348f0a4eb0ba@github.com>
 
Message-ID: 

On Fri, 14 Mar 2025 17:58:50 GMT, Magnus Ihse Bursie  wrote:

>> This change copies `libjvm.so` _and_ sibling `.jsa` files, right?
>> 
>> If so, then one thing is missing: regenerating CDS archives that have opinions on `modules` filesizes/dates for fingerprinting their CDS archives. My frankensteining scripts do that by invoking new JVM explicitly with `-Xshare:dump`. But build system should already know how to do that, as it does it at the end of the build.
>> 
>> Try to import a JVM and do `java -Xshare:on Hello`?
>
>> Try to import a JVM and do `java -Xshare:on Hello`?
> 
> The problem is that we can't really count on -Xshare being supported on an imported JVM.

@magicus I'm trying to see the big picture here of all the changes you are proposing and I'm really not seeing it. This seems to be making it more difficult to create a JDK/JRE with multiple VMs.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2725744927

From liach at openjdk.org  Fri Mar 14 23:07:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Mar 2025 23:07:51 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs  wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2687035378

From davidalayachew at gmail.com  Fri Mar 14 23:13:58 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 14 Mar 2025 19:13:58 -0400
Subject: Question about IO.println
In-Reply-To: 
References: 
 
Message-ID: 

Hey Stuart,

Thanks for the response. Just to confirm, you are saying that IO.println
would have a method that takes in StringTemplates? Or is it a case of
calling join on our tenplates, and the IO API remains unchanged?

Either way, StringTemplates are going to have a rippling effect on the Java
ecosystem. I'm excited for it.

On Fri, Mar 7, 2025, 4:14?PM Stuart Marks  wrote:

> Hi,
>
> Our goal with the IO class is to have it add as few mechanisms as
> possible. Anything
> it can do, one should easily be able to do with existing classes like
> PrintStream or
> BufferedReader. So, we wouldn't add a varargs method to IO itself without
> having one
> in PrintStream or something.
>
> Now, should PrintStream have a varargs overload of println? Well, println
> first
> appeared in JDK 1.0 well before varargs existed and the answer then was to
> use the +
> string concatenation operator for multiple values. This still works,
> though there
> are cases where it doesn't work very well.
>
> When varargs was added (5.0) PrintStream got printf with varargs, but
> println wasn't
> retrofitted with varargs.
>
> And there will be string templates, which will allow one to embed multiple
> values
> unobtrusively, so there's no need for varargs here. And a string templates
> should be
> directly usable from IO.println, so it'll come for "free".
>
> Thus I don't see a need to add varargs overloads here.
>
> s'marks
>
>
>
> On 3/4/25 5:03 AM, David Alayachew wrote:
> > Hello Amber Dev Team and Core Libs Dev Team,
> >
> > Another reddit discussion popped up today about IO.println(), and one of
> the
> > comments mentioned that they wanted something along the lines of this.
> >
> > IO.println(num1, num2, num3); //prints out "1 2 3"
> >
> > I proposed that maybe a better option would be a String.join overload.
> So, instead
> > of String.join(String delim, String... elements), there would be
> String.join(String
> > delim, Object... elements), with each object getting toString() called
> on it.
> >
> > What are your thoughts on either of these ideas? I actually think the
> IO.println()
> > version is nice, but I felt like String.join made a slightly better
> compromise.
> >
> > Another commentor mentioned that this will be easier with String
> Templates too, so
> > maybe it is better to wait for that. I don't think String templates are
> a bad idea
> > here, but it also felt like overkill imo. A library function seems like
> a better fit.
> >
> > Thank you for your time and thoughts.
> > David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tschatzl at openjdk.org  Sat Mar 15 13:12:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Sat, 15 Mar 2025 13:12:39 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v22]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * more documentation on why we need to rendezvous the gc threads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/b0730176..447fe39b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=20-21

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From liach at openjdk.org  Sat Mar 15 16:02:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 15 Mar 2025 16:02:17 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

Removing these two tags generated from `PreviewFeatures` and `JavaUtilCollectionAccess`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2726753687

From markus at headcrashing.eu  Sat Mar 15 17:58:09 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sat, 15 Mar 2025 18:58:09 +0100
Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an
 efficient alternative to java.io.StringWriter
In-Reply-To: 
References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu>
 
 
 
 <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu>
 <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
 <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>
 
 
Message-ID: <1b7d9c21-bfb1-43d1-945d-5d8597000968@headcrashing.eu>

Chen,

thank you for sharing your opinion!

Thinking about what you wrote about the "trifecta" complexity, I think 
it might be better to restart my idea from scratch:

As explained in my original proposal 
(https://mail.openjdk.org/pipermail/core-libs-dev/2024-December/137807.html), 
the actual driver for my proposal was to provide a StringWriter 
alternative which solves two main problems: It shall prevent String 
copies, and it shall be non-synchronized.

What comes into mind is: Writer.of(StringBuilder).

While compared to Appendable this signature is much less flexible, it 
also makes less headaches, but solved in fact those 99% of cases that 
triggered this whole idea: It does not create String copies, and it is 
non-synchronized. What this writer would simply, simply would be routing 
all incoming "append" and "write" calls down to the provided string builder.

Hence, kindly asking for comments on this updated idea: WDYT about 
Writer.of(StringBuilder)?

Thanks!

-Markus


Am 10.02.2025 um 01:51 schrieb Chen Liang:
> Hi Mark,
> After thinking about the Appendable-Closeable-Flushable trio versus 
> Writer, I believe that one problem with Writer.of is that it goes 
> against interface segregation principle represented by the trifecta, 
> and accidentally leaking the Closeable or Flushable functionality is 
> still dubious to me. This appears simple, but it may cause unintended 
> consequences, such as if Appendable b implements Closeable too, its 
> closing behavior is not proxied and users may find this inconsistency 
> weird. And as for interface segregation principle, it means APIs 
> should request Appendable instead of Writer if they only need writing 
> abilities with no lifecycle; using Writer as the type implies 
> potential dependency on closing/flushing behavior, which can sometimes 
> be dangerous.

From mukulg at apache.org  Sat Mar 15 18:33:30 2025
From: mukulg at apache.org (Mukul Gandhi)
Date: Sun, 16 Mar 2025 00:03:30 +0530
Subject: Xalan-J xsl 3 within openjdk
Message-ID: 

Hi all,
    Few days ago, I've suggested on this list to try having latest Xalan-J
XSLT 3.0 development code (it's available here,
https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn. IMHO, I've
written all XSLT 3 and corresponding XPath 3.1 changes within Xalan-J's XSL
3 dev repos branch as mention previously within this mail) included within
latest openjdk codebase. I think, Xalan-J's compliance with XSLT 3.0 spec
is nice, except I think few XSLT 3 features that can be implemented in due
course. XSLT 3.0 streaming spec is kind of planned not to be implemented in
Xalan-J.

It was also suggested within this list previously to know, what is
Xalan-J's compliance with W3C XSLT 3.0 test suite. I'll find it helpful if,
someone on this list having interest in this topic (perhaps, Joe Wang
@Oracle may suggest) volunteers to write Xalan-J XSLT 3 test driver for W3C
XSLT 3.0's test suite, which could give us knowledge about Xalan-J's
compliance with W3C XSLT 3.0 test suite.

Any thoughts please?

Many thanks.


Regards,
Mukul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sat Mar 15 23:32:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 15 Mar 2025 23:32:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: 
References: 
Message-ID: 

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG  wrote:

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

> Regarding your actual question, I do understand your idea and while originally I had the same in mind (it really _is_ appealing!), I came up with a draft using the original `String.getChars()` signature instead, due to the following drawbacks:
>
> * There might exist (possibly lotsof) `CharSequence.getChars(int, int, char[], int)` implementations already, as this problem (and the idea how to solve it) is anything but new. At least such implementations are `String`, `StringBuilder` and `StringBuffer`. If we come up with a different signature, then **none** of these already existing performance boosters will get used by `Reader.of(CharSequence)` automatically - at least until they come up with alias methods. Effectively this leads to (possibly lots) of alias methods. At least it leads to alias methods in `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`. In contrast, when keeping the signature copied from `String.getChars`, chances are good that (possibly lots of) implementations will _instantly_ be supported by `Reader.of(CharSequence)` without alias methods. At least, `String`, `StringBuilder` and `StringBuffer` will be.
>
> * Since decades people are now very used to `StringBuilder.getChars(int, int, char[], int)`, so (possibly a lot of) people might simply _expect_ us to come up with that lengthy signature. These people might be rather confused (if not to say frustrated) when we now force them to write an intermediate `subSequence(int, int)` for something that was "such simple" before.
>
> * Custom implementations of `CharSequence.subSequence` could come up with the (performance-wise "bad") idea of creating **copies** instead of views. At least it seems like `AbstractStringBuilder` is doing that, so chances are "good" that custom libs will do that, too. For example, because they need it for safety. Or possibly, because they have a technical reason that _enforces_ a copy. That would (possibly massively, depending on the actual class) spoil the idea of performance-boosting this PR is actually all about.

Kindly asking for more comments! Something I am missing? Some good reason to *not* adopt my proposal?

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2727054654

From jrose at openjdk.org  Sat Mar 15 23:54:01 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 15 Mar 2025 23:54:01 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

I'm surprised to see `@ForceInline` in the offset query functions in `Unsafe`.  Those are not on any fast path I'm aware of.  What use case does this annotation address?  If none, consider deleting; it will be a future maintenance puzzle.  Or at least document in a comment why a slow path function needs such an annotation.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2727063749

From jrose at openjdk.org  Sun Mar 16 00:37:03 2025
From: jrose at openjdk.org (John R Rose)
Date: Sun, 16 Mar 2025 00:37:03 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

(I am reading the patch, not playing with javadoc or live API, so I might be mis-reading what's going on, so apologies in advance if this is beside the point.)

Comments on visual noise and side effects in `toString`.

`renderWrapped` is clever for a single stable value, but it makes for a very noisy display string, with confusing doubly-nested `[]`, for composite stable values.  I'm talking about `StableFunction` mainly, I guess.

I suggest omitting the inner `[]` for such composites.  A simple boolean on `renderWrapped` will do that trick.  In that case, `renderWrapped` has the job of either presenting a fixed (recognizable) sentinel string, or else forwards, without further editorial comment, to the `toString` of the contained value.

I see that, probably due to prior `java.util` contracts, a stable list or map cannot present a `toString` with unset component values.  A stable list or map uses a ?canned? `toString` method that calls `get`, which must force all component values to be evaluated before the `toString` can be printed.

This may greatly annoy users of IDEs, which invoke `toString` (via JVMTI) to display program states.  IDE users don?t expect mere observation of program states to change program states.  This may be a blocker for some would-be adopters of `StableValue`.

Just as `WeakHashMap` bends the `Map` API (regarding `equals`), I think `StableValue` composites should bend the `List` and `Map` APIs, regarding `toString`.  Sometimes the contracts have to be bent for the whole design to fit together.

I think the basic rule should be that the `toString` of stable-whatever should have a little "noise" around the outside, to show that it is not just a bare value, but wherever a wrapped value is, that wrapped value should be presented as directly as possible.  Also, the wrapped value should not be forced, but rather a set, recognizable string (such as `` or `.unset`) should appear in place of the value string.

At the very least, the presence of side effects in `toString`, an unusual condition, needs to be documented prominently, where applicable.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2727094395

From jrose at openjdk.org  Sun Mar 16 00:43:59 2025
From: jrose at openjdk.org (John R Rose)
Date: Sun, 16 Mar 2025 00:43:59 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: <67zgwiCMxdlLGVECy3z81-p1EhUUp3BljMzuq7_lYEU=.424b64b6-ee08-41ef-98c1-88e0fc8be3d4@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

(P.S. I do see how fixing `toString` is just the first inch or so of a long? string? of debugging issues.  A JVMTI-based inspector is going to want to call `List::get` as well as `toString`.)

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2727096865

From john.r.rose at oracle.com  Sun Mar 16 01:02:06 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 18:02:06 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: 
 
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: <48649453-7926-4353-8AD7-A62EFD5AAF84@oracle.com>

> Are deeper cycles of concern? I was thinking of this:

There are a couple of ways existing java.util code handles
self-cycles.  The deepToString method handles them at all
levels, so it is robust.  But it is tricky and expensive.
(Look at the variable named ?dejaVu?.)

If you grep for /"(this / in the java.util sources, you
will see several examples of a one-level exclusion of
self-references.  This is what the present PR emulates,
and I think it is just fine to follow those precedents.
It?s a 99% solution.  Omitting the self-check would be
a 90% solution, but the self-check is so simple that,
why not do it?  Adding a ?dejaVu? table is not simple;
don?t.

One thing I noticed, when doing that grep, is that
the type name is usually ?detuned?.  We should do that
as well in this patch.  For example, in Hashtable.java,
the string says ?(this Map)? not ?(this Hashtable)?.
The toString method tilts away from TMI. I think we
have a slight TMI problem in this patch, maybe, and
given the precedents I would expect ?(this Function)?
not ?(this StableEnumFunction)?, etc.

(TMI = Too Much Information.  See also Gafter on
the TMI temptation for language designers, which
applies to API design as well:
https://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html )

I see the PR?s unit tests look at this string.  My
humble take on it is, let?s dial back the TMI before
it?s too late.

(My sensitivity to TMI also informs other comments I
made on this PR.)

From iklam at openjdk.org  Sun Mar 16 02:59:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 16 Mar 2025 02:59:32 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
Message-ID: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>

This PR tries to cut down the use of `WhiteBox` in the HotSpot test cases. It modifies `VMProps` to save the set of VM properties into a file called "vm.properties" under Jtreg's work directory. The new API `jdk.test.lib.VMPropsGetter` loads the properties from this file to pass onto individual test cases.

See `getJtregWorkDir()` for the code that figures out the work directory. It assumes that `VMProps` and all test cases are always executed under

- `workDir/scratch/` ; or
- `workDir/scratch/[0-9]+/` 

This is probably not the right thing to do. I would be better for Jtreg to pass the location of the work directory to the test cases, with a command-line options like `-Djtreg.work.dir=`.

To show the benefit of this PR, I modified a few test cases to remove their use of WhiteBox.

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

Commit messages:
 - 8352107: Allow jtreg test cases to query test VM properties

Changes: https://git.openjdk.org/jdk/pull/24071/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352107
  Stats: 202 lines in 7 files changed: 192 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24071.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24071/head:pull/24071

PR: https://git.openjdk.org/jdk/pull/24071

From jrose at openjdk.org  Sun Mar 16 03:13:00 2025
From: jrose at openjdk.org (John R Rose)
Date: Sun, 16 Mar 2025 03:13:00 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

The example code `class Component` uses a `Supplier` non-static field to hold a singular stable value, in a lambda which does not capture `this`.  It may be best not to claim a solution (yet) for lazy non-statics, so consider making `Component.logger` static.

I'm not saying you should attempt this in the present PR!  But here are some related thoughts, for later.

Solving the problem of lazy statics, using stable suppliers, is a big deal.  It allows single-static-holder-classes to be refactored more cheaply.

Here's why I think non-static lazy fields are not fully addressed by this PR.  (A) Their initializer function should probably not capture `this`, for best performance, and (B) the VM's special casing of non-static fields of type `StableValue` does not extend to fields of type `Supplier`.  (Nor should it.)  But it seems we either need strict fields, or a JVM lockout of instance-supplier fields, to avoid problems with reflective object patching.

You might consider a type `StableSupplier` <: `Supplier` to address (B), but unless (A) is addressed as well there is not an efficient end-to-end solution for lazy non-statics.

(B) will also be addressed (independently) by strict statics.

A full solution might require an indexed version of Supplier (i.e., a restricted Function) which takes `this` whenever needed to evaluate the lazily supplied value.  So there's some cross-connection with the design of stable functions in this PR.

(A stable function which caches one value seems useless, but it exactly fits the use case of a non-static lazy object attribute.  The argument to the function is `this`.  That's the only argument the instance-supplier will ever see.  Every distinct instance of an instance-supplier will only ever see one instance of `this` as its argument value.)


class Component {
  private strict final
      StableInstanceSupplier
          instanceSpecificLogger = StableValue.instanceSupplier(
              self -> Logger.getLogger(Component.class, self.getName() );
}


In today's API you can get this effect but you have redundant bindings of `this` buried in the supplier structure.  As other PR threads have pointed out, it's hard to drop the lambda after its invocation, so as to GC the storage of the bindings.

OTOH, maybe there are more reasons we can't get rid of `this`.  If so, maybe we have arrived at a final state for problem (A): the lambda has to capture `this`, so be it.  But if that's true, we still want a story for problem (B) as well (non-strictness of instance fields).

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2727157600

From john.r.rose at oracle.com  Sun Mar 16 03:19:38 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 20:19:38 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: 
References: 
 
 
Message-ID: <93E21D00-2C99-4278-A6BB-0578F32295F8@oracle.com>

On 13 Mar 2025, at 4:20, Per Minborg wrote:

> ?
>> Reentrancy into here seems really buggy, I would endorse disallowing it >> instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`
>
> StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

+1 from me

A similar level of concern with footprint was in my mind in my
earlier comment, where I claimed that capturing /this/ in a lambda
is suboptimal.  The inefficiency is in object creation and footprint,
since an extra copy of /this/ must be tracked.

>
>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:
>>
>>> 157:     private boolean wrapAndCas(Object value) {
>>> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
>>> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));
>>
>> There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.
>
> This is more of a belt and suspenders solution. It is true that it is redundant. A set volatile would suffice here.

There is a broad choice at the beginning of this design whether
to use a mutex (as  and ClassValue do) or use lock-free
CAS (as condy/indy do).  This API, which is more parallel to
the higher-level  and ClassValue, uses a mutex.

The choice connects to the rules about handling races.  Surely,
two threads can ask concurrently for a SV state, and both may
?suggest? a lambda to give it a value.  Now we come to a fork
in the road:  Do we select at most one lambda to run?  Or,
do we let both lambdas run and then pick a winner?  The first
requires a mutex.  The second is lock-free and uses CAS.

It?s a binary choice.  I don?t think we ever need the belt
and suspenders.  I agree that StableValue is like ClassValue
and not like condy, so it should not be playing with lock
free stuff.  (Or did I forget something??)

? John

From john.r.rose at oracle.com  Sun Mar 16 03:29:28 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 20:29:28 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
Message-ID: <2AEBD2FF-0816-418A-B8A9-C936D942F4D3@oracle.com>

A @Stable field does not need to be volatile.
Avoiding volatile is one of the uses for @Stable.

That said, @Stable is not as foolproof as volatile.
It?s more dangerous, and cheaper.

You have to do a release store to a stable variable.

That?s what the VM does for you automatically for
a final, and a stable is like a delayed final.
But the VM does not give you the release store
automatically; you must do it manually.

That?s why @Stable is an internal feature, and
StableValue is the ?housebroken? version of it.
StableValue has to help the VM maintain the
appearance of a ?final? variable whose initialization
got delayed.  The wrapAndSet method does this job.

This might seem to contradict my previous assertion
that StableValue, being mutex based, must not
use lock-free idioms.  That comment applies
specifically to the update operation that takes
a lambda.  Other operations, such as reading
a SV, or hopefully poking a value at a SV can be,
and should be, composed of lock-free operations.
Why take a lock when it?s just a one-word read
or write?


On 13 Mar 2025, at 9:07, Maurizio Cimadamore wrote:

> On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:
>
>>> Implement JEP 502.
>>>
>>> The PR passes tier1-tier3 tests.
>>
>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>>
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 74:
>
>> 72:     @Override
>> 73:     public boolean trySet(T value) {
>> 74:         if (wrappedContentAcquire() != null) {
>
> IMHO, if our goal is to do:
>
> Object content = this.content;
> if (context != null) return content:
> synchronized (...) {
>     if (context != null) return content:
>     this.context = ...
> }
>
>
> Then we might just use a volatile field and synchronized blocks. I don't see an immediate need for using acquire/release semantics --
> especially when using a monitor. E.g. this should look more like a classic double checked locking idiom. (but with a stable field to make the first volatile read more efficient in case the field is already set)
>
> -------------
>
> PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993850760

From alanb at openjdk.org  Sun Mar 16 07:54:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Mar 2025 07:54:58 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 15 Mar 2025 23:51:36 GMT, John R Rose  wrote:

> I'm surprised to see `@ForceInline` in the offset query functions in `Unsafe`. Those are not on any fast path I'm aware of. What use case does this annotation address? If none, consider deleting; it will be a future maintenance puzzle. Or at least document in a comment why a slow path function needs such an annotation.

Looks like it was added as part of JDK-8149159 in JDK 9 as part of work to improve the argument checking. We have touched this area a few times (for deprecations and warnings mostly) but we missed it.

Part of me wonders if the additional checks in Unsafe are really needed. The first use of offset methods will print a warning to say they are going to be removed in the future. If someone is really determined to hack on a SV then they will just exploit layout and bypass the check. We don't have any deterrent (aside from the first) warning for the more likely case of someone using the offsets to modify a static final.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2727248346

From mbaesken at openjdk.org  Sun Mar 16 13:26:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sun, 16 Mar 2025 13:26:51 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 14 Mar 2025 12:45:23 GMT, Matthias Baesken  wrote:

> > What testing have you run?
> 
> I put it into our testing queue, this runs jtreg tier 1 - 4 and some more stuff over the weekend on all our platforms.

No issues were seen with the patch in the mentioned tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2727422791

From duke at openjdk.org  Sun Mar 16 19:41:02 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 16 Mar 2025 19:41:02 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/util/ImmutableCollections.java line 798:

> 796:                 throw new IndexOutOfBoundsException(i);
> 797:             }
> 798:         }

I think `orElseSet` should be outside of the `try` block, otherwise an `ArrayIndexOutOfBoundsException` thrown by `mapper.apply` will be wrapped.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1488:

> 1486:             final K k = (K) key;
> 1487:             return stable.orElseSet(new Supplier() {
> 1488:                 @Override public V get() { return mapper.apply(k); }});

This can return `null` (`StableMap` does allow `null` values), so the `getOrDefault` implementation in `AbstractImmutableMap` does not properly work for `StableMap`:

var map = StableValue.map(Set.of(1), _ -> null);
// should print "null", but prints "default value"
System.out.println(map.getOrDefault(1, "default value"));

src/java.base/share/classes/jdk/internal/lang/stable/EmptyStableFunction.java line 47:

> 45:     @Override
> 46:     public R apply(T value) {
> 47:         throw new IllegalArgumentException("Input not allowed: " + value);

`StableEnumFunction` and `StableFunction` throw a `NullPointerException` if `value` is `null`.

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 68:

> 66:         } catch (ArrayIndexOutOfBoundsException ioob) {
> 67:             throw new IllegalArgumentException("Input not allowed: " + value, ioob);
> 68:         }

Same here.

src/java.base/share/classes/jdk/internal/lang/stable/StableIntFunction.java line 61:

> 59:             throw new IllegalArgumentException("Input not allowed: " + index, ioob);
> 60:         }
> 61:     }

Same here.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueFactories.java line 77:

> 75:         int i = 0;
> 76:         for (K key : keys) {
> 77:             entries[i++] = Map.entry(key, StableValueImpl.newInstance());

`Map.entry` causes `null` keys to throw a `NullPointerException`, meaning there can't be stable functions/maps with a `null` input/key. They can however have `null` values. Is that intended?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 132:

> 130:         // Prevent reentry
> 131:         if (Thread.holdsLock(this)) {
> 132:             throw new IllegalStateException("Recursing supplier detected: " + supplier);

Is it right to include `supplier` in the message? The actual recursing supplier could be another one:


var s = StableValue.of();
// throws java.lang.IllegalStateException: Recursing supplier detected: supplier 2
s.orElseSet(new Supplier<>() {
    public String toString() {return "supplier 1";}
    public Integer get() {
        s.orElseSet(new Supplier<>() {
            public String toString() {return "supplier 2";}
            public Integer get() {return 2;}
        });
        return 1;
    }
});

The exception message could also be confusing in cases like this:

var s = StableValue.of();
synchronized (s) {
    // throws java.lang.IllegalStateException: Recursing supplier detected
    s.trySet(null);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997660330
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997685354
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997681440
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997660665
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997660937
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997680982
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997689245

From duke at openjdk.org  Sun Mar 16 23:48:52 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sun, 16 Mar 2025 23:48:52 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs  wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2688864196

From liach at openjdk.org  Mon Mar 17 00:44:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 00:44:09 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 16 Mar 2025 16:50:19 GMT, Luca Kellermann  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 798:
> 
>> 796:                 throw new IndexOutOfBoundsException(i);
>> 797:             }
>> 798:         }
> 
> I think `orElseSet` should be outside of the `try` block, otherwise an `ArrayIndexOutOfBoundsException` thrown by `mapper.apply` will be wrapped.

Even better, we should just do a `Preconditions.checkIndex` explicitly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997792857

From liach at openjdk.org  Mon Mar 17 00:47:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 00:47:01 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/jdk/internal/lang/stable/StableValueFactories.java line 71:

> 69:     }
> 70: 
> 71:     public static  Map> map(Set keys) {

I recommend choosing a different name from `map(Set, Function)` for navigation simplicitiy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997794773

From duke at openjdk.org  Mon Mar 17 02:01:59 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 17 Mar 2025 02:01:59 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 16 Mar 2025 00:34:45 GMT, John R Rose  wrote:

> I see that, probably due to prior `java.util` contracts, a stable list or map cannot present a `toString` with unset component values.  A stable list or map uses a ?canned? `toString` method that calls `get`, which must force all component values to be evaluated before the `toString` can be printed.

I also noticed this issue of `toString` eagerly setting all elements of stable collections and agree that it probably shouldn't do this. Note that all views of these collections (obtained via `List.subList`, `List.reversed`, `Map.entrySet`, `Map.values`, etc.) would also need their own `toString` implementation.

> Just as `WeakHashMap` bends the `Map` API (regarding `equals`), I think `StableValue` composites should bend the `List` and `Map` APIs, regarding `toString`.  Sometimes the contracts have to be bent for the whole design to fit together.

Neither `List`, `Set`, nor `Map` mention any requirements for `toString` in their interface specification. Only `AbstractCollection` and `AbstractMap` have a default implementation of `toString`. So I don't think any contract would be bent here.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2727837224

From liach at openjdk.org  Mon Mar 17 02:23:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 02:23:53 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 15 Mar 2025 23:30:21 GMT, Markus KARG  wrote:

> Some good reason to *not* adopt my proposal?

I am still afraid of such a pattern in the future like:

CharSequence cs = ...
if (cs.getClass().getModule() == Object.class.getModule()) {
    // or cs.getClass().getClassLoader() == null
    cs.getChars(...);
} else {
    // damn, can't trust an arbitrary char sequence!
    char[] intermediate = ...
    cs.getChars(...);
    // copy from intermediate etc.
}

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2727862188

From liach at openjdk.org  Mon Mar 17 02:38:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 02:38:08 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 13 Mar 2025 15:36:08 GMT, Maurizio Cimadamore  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/hotspot/share/ci/ciField.cpp line 254:
> 
>> 252: 
>> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
>> 254:   return signature == vmSymbols::java_lang_StableValue_signature();
> 
> Just a note that we will need to decide whether to keep this or not...

We might change this to require stable values to be strict final instead if strict final is previewed at the same time as stable values - https://openjdk.org/jeps/8350458

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997850924

From liach at openjdk.org  Mon Mar 17 02:52:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 02:52:08 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 47:

> 45:  * A stable value is a shallowly immutable holder of deferred content.
> 46:  * 

> 47:  * A {@linkplain StableValue {@code StableValue}} can be created using the factory

This looks weird. I recommend doing `{@code StableValue}` as we are already in the StableValue class and this link won't go anywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997858327

From liach at openjdk.org  Mon Mar 17 02:59:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 02:59:03 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 56:

> 54:  * , {@linkplain #orElse(Object) orElse()}, or {@linkplain #orElseSet(Supplier) orElseSet()}.
> 55:  * 

> 56:  * A stable value that is set is treated as a constant by the JVM, enabling the

Before promoting the "constant" features, I would prefer more details about the transition to set - that setting is really a racy thing and only one actor succeeds in setting, and specify the memory effect (like the final field freeze) as a hb for the set and all subsequent gets that successfully observed that set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997862275

From duke at openjdk.org  Mon Mar 17 03:03:27 2025
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 17 Mar 2025 03:03:27 GMT
Subject: RFR: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java
Message-ID: 

The current test program for the logging feature added in JDK-8301627 does not fully check some important cases.

Issue Details:
The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.)
The check for the logged stack trace is not enough, as it does not confirm enough details in the output.

Fix Details:
Added more test cases to check behavior under different logging levels.
Improved the stack trace check by verifying more details in the logged output.
These changes make the test more complete and ensure that the logging feature works as expected.
Also, any existing test cases prior to this pull request are retained.

The test was verified in the following OS environments, and it passed successfully in both environments.
- Windows Server 2022 Standard 21H2
- Red Hat Enterprise Linux release 9.2 (Plow)

Could you please review this fix?

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

Commit messages:
 - 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java
 - 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java

Changes: https://git.openjdk.org/jdk/pull/24050/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24050&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352016
  Stats: 108 lines in 8 files changed: 90 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24050/head:pull/24050

PR: https://git.openjdk.org/jdk/pull/24050

From liach at openjdk.org  Mon Mar 17 03:05:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 03:05:01 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 358:

> 356:  *           other hand are guaranteed not to synchronize on {@code this}.
> 357:  *
> 358:  * @implNote A {@linkplain StableValue} is mainly intended to be a non-public field in

This should have been a piece of API Notes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1997865152

From ecki at zusammenkunft.net  Mon Mar 17 04:19:57 2025
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 17 Mar 2025 05:19:57 +0100
Subject: RFR: 8343110: Add getChars(int, int, char[], int) to
 CharSequence and CharBuffer
In-Reply-To: 
References: 
 ,
 
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From dholmes at openjdk.org  Mon Mar 17 06:43:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 06:43:58 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: 
 
 
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: 

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes  wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?

Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.

> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.

I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2728361931

From djelinski at openjdk.org  Mon Mar 17 07:27:02 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 17 Mar 2025 07:27:02 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: 
References: 
Message-ID: <6t_-npUpIttqDOGTqd-xrvkwQ-Miygw6MKqt-t-qAWg=.7672b684-e053-4c93-9e66-0f38be74d5de@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs  wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2689360580

From stefank at openjdk.org  Mon Mar 17 07:57:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 17 Mar 2025 07:57:55 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
Message-ID: 

On Sun, 16 Mar 2025 02:54:36 GMT, Ioi Lam  wrote:

> This is probably not the right thing to do.

I agree that this doesn't sound like the right thing to do. This breaks the jtreg -othervm mode.

I use the -othervm mode whenever I want to run reproduce a failure in jtreg. In -othervm mode the pwd is the same as the final destination of the log files, hs_err files, jars, etc. So, when the logs says "hs_err files is written to xyz" it actually is left in that directory. In -agentvm mode the JVM says that the hs_err files is in scratch/<0>, but you won't find a hs_err file there, because jtreg moved it. Even more annoying is that in -agentvm mode it moves the whitebox.jar file, so the printed "rerun" line is not usable. If you run in -othervm mode you can copy and past the rerun line and it actually works, even when you are using the whitebox APIs.

Is there a way to get this patch to also work in -othervm mode?

When I run the test above with -othervm -retain -concurrency:1 I get the log files here:

jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/runtime/cds/appcds/aotClassLinking/BulkLoaderTest_aot


but the vm.properties file is located here:

jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/vm.properties


So, I'm not sure what's the easiest way to fix that. Maybe walk the chain of parent directories until you find the vm.properties file?

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2728492700

From clanger at openjdk.org  Mon Mar 17 08:23:01 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Mar 2025 08:23:01 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 14:10:30 GMT, Severin Gehwolf  wrote:

>> Alternative approach to #24012
>> 
>> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
>> 
>> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.
>
> make/Bundles.gmk line 248:
> 
>> 246:           %.stripped.pdb, \
>> 247:           $(call FindFiles, $(SYMBOLS_IMAGE_DIR)) \
>> 248:       )
> 
> Why filter *.stripped.pdb? Because they are useless for debugging? Then it should be mentioned as a comment.

This is fixing a small issue that is independent of JEP 493. Currently the JDK/JRE bundles contain the lib.stripped.pdb files renamed to lib.pdb. The symbols bundle contains these as well but it should have the full lib.pdb files. So, by filtering out *stripped.pdb during the creation of the symbols bundle, we make sure that the full pdb files end up in the symbols bundle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24057#discussion_r1998173085

From clanger at openjdk.org  Mon Mar 17 08:29:57 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 17 Mar 2025 08:29:57 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer  wrote:

> Alternative approach to #24012
> 
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional.
> 
> I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions.

After running this patch through our testing I can confirm that it at least solves all existing test issues and does not create regressions.

I, however, admit that the added code in JRTArchive.java is quite hacky and is actually only there to solve some testing issues, not great. Can we maybe add a possibility to store two alternative SHA sums in the JMod archives, per file? Then we could add SHA sums for both, the stripped and the full pdb file and either one which is present in the current runtime would be accepted. So we'd cover the cases where the stripped pdb files are around as well as a potential case when somebody extracted the symbols archive over the runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/24057#issuecomment-2728566685

From iklam at openjdk.org  Mon Mar 17 08:48:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Mar 2025 08:48:56 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: 
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
 
Message-ID: 

On Mon, 17 Mar 2025 07:55:00 GMT, Stefan Karlsson  wrote:

> > This is probably not the right thing to do.
> 
> I agree that this doesn't sound like the right thing to do. This breaks the jtreg -othervm mode.
> 
> I use the -othervm mode whenever I want to run reproduce a failure in jtreg. In -othervm mode the pwd is the same as the final destination of the log files, hs_err files, jars, etc. So, when the logs says "hs_err files is written to xyz" it actually is left in that directory. In -agentvm mode the JVM says that the hs_err files is in scratch/<0>, but you won't find a hs_err file there, because jtreg moved it. Even more annoying is that in -agentvm mode it moves the whitebox.jar file, so the printed "rerun" line is not usable. If you run in -othervm mode you can copy and past the rerun line and it actually works, even when you are using the whitebox APIs.
> 
> Is there a way to get this patch to also work in -othervm mode?
> 
> When I run the test above with -othervm -retain -concurrency:1 I get the log files here:
> 
> ```
> jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/runtime/cds/appcds/aotClassLinking/BulkLoaderTest_aot
> ```
> 
> but the vm.properties file is located here:
> 
> ```
> jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/vm.properties
> ```
> 
> So, I'm not sure what's the easiest way to fix that. Maybe walk the chain of parent directories until you find the vm.properties file?

Actually my PR may not cover all VM properties. VMProps is just for computing the "extra" properties:


requires.extraPropDefns = ../jtreg-ext/requires/VMProps.java


But jtreg also computes "built-in" properties like `jdk.version.major`, `os.simpleArch`, etc:

https://openjdk.org/jtreg/tag-spec.html#requires_names

So I think the best solution may be for jtreg to save the properties to a location of its choice, and pass this location to the test cases with a property like `test.vm.properties.file`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2728610838

From alanb at openjdk.org  Mon Mar 17 09:14:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Mar 2025 09:14:03 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <4Ae963vByEmyd_U31MPYWErLbam0FeKgi4Sni-ApClY=.910c3fbc-1f8b-4928-aa25-7b5a2803202b@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie  wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

The discussion on jdk-dev was useful but I don't think adding --with-import-jvms is the right direction. It's too fragile and loose to import from a build created somewhere else.

I can relate to Aleksey's case where it might be useful to have release + debug builds in the same run-time image. Having java launcher support selecting the fastdebug libjvm, and using jlink to include/exclude the debug VM, can become part of a good story.

I'm less sure that builds that want to produce server + minimal or server + zero or other combinations like this are important or compelling in 2025. In the case of minimal then it may be more useful for the build to just produce the packaged modules (JMOD) rather than an image.  When targeting small/embedded environments then this is what you need as a JDK build with all modules + minimal VM doesn't really make too much sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2728700020

From shade at openjdk.org  Mon Mar 17 09:32:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Mar 2025 09:32:00 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <8c-cbH6l8A21Bn4jRomHaznZkgK6GxHpgPOO359uGa4=.9ca586ec-bf21-4e84-ae96-ab8ae3c4113b@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie  wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

For completeness/reference, this is my JDK frankensteining script that is used for producing builds.shipilev.net bundles: [bundle-multi-jdk.sh.txt](https://github.com/user-attachments/files/19283184/bundle-multi-jdk.sh.txt). That would be one of the workflows that new build support feature would need to help.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2728766491

From jkern at openjdk.org  Mon Mar 17 10:04:56 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 10:04:56 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 17:35:02 GMT, Erik Joelsson  wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> make/StaticLibs.gmk line 116:
> 
>> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
>> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \
> 
> The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:
> 
> Suggestion:
> 
> #    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \
> 
> 
> You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.

Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998375442

From tschatzl at openjdk.org  Mon Mar 17 10:32:33 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Mar 2025 10:32:33 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v23]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * obsolete G1UpdateBufferSize
  
  G1UpdateBufferSize has previously been used to size the refinement
  buffers and impose a minimum limit on the number of cards per thread
  that need to be pending before refinement starts.
  
  The former function is now obsolete with the removal of the dirty
  card queues, the latter functionality has been taken over by the new
  diagnostic option `G1PerThreadPendingCardThreshold`.
  
  I prefer to make this a diagnostic option is better than a product option
  because it is something that is only necessary for some test cases to
  produce some otherwise unwanted behavior (continuous refinement).
  
  CSR is pending.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/447fe39b..4d0afd57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=21-22

  Stats: 16 lines in 7 files changed: 2 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From dchuyko at openjdk.org  Mon Mar 17 10:39:00 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 17 Mar 2025 10:39:00 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: <4dkUUSqlA_M63BBSDO8ZYHeGTyyG9VSPU0D3ZSW1KRA=.88af0f17-2907-4d1b-804d-1a0c60f4be38@github.com>

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

While this has been included into upcoming FJP update for better delayed task handling https://github.com/DougLea/jdk/commit/9b51b7a37711371b40466f6f322608bafe9d65e8 (JDK-8319447), a separate commit will make the fix much easier in update releases.

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2729013325

From duke at openjdk.org  Mon Mar 17 10:47:06 2025
From: duke at openjdk.org (snake66)
Date: Mon, 17 Mar 2025 10:47:06 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: 
References: 
 
 
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 
Message-ID: <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com>

On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes  wrote:

>> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??
>
>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
> 
>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.
> 
> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

> > Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> (...) I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.

I'm happy to test this, if you want. Won't have time this week, though.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2729033496

From jpai at openjdk.org  Mon Mar 17 10:58:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Mar 2025 10:58:02 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: 
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
 
 
Message-ID: 

On Mon, 17 Mar 2025 08:46:06 GMT, Ioi Lam  wrote:

> So I think the best solution may be for jtreg to save the properties to a location of its choice, and pass this location to the test cases with a property like test.vm.properties.file.

>From what I understand of the use case, certain parts of the test code would like to use key/value pairs whose keys are pre-defined in the JDK testsuite and values are computed by testsuite specific class, before jtreg launches the tests. These set of key/value pairs are currently used by jtreg in the evaluation of the `@requires` tag of the test definition. The proposal here is to make available that same key/value pairs to the test code itself (once the test is launched) so that they can do additional decisions based on those properties. 

If I understood that correctly then the proposal in jtreg would be to expose the https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/RegressionContext.java#L38. Since tests are not expected to rely on jtreg classes/types, the way to expose that detail would be by persisting the key/value pairs to a (properties) file whose path is then passed along to the test as a standard jtreg system property like the ones noted in https://openjdk.org/jtreg/tag-spec.html#testvars. I think that's doable. Could you file a request for this in the CODETOOLS project? I would need additional inputs from others in that project whether it's a good thing to expose this but based on my limited knowledge of that project, I think it's OK to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2729061175

From myankelevich at openjdk.org  Mon Mar 17 12:27:58 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 17 Mar 2025 12:27:58 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
In-Reply-To: <1QNFmbAQK8Q_F1sOPLf3XQSUQ8enU4tpNfctudsYu74=.54ca3f1f-3745-456a-b22b-de50aacebf3f@github.com>
References: 
 <1QNFmbAQK8Q_F1sOPLf3XQSUQ8enU4tpNfctudsYu74=.54ca3f1f-3745-456a-b22b-de50aacebf3f@github.com>
Message-ID: 

On Fri, 14 Mar 2025 18:35:12 GMT, Joe Wang  wrote:

> Thanks for review. Updated the test.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/24039#issuecomment-2729299732

From erikj at openjdk.org  Mon Mar 17 13:09:02 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Mar 2025 13:09:02 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken  wrote:

> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24054#pullrequestreview-2690424664

From jkern at openjdk.org  Mon Mar 17 13:13:53 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 13:13:53 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 17 Mar 2025 10:02:12 GMT, Joachim Kern  wrote:

>> make/StaticLibs.gmk line 116:
>> 
>>> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
>>> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>>> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \
>> 
>> The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:
>> 
>> Suggestion:
>> 
>> #    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \
>> 
>> 
>> You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.
>
> Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?

The problem seems to be that `$(generate_export_list)` is empty and I do not know why.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998701815

From erikj at openjdk.org  Mon Mar 17 13:16:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Mar 2025 13:16:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 17 Mar 2025 13:11:14 GMT, Joachim Kern  wrote:

>> Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?
>
> The problem seems to be that `$(generate_export_list)` is empty and I do not know why.

Looks like this variable is misspelled (missing "S").

DEPS := $(STATIC_LIB_FILE), \

Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998708773

From sgehwolf at openjdk.org  Mon Mar 17 13:49:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 17 Mar 2025 13:49:55 GMT
Subject: RFR: 8351842: Windows specific issues in combination of JEP 493
 and --with-external-symbols-in-bundles=public
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 Mar 2025 08:27:20 GMT, Christoph Langer  wrote:

> Can we maybe add a possibility to store two alternative SHA sums in the JMod archives, per file? Then we could add SHA sums for both, the stripped and the full pdb file and either one which is present in the current runtime would be accepted. So we'd cover the cases where the stripped pdb files are around as well as a potential case when somebody extracted the symbols archive over the runtime.

I wonder if there would be a more generic way to solve this. We've seen similar issues with JDK image post-processing interfering with the SHA sum check. The general problem is that for some cases SHA sum checking is too strict (e.g. for signed binaries or stripped binaries - debug symbol processing). Now those use-cases aren't for everyone. So it would be ideal if we could opt-into a more lenient SHA sum checking without needing to change the JMOD archive format.

The prime reason for the SHA sum check was population of modified configuration files to the linked image.

`SaveJLinkArgFilesPlugin` comes to mind. How about we added a way of checking the SHA for a file from a set of values (it could be restricted to binaries and libraries only). Say, this set of SHA sums could be passed to `jlink` itself with an option, say `--sha-mappings=...`. That option could be a list of file/sha pairs or use `file:` with a mapping. Then, we could add an additional configure option to the JDK build which adds such sha mappings to `jlink` with the `--save-jlink-argfiles` option to the resulting `jlink`. For the Windows case configured with `--with-external-symbols-in-bundles=public` case this could be done at build time. The resulting `jlink` would use `--sha-mappings` as needed for `*.pdb` files only, solving this problem.

For RPM builds where we face similar issues of *.so files and executables getting stripped of debug symbols way after the JDK build completes. We could add `--sha-mappings=file:$JAVA_HOME/conf/jlink_extra_mappings.txt` via `--save-jlink-argfiles` and allow for the new SHA sum in that file - again restricting this multi-mapping for binaries/libraries only.

Thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/24057#issuecomment-2729570316

From liach at openjdk.org  Mon Mar 17 14:45:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 14:45:58 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

It seems this is an overflow for the TC part of the flag. The RC part seems to be able to overflow too, but because it occupies the higher bits its overflow will never affect the TC. And this is the only site where TC is masked with `UMASK` after overflow-capable addition. Should we reexamine all uses of `UMASK` to mask only RC/TC explicitly?

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2729780512

From jkern at openjdk.org  Mon Mar 17 15:03:52 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 15:03:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 17 Mar 2025 13:14:44 GMT, Erik Joelsson  wrote:

>> The problem seems to be that `$(generate_export_list)` is empty and I do not know why.
>
> Looks like this variable is misspelled (missing "S").
> 
> DEPS := $(STATIC_LIB_FILE), \
> 
> Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.

Ups, thank you for giving me the 'S'. But nevertheless if I make with
`make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998959519

From dchuyko at openjdk.org  Mon Mar 17 15:17:52 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 17 Mar 2025 15:17:52 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: 
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
 
Message-ID: 

On Mon, 17 Mar 2025 14:43:05 GMT, Chen Liang  wrote:

> It seems this is an overflow for the TC part of the flag. The RC part seems to be able to overflow too, but because it occupies the higher bits its overflow will never affect the TC. And this is the only site where TC is masked with `UMASK` after overflow-capable addition.

Yes, from this point RC (in)accurate masking can be considered cosmetic, but this might be the source of this bug with TC.

> Should we reexamine all uses of `UMASK` to mask only RC/TC explicitly?

'(v.stackPred & SP_MASK) | (UC_MASK & c)' patterns seem ok to me, but for all subfield arithmetic it would be more clear to see all subfields recombined.

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2729913449

From dchuyko at openjdk.org  Mon Mar 17 15:25:55 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 17 Mar 2025 15:25:55 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: <0R_h5ot_Co2bfmLVsncVcn8r92LC-2kGvDgXTK1txLs=.7c63395e-21f3-4b51-a783-d0edba8c3e9c@github.com>

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

So I'd propose to consider RC masking separately, and maybe as a part of larger FJP update (such as JDK-8319447), without a need to backport.

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2729937960

From iklam at openjdk.org  Mon Mar 17 16:38:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Mar 2025 16:38:28 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: 
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
 
 
 
Message-ID: 

On Mon, 17 Mar 2025 10:55:14 GMT, Jaikiran Pai  wrote:

> > So I think the best solution may be for jtreg to save the properties to a location of its choice, and pass this location to the test cases with a property like test.vm.properties.file.
> 
> From what I understand of the use case, certain parts of the test code would like to use key/value pairs whose keys are pre-defined in the JDK testsuite and values are computed by testsuite specific class, before jtreg launches the tests. These set of key/value pairs are currently used by jtreg in the evaluation of the `@requires` tag of the test definition. The proposal here is to make available that same key/value pairs to the test code itself (once the test is launched) so that they can do additional decisions based on those properties.
> 
> If I understood that correctly then the proposal in jtreg would be to expose the https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/RegressionContext.java#L38. Since tests are not expected to rely on jtreg classes/types, the way to expose that detail would be by persisting the key/value pairs to a (properties) file whose path is then passed along to the test as a standard jtreg system property like the ones noted in https://openjdk.org/jtreg/tag-spec.html#testvars. I think that's doable. Could you file a request for this in the CODETOOLS project? I would need additional inputs from others in that project whether it's a good thing to expose this but based on my limited knowledge of that project, I think it's OK to do that.

Thanks @jaikiran . I filed [CODETOOLS-7903975](https://bugs.openjdk.org/browse/CODETOOLS-7903975)

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2730167839

From kbarrett at openjdk.org  Mon Mar 17 17:22:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 17 Mar 2025 17:22:10 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  bchristi-git review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23952/files
  - new: https://git.openjdk.org/jdk/pull/23952/files/68c2579c..1c15bce8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23952&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23952&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23952/head:pull/23952

PR: https://git.openjdk.org/jdk/pull/23952

From rriggs at openjdk.org  Mon Mar 17 18:05:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Mar 2025 18:05:09 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 Mar 2025 17:22:10 GMT, Kim Barrett  wrote:

>> Please review this revision of a previously puzzling comment intending to
>> provide the rationale for a bit of non-obvious code.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bchristi-git review

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23952#pullrequestreview-2691564090

From asemenyuk at openjdk.org  Mon Mar 17 18:41:14 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 17 Mar 2025 18:41:14 GMT
Subject: Integrated: 8351372: Improve negative tests coverage of jpackage
In-Reply-To: 
References: 
Message-ID: <2_xqhhWE3UW-cKZhHWZ31uENIFzvUq4jbNrwX_ivbNE=.43774bcd-3e14-4235-803a-89cbd8633d3d@github.com>

On Thu, 6 Mar 2025 23:30:09 GMT, Alexey Semenyuk  wrote:

> Changes to tests:
>  - Added more test cases to ErrorTest.
>  - Added functionality to jpackage test lib to facilitate new ErrorTest test cases.
>  - Make all other negative tests use the `CannedFormattedString` class to validate error messages in jpackage output strictly.
>  - Removed redundant negative tests/test cases duplicating ErrorTest.
>  - Give unique descriptions to macos signing tests.
>  
> Changes to jpackage:
>  - Main.java: Catch `java.nio.file.NoSuchFileException` as `jdk.internal.opt.CommandLine.parse()` throws this exception instead of  `java.io.FileNotFoundException` to indicate missing command file. The issue was uncovered with the new ErrorTest test case for `ERR_CannotParseOptions` error ID.
>  - DeployParams.java: replace `ERR_MissingArgument` with `error.no-input-parameter` as the error is not missing argument of `--input` parameter, but missing `--input` parameter itself. The issue was uncovered with the new ErrorTest test cases for `ERR_MissingArgument` and ``error.no-input-parameter` error IDs.
>  - LauncherData.java: remove dead code as missing `--input` parameter is handled earlier in DeployParams.
>  - DottedVersion.java: fix exception messages based on the new test cases in ErrorTest.
>  - TokenRepalce.java/TokenRepalceTest.java: picked from https://github.com/openjdk/jdk/pull/23923 PR. It is needed for ErrorTest as well.

This pull request has now been integrated.

Changeset: 3aa6d62a
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/3aa6d62afecbea5684618bc82425e59404233be5
Stats:     2112 lines in 37 files changed: 1377 ins; 459 del; 276 mod

8351372: Improve negative tests coverage of jpackage

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/23936

From roger.riggs at oracle.com  Mon Mar 17 18:42:18 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 17 Mar 2025 14:42:18 -0400
Subject: Missing offset+length Arrays.hashCode() methods?
In-Reply-To: 
References: 
Message-ID: 

Hi,

It seems like a reasonable API enhancement, the implementation already 
supports sub-ranges.

Created JDK-8352171  
Arrays.hashCode for sub-range of byte array API addition

Regards, Roger

On 1/31/25 6:45 AM, Matthew Swift wrote:
> Hello experts,
>
> Firstly, please let me know where to post this question if it is an 
> inappropriate question for this mailing list.
>
> The java.util.Arrays utility class currently exposes pairs of methods 
> for comparing arrays of primitives and objects, for example:
>
> ? ? java.util.Arrays#equals(byte[], byte[])
> ? ? java.util.Arrays#equals(byte[], int, int, byte[], int, int)
>
> However, only a single method is provided for the equivalent 
> hashCode() methods:
>
> ? ??java.util.Arrays#hashCode(byte[])
>
> Specifically, the offset+length versions are not present, despite 
> there being support in?jdk.internal.util.ArraysSupport. Given the 
> ubiquity of equals?+ hashCode, I would expect there to be symmetry 
> between the equals and hashCode APIs in Arrays. The lack of support 
> means that applications cannot take advantage of intrinsics.
>
> The use-case we have is parsing byte[] network protocol packets into 
> their components, which are represented using objects containing 
> offset+length pointers into the original packet. These components are 
> frequently?stored in hash sets and maps. More precisely, we are 
> parsing ASN.1 BER packets, so our use-case is remarkably similar to 
> JDK's?sun.security.util.DerValue#hashCode, but could be applied 
> equally to other network protocols.
>
> I know that the String class stopped using the offset+length 
> low-allocation design some time ago, so perhaps the design I'm 
> describing above is no longer best-practice thanks to JVM 
> advancements, and hence there should be no need for offset+length 
> Arrays#hashCode - but that doesn't explain the asymmetry with 
> Arrays#equals.
>
> Thanks in advance,
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Mon Mar 17 18:58:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Mar 2025 18:58:12 GMT
Subject: Integrated: 8351970: Retire JavaLangAccess::exit
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs  wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

This pull request has now been integrated.

Changeset: 19154f7a
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/19154f7af34bf6f13d61d7a9f05d6277964845d8
Stats:     13 lines in 3 files changed: 0 ins; 12 del; 1 mod

8351970: Retire JavaLangAccess::exit

Reviewed-by: rgiulietti, liach, djelinski

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

PR: https://git.openjdk.org/jdk/pull/24066

From forax at univ-mlv.fr  Mon Mar 17 18:59:25 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 17 Mar 2025 19:59:25 +0100 (CET)
Subject: Missing offset+length Arrays.hashCode() methods?
In-Reply-To: 
References: 
 
Message-ID: <1511572629.171324931.1742237965926.JavaMail.zimbra@univ-eiffel.fr>

Just a comment "en passant", 
array, List or String in Java tend to use the from/to index convention instead of the offset+length convention which is the convention for system calls (read/write etc). 

regards, 
R?mi 

> From: "Roger Riggs" 
> To: "core-libs-dev" 
> Sent: Monday, March 17, 2025 7:42:18 PM
> Subject: Re: Missing offset+length Arrays.hashCode() methods?

> Hi,

> It seems like a reasonable API enhancement, the implementation already supports
> sub-ranges.

> Created [ https://bugs.openjdk.org/browse/JDK-8352171 | JDK-8352171 ]
> Arrays.hashCode for sub-range of byte array API addition

> Regards, Roger

> On 1/31/25 6:45 AM, Matthew Swift wrote:

>> Hello experts,

>> Firstly, please let me know where to post this question if it is an
>> inappropriate question for this mailing list.

>> The java.util.Arrays utility class currently exposes pairs of methods for
>> comparing arrays of primitives and objects, for example:

>> java.util.Arrays#equals(byte[], byte[])
>> java.util.Arrays#equals(byte[], int, int, byte[], int, int)

>> However, only a single method is provided for the equivalent hashCode() methods:

>> java.util.Arrays#hashCode(byte[])

>> Specifically, the offset+length versions are not present, despite there being
>> support in jdk.internal.util.ArraysSupport. Given the ubiquity of equals +
>> hashCode, I would expect there to be symmetry between the equals and hashCode
>> APIs in Arrays. The lack of support means that applications cannot take
>> advantage of intrinsics.

>> The use-case we have is parsing byte[] network protocol packets into their
>> components, which are represented using objects containing offset+length
>> pointers into the original packet. These components are frequently stored in
>> hash sets and maps. More precisely, we are parsing ASN.1 BER packets, so our
>> use-case is remarkably similar to JDK's sun.security.util.DerValue#hashCode,
>> but could be applied equally to other network protocols.

>> I know that the String class stopped using the offset+length low-allocation
>> design some time ago, so perhaps the design I'm describing above is no longer
>> best-practice thanks to JVM advancements, and hence there should be no need for
>> offset+length Arrays#hashCode - but that doesn't explain the asymmetry with
>> Arrays#equals.

>> Thanks in advance,
>> Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Mon Mar 17 19:29:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 19:29:07 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

The issue looks valid to me and the fix looks good. Would be nice if another reviewer can double check.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24034#pullrequestreview-2691756966

From liach at openjdk.org  Mon Mar 17 20:24:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 20:24:13 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

Note that some reviewers may be busy with the ongoing JavaOne. Please wait for another reviewer in area to double check.

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2730744798

From alanb at openjdk.org  Tue Mar 18 06:53:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Mar 2025 06:53:07 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

As noted, this is fixed by the FJP changes in JDK-8319447. If the change is going in separately then best to take the exact change to tryTrim to avoid merge issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2731868210

From qamai at openjdk.org  Tue Mar 18 09:02:16 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 18 Mar 2025 09:02:16 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v7]
In-Reply-To: <_IZBYKPqsgElXJ5jJANnee0ujmsnbDY5_En0LN15TW4=.dd7659bd-264b-42d9-b0f8-f88cd2ec2738@github.com>
References: 
 <0_1SZd0VVSYj61Zc71DqxZMrfRWIgfrmCPou_AS2DYc=.9156ec5f-fac3-4ff3-9261-f576414372fc@github.com>
 <_IZBYKPqsgElXJ5jJANnee0ujmsnbDY5_En0LN15TW4=.dd7659bd-264b-42d9-b0f8-f88cd2ec2738@github.com>
Message-ID: 

On Thu, 13 Mar 2025 16:21:07 GMT, Maurizio Cimadamore  wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   expand wildcard imports
>
> Marked as reviewed by mcimadamore (Reviewer).

@mcimadamore @JornVernee Thanks a lot for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22610#issuecomment-2732182331

From qamai at openjdk.org  Tue Mar 18 09:02:16 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 18 Mar 2025 09:02:16 GMT
Subject: Integrated: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Dec 2024 16:30:47 GMT, Quan Anh Mai  wrote:

> Hi,
> 
> This patch improves the performance of a typical `Arena::allocate` in several ways:
> 
> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
> - Split the allocation of over-aligned memory to a slow-path method.
> - Align the memory to 8 bytes, allowing faster zeroing.
> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: e1bcff3a
Author:    Quan Anh Mai 
URL:       https://git.openjdk.org/jdk/commit/e1bcff3ada9214940e9c71ba4ed5ba93d0218af2
Stats:     72 lines in 4 files changed: 27 ins; 17 del; 28 mod

8345687: Improve the implementation of SegmentFactories::allocateSegment

Reviewed-by: jvernee, mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/22610

From dchuyko at openjdk.org  Tue Mar 18 09:11:01 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Tue, 18 Mar 2025 09:11:01 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

Agree, reformatted the code. That doesn't affect any backports (already prepared).

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2732216305

From dchuyko at openjdk.org  Tue Mar 18 09:11:00 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Tue, 18 Mar 2025 09:11:00 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool [v2]
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:

  Aligned with JDK-8319447

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24034/files
  - new: https://git.openjdk.org/jdk/pull/24034/files/e5517c7d..973c84cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24034&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24034&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24034.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24034/head:pull/24034

PR: https://git.openjdk.org/jdk/pull/24034

From jkern at openjdk.org  Tue Mar 18 10:47:07 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 10:47:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Mon, 17 Mar 2025 15:01:10 GMT, Joachim Kern  wrote:

>> Looks like this variable is misspelled (missing "S").
>> 
>> DEPS := $(STATIC_LIB_FILE), \
>> 
>> Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.
>
> Ups, thank you for giving me the 'S'. But nevertheless if I make with
> `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list

I did not get the SetupExecute function, even if I strip it down to a simple example

$(eval $(call SetupExecute, generate_export_list, \
    INFO := Generating export list for static libs, \
    DEPS := /path/libjli.a, \
    OUTPUT_FILE := /path/libjli.a.exp, \
    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \
))

$(java): $(STATIC_LIB_FILES) /path/libjli.a.exp

I still get
`gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'.  Stop.
`
Why does make not recognize, that the rule is in my
 `call SetupExecute, generate_export_list,`
macro?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000736109

From jwaters at openjdk.org  Tue Mar 18 11:35:17 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 18 Mar 2025 11:35:17 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters  wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
> 
> build.log on release configuration:
> 
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=]
>  3560 |                     static const UINT _VKS_ALT_MASK = 0x04;
>       |                                       ^~~~~~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs]
>  1361 | } SUBTABLE, *PSUBTABLE;
>       |              ^~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs]
>  1588 | } HEAD, *PHEAD;
>       |          ^~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs]
>  1595 | } ENTRY, *PENTRY;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/...

Keep open please

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

PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2732871765

From ihse at openjdk.org  Tue Mar 18 11:41:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 11:41:13 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken  wrote:

> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24054#pullrequestreview-2694167632

From ihse at openjdk.org  Tue Mar 18 12:12:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:12:13 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern  wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

make/StaticLibs.gmk line 112:

> 110: $(STATIC_LIB_EXPORT_FILES): $(STATIC_LIB_FILES)
> 111: 	$(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@
> 112: #$(eval $(call SetupExecute, generate_export_list, \

I think there are multiple issues at hand here.

1) There is a current bug in SetupExecute that requires you to execute any command with redirection in a subshell, that is, you need to wrap the COMMAND in `(` ... `)`.

2) STATIC_LIB_EXPORT_FILES is not a single file, it is a list of file. So what you have written above is not a single recipe, it is a multi-file recipe template. But it's weird, it will evaluate to like:
libjvm.so.exp libjava.so.exp libjli.so.exp: libjvm.so libjava.so libjli.so
which makes no sense, since you do not need to have a dependency to  libjava.so libjli.so for libjvm.so.exp.

What you really want is to have a single rule per library that creates the corresponding exp file for that library, and which is dependent only on that library.

Or, possibly, you can just concatenate the export of all libraries into a single file. It will make the final linker command line simpler, since you would only need a single `-Wl,-bE:`, but it is potentially worse for an incremental rebuild, since all native libraries need to be re-scanned for exported functions.

My preferred solution would to make this explicit by creating a loop over STATIC_LIB_FILES, and doing a SetupExecute for each such lib. Then you can get it down to something like:

$(foreach lib, $(STATIC_LIB_FILES), \
  $(eval $(call SetupExecute, generate_export_list_$(lib),
      INFO := Generating export list for $(lib), \
      DEPS :=  $(lib), \
      OUTPUT_FILE := $(lib).exp, \
      COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | sort -u > $(lib).exp ), \
  ) \
  $(eval STATIC_LIB_EXPORT_FILES += $(lib).exp) \
)

make/StaticLibs.gmk line 136:

> 134: ))
> 135: 
> 136: $(java): $(STATIC_LIB_FILES) $(if $(call isTargetOs, aix), $(STATIC_LIB_EXPORT_FILES))

This is just clunky. Leave the original line, and add:

ifeq ($(call isTargetOs, aix), true)
  $(java): $(STATIC_LIB_EXPORT_FILES)
endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000901430
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000904229

From ihse at openjdk.org  Tue Mar 18 12:15:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:15:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Tue, 18 Mar 2025 10:44:46 GMT, Joachim Kern  wrote:

>> Ups, thank you for giving me the 'S'. But nevertheless if I make with
>> `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list
>
> I did not get the SetupExecute to function, even if I strip it down to a simple example
> 
> $(eval $(call SetupExecute, generate_export_list, \
>     INFO := Generating export list for static libs, \
>     DEPS := /path/libjli.a, \
>     OUTPUT_FILE := /path/libjli.a.exp, \
>     COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \
> ))
> 
> $(java): $(STATIC_LIB_FILES) /path/libjli.a.exp
> 
> I still get
> `gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'.  Stop.
> `
> Why does make not recognize, that the rule is in my
>  `call SetupExecute, generate_export_list,`
> macro?

This is likely due to the missing subshell. There is an enhancement filed to fix this automatically but it has unfortunately not been prioritized: https://bugs.openjdk.org/browse/JDK-8233115

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000909674

From ihse at openjdk.org  Tue Mar 18 12:30:11 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:30:11 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <4Ae963vByEmyd_U31MPYWErLbam0FeKgi4Sni-ApClY=.910c3fbc-1f8b-4928-aa25-7b5a2803202b@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <4Ae963vByEmyd_U31MPYWErLbam0FeKgi4Sni-ApClY=.910c3fbc-1f8b-4928-aa25-7b5a2803202b@github.com>
Message-ID: 

On Mon, 17 Mar 2025 09:10:50 GMT, Alan Bateman  wrote:

> The discussion on jdk-dev was useful but I don't think adding --with-import-jvms is the right direction. It's too fragile and loose to import from a build created somewhere else.

Why's that? It's more loose than just "importing" a jtreg jar from "somewhere else". Nor is it any more fragile than any other part of the build system. In fact, I think you seriously underestimate how fragile the *current* solution is, where we have to manage multiple hotspot builds. I've lost count on how many times we've had to solve bugs related to this. That is a very weird quirk in the build system, that has ramifications all over, and making all changes related to hotspot being much harder and riskier.

Also, to quote what I just wrote in a JBS issue:

This is all not really about removing any functionality. It is just about shifting the cost of doing this odd combinations to the distributors who still want to support them, instead of letting the entire JDK build ecosystem pay the price.

Any distributor who wants to build a JDK with both minimal and server will still be able to do that. But since that is a niche case, it stands to reason that they must add just a tiny bit of complexity to their build scripts to achieve this. 

But as a result of removing this complexity from the build system in the JDK, it will allow us to unlock a lot of well-needed functionality, such as decoupling the gtest build from the hotspot build. This in turn will lead to faster builds, and the ability to use gtest for testing of native libs (outside Hotspot) in the JDK. I can't see how it is by any mean worth paying the price of missing out on this functionality, just to keep distributors from having to modify their build scripts, for a combination that I think everyone agrees are at least on its way out.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733044671

From ihse at openjdk.org  Tue Mar 18 12:36:06 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:36:06 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie  wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

And to be absolutely clear: this PR is just about adding new functionality that was not present before.

A follow-up PR for JDK-8352045 will actually remove functionality from the build system. But, and once again, let me be absolutely clear, the intention is that even after that PR, any distributor who wants to build an image with multiple JVMs will still be able to do so. The generated bits will be identical before and after JDK-8352045; the only difference is that you are going to need a "pre-build" step for each additional JVM you want to add, where the pre-build step basically consists of calling `bash configure --with-jvm-variant= && make hotspot`. If you add this simple step, you are going to get the exact same bits in the image.

In theory, I could even program a make target to call `configure --with-jvm-variant= --with-conf-name=support-for- && make hotspot CONF=support-for-` but that's kind of silly, and looks like babysitting and insulting the intelligence of distributors...

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733054041
PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733057930

From myankelevich at openjdk.org  Tue Mar 18 12:48:07 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Mar 2025 12:48:07 GMT
Subject: RFR: 8352016: Improve
 java/lang/RuntimeTests/RuntimeExitLogTest.java
In-Reply-To: 
References: 
Message-ID: <9GhLe8FJWgpKSIdlkzHRKYVR2Ge9uOYqehdY5p3_1o4=.e5dee567-648b-472f-80ed-f858b8d8269b@github.com>

On Fri, 14 Mar 2025 09:17:06 GMT, KIRIYAMA Takuya  wrote:

> The current test program for the logging feature added in JDK-8301627 does not fully check some important cases.
> 
> Issue Details:
> The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.)
> The check for the logged stack trace is not enough, as it does not confirm enough details in the output.
> 
> Fix Details:
> Added more test cases to check behavior under different logging levels.
> Improved the stack trace check by verifying more details in the logged output.
> These changes make the test more complete and ensure that the logging feature works as expected.
> Also, any existing test cases prior to this pull request are retained.
> 
> The test was verified in the following OS environments, and it passed successfully in both environments.
> - Windows Server 2022 Standard 21H2
> - Red Hat Enterprise Linux release 9.2 (Plow)
> 
> Could you please review this fix?

Looks good, just a minor comment. Thank you!

test/jdk/java/lang/RuntimeTests/RuntimeExitLogTest.java line 52:

> 50:     private static final String TEST_JDK = System.getProperty("test.jdk");
> 51:     private static final String TEST_SRC = System.getProperty("test.src");
> 52:     private static final String NL = System.getProperty("line.separator");

Wouldn't it be easier to just use `System.lineSeparator();` here, what do you think? 

Also I'd personally rename it to `NEW_LINE` or `SEPARATOR`, as it took me a few read throughs to understand what does NL stand for, but thats minor.

test/jdk/java/lang/RuntimeTests/RuntimeExitLogTest.java line 53:

> 51:     private static final String TEST_SRC = System.getProperty("test.src");
> 52:     private static final String NL = System.getProperty("line.separator");
> 53:     private static Object HOLD_LOGGER;

Nitpick: This is not used, could you please remove if there will be another revision.

test/jdk/java/lang/RuntimeTests/RuntimeExitLogTest.java line 167:

> 165:                 List lines = reader.lines().toList();
> 166:                 boolean match = (expectMessage.isEmpty())
> 167:                         ? lines.size() == 0

Nitpick: `? lines.isEmpty()` would be easier to read imo, but it's fine as it is.

test/jdk/java/lang/RuntimeTests/RuntimeExitLogTest.java line 174:

> 172:                     System.err.println(expectMessage.replaceAll("\\n", NL));
> 173:                     System.err.println("---- Actual output begin");
> 174:                     lines.forEach(l -> System.err.println(l));

Nitpick: `lines.forEach(System.err::println);` would be easier to read in my opinion, but it's fine as it is.

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

PR Review: https://git.openjdk.org/jdk/pull/24050#pullrequestreview-2694348466
PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2000948118
PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2000943776
PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2000950379
PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2000949810

From mbaesken at openjdk.org  Tue Mar 18 13:02:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Mar 2025 13:02:13 GMT
Subject: RFR: 8352015: LIBVERIFY_OPTIMIZATION remove special optimization
 settings
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken  wrote:

> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2733131425

From mbaesken at openjdk.org  Tue Mar 18 13:02:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Mar 2025 13:02:14 GMT
Subject: Integrated: 8352015: LIBVERIFY_OPTIMIZATION remove special
 optimization settings
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken  wrote:

> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to HIGH.

This pull request has now been integrated.

Changeset: a37d8434
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/a37d8434ab991507bf8085ecf7816d0cd41ab584
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8352015: LIBVERIFY_OPTIMIZATION remove special optimization settings

Reviewed-by: erikj, ihse

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

PR: https://git.openjdk.org/jdk/pull/24054

From erikj at openjdk.org  Tue Mar 18 13:07:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Mar 2025 13:07:09 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: 

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie  wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

make/modules/java.base/Copy.gmk line 128:

> 126:   $(foreach import_jvm, $(IMPORT_JVM_NAMES), \
> 127:     $(eval $(import_jvm)_path := $(patsubst $(import_jvm):%,%,$(filter $(import_jvm):%, $(IMPORT_JVMS)))) \
> 128:     $(eval $(call MakeDir, $(LIB_DST_DIR)/$(import_jvm))) \

Do you really need to call MakeDir outside of a recipe? Won't SetupCopyFiles recipes create this directory?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24063#discussion_r2000996873

From erikj at openjdk.org  Tue Mar 18 13:12:08 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Mar 2025 13:12:08 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie  wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

If we want to support CDS archives for the imported JVMs, then we would need to modify the loop in Images.gmk so that it covers them as well. I think that makes sense to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733160930

From ihse at openjdk.org  Tue Mar 18 13:15:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 13:15:18 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com>
Message-ID: 

On Tue, 18 Mar 2025 13:09:10 GMT, Erik Joelsson  wrote:

> If we want to support CDS archives for the imported JVMs, then we would need to modify the loop in Images.gmk so that it covers them as well. I think that makes sense to do.

Yes, I agree. That, and importing the whole directory, is the two changes I have on my mental todo list for this PR.

> make/modules/java.base/Copy.gmk line 128:
> 
>> 126:   $(foreach import_jvm, $(IMPORT_JVM_NAMES), \
>> 127:     $(eval $(import_jvm)_path := $(patsubst $(import_jvm):%,%,$(filter $(import_jvm):%, $(IMPORT_JVMS)))) \
>> 128:     $(eval $(call MakeDir, $(LIB_DST_DIR)/$(import_jvm))) \
> 
> Do you really need to call MakeDir outside of a recipe? Won't SetupCopyFiles recipes create this directory?

I assumed it would, but it failed, and I looked at the code and found no clear evidence that it does, so I added this. It might have been some other issue, so I can double-check again, if you are certain that SetupCopyFiles should create needed directories.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2733171467
PR Review Comment: https://git.openjdk.org/jdk/pull/24063#discussion_r2001014378

From duke at openjdk.org  Tue Mar 18 14:50:15 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 18 Mar 2025 14:50:15 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v31]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 4 Dec 2024 14:56:02 GMT, fabioromano1  wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An optimization

This comment is to avoid closing this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2733520815

From erikj at openjdk.org  Tue Mar 18 15:37:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Mar 2025 15:37:09 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: 
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <2lDDKpoAYVPFPm24kwg2gjpmgAGnPz-_lh3r2UCpb2c=.776de8cb-9fb1-4549-b335-399cdb6450f3@github.com>
 
Message-ID: 

On Tue, 18 Mar 2025 13:12:16 GMT, Magnus Ihse Bursie  wrote:

>> make/modules/java.base/Copy.gmk line 128:
>> 
>>> 126:   $(foreach import_jvm, $(IMPORT_JVM_NAMES), \
>>> 127:     $(eval $(import_jvm)_path := $(patsubst $(import_jvm):%,%,$(filter $(import_jvm):%, $(IMPORT_JVMS)))) \
>>> 128:     $(eval $(call MakeDir, $(LIB_DST_DIR)/$(import_jvm))) \
>> 
>> Do you really need to call MakeDir outside of a recipe? Won't SetupCopyFiles recipes create this directory?
>
> I assumed it would, but it failed, and I looked at the code and found no clear evidence that it does, so I added this. It might have been some other issue, so I can double-check again, if you are certain that SetupCopyFiles should create needed directories.

SetupCopyFiles uses `install-file` by default and that macro calls `MakeTargetDir`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24063#discussion_r2001341907

From asemenyuk at openjdk.org  Tue Mar 18 15:52:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Mar 2025 15:52:18 GMT
Subject: RFR: 8352275: Clean up dead code in jpackage revealed with improved
 negative test coverage
Message-ID: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>

Follow up code cleanup for https://github.com/openjdk/jdk/pull/23936 PR.

Details on cleanup actions are given in commit descriptions.

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

Commit messages:
 - Update copyright year
 - "message.version-string-too-many-components" ID is not used
 - Remove dead code. ERR_NoJreInstallerName is never used because in case of runtime packaging the name always available - it is picked from the name of runtime image directory (the value of `--runtime-image` option) if `--name` is missing.
 - Remove dead code. `ERR_InputNotDirectory` and `ERR_CannotReadInputDir` are not referenced
 - Remove dead code. `ERR_MissingAppResources` is not referenced
 - Remove dead code. Exception with `error.no.name` can not be thrown from WinMsiBundler.prepareProto() because app name is validated earlier.
 - Remove unreferenced `message.app-image-dir-does-not-exist` and `message.app-image-dir-does-not-exist.advice` keys
 - Remove dead code. Exceptions with `message.app-image-dir-does-not-exist` id never thrown, because DeployParams.validate() would throw `ERR_AppImageNotExist` early
 - Remove dead code. `message.app-image-requires-app-name` can not be reported because if name is not explicitly specified, jpackage will use name from the external app image. In other words, there is no need to set app name if `--app-image` is specified.
 - Remove dead code. Exception with `message.app-image-requires-identifier` id will never be thrown from MacPkgBundler because bundle identifier will fallback to app name in the worst case scenario. app name is validated before MacPkgBundler.validate() is called.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/19154f7a...c17e612c

Changes: https://git.openjdk.org/jdk/pull/24099/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24099&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352275
  Stats: 76 lines in 9 files changed: 2 ins; 67 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24099.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24099/head:pull/24099

PR: https://git.openjdk.org/jdk/pull/24099

From jkern at openjdk.org  Tue Mar 18 16:18:52 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 16:18:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v2]
In-Reply-To: 
References: 
Message-ID: 

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  following Magnus proposals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/48668be6..6e76f114

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=00-01

  Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

PR: https://git.openjdk.org/jdk/pull/24062

From jkern at openjdk.org  Tue Mar 18 16:21:14 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 16:21:14 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: 
References: 
Message-ID: 

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern  wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

I applied all of magnus proposals, but I still get
`gmake[3]: *** No rule to make target '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/native/java.base/libverify/static/libverify.a.exp', needed by '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/static-native/launcher/java'.  Stop.`

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2733873645

From tschatzl at openjdk.org  Tue Mar 18 16:24:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 18 Mar 2025 16:24:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v24]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - * factor out card table and refinement table merging into a single
     method
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
 - * obsolete G1UpdateBufferSize
   
   G1UpdateBufferSize has previously been used to size the refinement
   buffers and impose a minimum limit on the number of cards per thread
   that need to be pending before refinement starts.
   
   The former function is now obsolete with the removal of the dirty
   card queues, the latter functionality has been taken over by the new
   diagnostic option `G1PerThreadPendingCardThreshold`.
   
   I prefer to make this a diagnostic option is better than a product option
   because it is something that is only necessary for some test cases to
   produce some otherwise unwanted behavior (continuous refinement).
   
   CSR is pending.
 - * more documentation on why we need to rendezvous the gc threads
 - Merge branch 'master' into 8342381-card-table-instead-of-dcq
 - * ayang review
     * re-add STS leaver for java thread handshake
 - * when aborting refinement during full collection, the global card table and the per-thread card table might not be in sync. Roll forward during abort of the refinement in these situations.
   * additional verification
   * added some missing ResourceMarks in asserts
   * added variant of ArrayJuggle2 that crashes fairly quickly without these changes
 - * ayang review
     * remove unnecessary STSleaver
     * some more documentation around to_collection_card card color
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * optimized RISCV gen_write_ref_array_post_barrier() implementation contributed by @RealFYang
 - ... and 22 more: https://git.openjdk.org/jdk/compare/b025d8c2...c833bc83

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=23
  Stats: 6788 lines in 104 files changed: 2382 ins; 3476 del; 930 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From lancea at openjdk.org  Tue Mar 18 18:09:23 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Mar 2025 18:09:23 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <4vwMVyfhkH0veu5XwKEGp7rP6PmBSTBsqTyGaVVaS4o=.0c05d8d1-d6f0-435f-b83c-d7d12839bab0@github.com>

On Fri, 14 Mar 2025 18:35:22 GMT, Joe Wang  wrote:

>> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the test: change variables and etc.

changes look OK Joe

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24039#pullrequestreview-2695730699

From asemenyuk at openjdk.org  Tue Mar 18 18:16:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Mar 2025 18:16:41 GMT
Subject: RFR: 8352293: jpackage tests build rpm packages on Ubuntu test
 machines after JDK-8351372
Message-ID: <_aIVIjRlSORV1Q9wreC89nnQdKZvWWUBQ8lt0MZU6bU=.bf6fab10-63bc-4fad-b1db-5462b62871a3@github.com>

Fix a typo.

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

Commit messages:
 - 8352293: jpackage tests build rpm packages on Ubuntu test machines after JDK-8351372

Changes: https://git.openjdk.org/jdk/pull/24101/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352293
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24101/head:pull/24101

PR: https://git.openjdk.org/jdk/pull/24101

From iris at openjdk.org  Tue Mar 18 18:27:08 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 18 Mar 2025 18:27:08 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 18:35:22 GMT, Joe Wang  wrote:

>> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the test: change variables and etc.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24039#pullrequestreview-2695802086

From asemenyuk at openjdk.org  Tue Mar 18 18:37:08 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Mar 2025 18:37:08 GMT
Subject: RFR: 8352275: Clean up dead code in jpackage revealed with
 improved negative test coverage
In-Reply-To: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
References: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
Message-ID: <96XR8s3Y8GwUGJAh-PLmyty25VYGlHAaZw97PmOFwUo=.f9a8af8c-bead-4920-a0f5-9745bb642d7e@github.com>

On Tue, 18 Mar 2025 15:25:40 GMT, Alexey Semenyuk  wrote:

> Follow up code cleanup for https://github.com/openjdk/jdk/pull/23936 PR.
> 
> Details on cleanup actions are given in commit descriptions.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/24099#issuecomment-2734345824

From asemenyuk at openjdk.org  Tue Mar 18 18:40:08 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Mar 2025 18:40:08 GMT
Subject: RFR: 8352275: Clean up dead code in jpackage revealed with
 improved negative test coverage
In-Reply-To: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
References: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
Message-ID: 

On Tue, 18 Mar 2025 15:25:40 GMT, Alexey Semenyuk  wrote:

> Follow up code cleanup for https://github.com/openjdk/jdk/pull/23936 PR.
> 
> Details on cleanup actions are given in commit descriptions.

@justin-curtis-lu PTAL. Is it a valid assumption that removing property keys from the main L10N property file only is sufficient, and the L10N team will take care of these removals in translated property files?

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

PR Comment: https://git.openjdk.org/jdk/pull/24099#issuecomment-2734352518

From asemenyuk at openjdk.org  Tue Mar 18 18:41:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Mar 2025 18:41:07 GMT
Subject: RFR: 8352293: jpackage tests build rpm packages on Ubuntu test
 machines after JDK-8351372
In-Reply-To: <_aIVIjRlSORV1Q9wreC89nnQdKZvWWUBQ8lt0MZU6bU=.bf6fab10-63bc-4fad-b1db-5462b62871a3@github.com>
References: <_aIVIjRlSORV1Q9wreC89nnQdKZvWWUBQ8lt0MZU6bU=.bf6fab10-63bc-4fad-b1db-5462b62871a3@github.com>
Message-ID: 

On Tue, 18 Mar 2025 18:11:36 GMT, Alexey Semenyuk  wrote:

> Fix a typo.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/24101#issuecomment-2734354464

From rriggs at openjdk.org  Tue Mar 18 18:53:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Mar 2025 18:53:11 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 18:35:22 GMT, Joe Wang  wrote:

>> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the test: change variables and etc.

The XMLSchema.dtd changes the referenced version from the 2009 version to the 2001 version. Is that intentional.

src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd line 8:

> 6:     
> 7:          
> 8:               

The other XML comments use the multi-line format with a single begin 
What is the meaning of ""?
Is "REC" a typo?
The comment seems unnecessarily apologetic. It should be sufficient to say:
Note: this DTD is NOT normative, any differences from RFC XXX are insidential". (or similar).

src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd line 20:

> 18: 
> 19: 
> 20:  
> 27: 
> 28: 

There changes seem to be not related to the public identifier additions.

src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd line 60:

> 58: 

Some changes seem to be present to minimize differences from the official versions.
Keeping the split line from the original would show fewer differences.

src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd line 213:

> 211:      name and ref are mutually exclusive, one is required -->
> 212: 

ur-type does not appear in the original; is that intentional? 
(Ref https://www.w3.org/2009/XMLSchema/XMLSchema.dtd)

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24039#pullrequestreview-2695806614
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001727887
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001730500
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001732828
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001737834
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001744036

From kbarrett at openjdk.org  Tue Mar 18 19:02:15 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 18 Mar 2025 19:02:15 GMT
Subject: RFR: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run [v2]
In-Reply-To: 
References: 
 
Message-ID: <_b6y4nS1bXf4N-DBWZHslPIB5aWwc0JW8frsXaLM2zY=.c6d5ba06-8462-4e64-9227-684e2ddadc86@github.com>

On Mon, 17 Mar 2025 17:22:10 GMT, Kim Barrett  wrote:

>> Please review this revision of a previously puzzling comment intending to
>> provide the rationale for a bit of non-obvious code.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bchristi-git review

Thanks for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23952#issuecomment-2734421246

From jiangli at openjdk.org  Tue Mar 18 19:02:18 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Mar 2025 19:02:18 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
Message-ID: 

Please review this PR that adds `@requires !jdk.static` to tests, thanks.

- runtime/StackGap/TestStackGap.java
- runtime/StackGuardPages/TestStackGuardPages.java
- runtime/TLS/TestTLS.java
- runtime/jni/daemonDestroy/TestDaemonDestroy.java
- runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
- jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
- jdk/jni/nullCaller/NullCallerTest.java
- jdk/tools/launcher/JniInvocationTest.java

These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

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

Commit messages:
 - Skip tests using native executable with libjvm.so/libjli.so dependencies on static JDK.

Changes: https://git.openjdk.org/jdk/pull/24103/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352276
  Stats: 8 lines in 8 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24103/head:pull/24103

PR: https://git.openjdk.org/jdk/pull/24103

From kbarrett at openjdk.org  Tue Mar 18 19:02:15 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 18 Mar 2025 19:02:15 GMT
Subject: Integrated: 8351374: Improve comment about queue.remove timeout in
 CleanerImpl.run
In-Reply-To: 
References: 
Message-ID: <6f05FNW41IqWGAuyTtbhTca09v0XmCzOHsehE1Yt6gU=.71570085-4802-46b0-97cc-663a0a32cee3@github.com>

On Fri, 7 Mar 2025 23:17:53 GMT, Kim Barrett  wrote:

> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.

This pull request has now been integrated.

Changeset: 355b2f3b
Author:    Kim Barrett 
URL:       https://git.openjdk.org/jdk/commit/355b2f3bdd99b28c97c7a20ef25ad862012b5007
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8351374: Improve comment about queue.remove timeout in CleanerImpl.run

Reviewed-by: rriggs, shade

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

PR: https://git.openjdk.org/jdk/pull/23952

From rriggs at openjdk.org  Tue Mar 18 19:19:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Mar 2025 19:19:09 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <8tejVEN05-Wgvmqe0gvVALdZi7BGRYrh-PmkO3x4suI=.b953a002-6384-4bd5-ba65-81d0f14ace3e@github.com>

On Fri, 14 Mar 2025 18:35:22 GMT, Joe Wang  wrote:

>> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Shema 1.0 DTDs.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the test: change variables and etc.

test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 25:

> 23: package common.jdkcatalog;
> 24: 
> 25: import static jaxp.library.JAXPTestUtilities.SRC_DIR;

Static imports across classes (even with a package) make it harder to read the test and know where it is imported from. The reference in the source here should include the class its imported from.

test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 143:

> 141:     public void testDTDsInJDKCatalog(String publicId, String systemId) {
> 142:         String matchingPubId = JDKCATALOG.matchPublic(publicId);
> 143:         String matchingSysId = JDKCATALOG.matchSystem(systemId);

Isn't there a public API to get these values. It seems a bit of a hack to have to break module encapsulation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001787672
PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001803674

From lmesnik at openjdk.org  Tue Mar 18 19:24:07 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 18 Mar 2025 19:24:07 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
Message-ID: 

On Sun, 16 Mar 2025 02:54:36 GMT, Ioi Lam  wrote:

> This PR tries to cut down the use of `WhiteBox` in the HotSpot test cases. It modifies `VMProps` to save the set of VM properties into a file called "vm.properties" under Jtreg's work directory. The new API `jdk.test.lib.VMPropsGetter` loads the properties from this file to pass onto individual test cases.
> 
> See `getJtregWorkDir()` for the code that figures out the work directory. It assumes that `VMProps` and all test cases are always executed under
> 
> - `workDir/scratch/` ; or
> - `workDir/scratch/[0-9]+/` 
> 
> This is probably not the right thing to do. I would be better for Jtreg to pass the location of the work directory to the test cases, with a command-line options like `-Djtreg.work.dir=
`.
> 
> To show the benefit of this PR, I modified a few test cases to remove their use of WhiteBox.

Changes requested by lmesnik (Reviewer).

test/lib/jdk/test/lib/VMPropsGetter.java line 53:

> 51:     }
> 52: 
> 53:     static Properties init() {

That is not going to work correctly  for any test that use specific option, saying 
@run main/othervm -XX:+UseCompactObjectHeader Test
will return true for 
`if ("true".equals(VMPropsGetter.get("vm.cds.sharing.enabled"))) {`
because CDS are enabled for VMProps but false for 
`if (wb.isSharingEnabled()) {`
because for this particular test the CDS is not supported.

Also, anything that is executed with ProcessTools is going to have wrong information.

I think it is not the best way. The fix proposed in the https://bugs.openjdk.org/browse/CODETOOLS-7903975
is going to have the same issue.

The VM specific properties should be read only from current VM directly.

I f you want to simplify WB usage, I propose better to rewrite WB APIto  internal JDK test module available for all tests.  
The WB might be implemented like
`module jdk.jfr/jdk.jfr.internal.test` with` jdk.jfr.internal.test.WhiteBox`
I think internal module jdk.internal.test could be implemented to support WB access to JDK.  Additionally it could be protected by VM flags to make it is more clear that shouldn't be used in production.

The another alternative is to add tag `@wbEnabled` to jtreg and teach it to run jtreg run tests with WB API enabled. I can't be added to the TEST.ROOT to whole hotspot tests.

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

PR Review: https://git.openjdk.org/jdk/pull/24071#pullrequestreview-2691487031
PR Review Comment: https://git.openjdk.org/jdk/pull/24071#discussion_r1999302346

From joehw at openjdk.org  Tue Mar 18 19:43:07 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 18 Mar 2025 19:43:07 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <3ebo4UY1MFsuYb4lFFgvCK3N8G6eNuGHRhxk-KNoQpU=.4e6c297b-7ace-4f0d-8ae5-c380743f5844@github.com>

On Tue, 18 Mar 2025 18:50:24 GMT, Roger Riggs  wrote:

> The XMLSchema.dtd changes the referenced version from the 2009 version to the 2001 version. Is that intentional.

Yes. Note the Public Identifier: "-//W3C//DTD XSD 1.1//EN" vs "-//W3C//DTD XMLSCHEMA 200102//EN" at line 2. The 2009 version was for Schema 1.1 while the 2001 version for Schema 1.0. As shown in the JDKCatalog.xml, only Schema 1.0 is included in the catalog. It's a bit unfortunate the files were named the same.

The 1.1 version file was indeed better formatted/worded. But since this is standard file, it was a simple copy without modification.

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

PR Comment: https://git.openjdk.org/jdk/pull/24039#issuecomment-2734522375

From joehw at openjdk.org  Tue Mar 18 19:58:08 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 18 Mar 2025 19:58:08 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 18 Mar 2025 18:26:09 GMT, Roger Riggs  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the test: change variables and etc.
>
> src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd line 8:
> 
>> 6:     
>> 7:          
>> 8:               
> 
> The other XML comments use the multi-line format with a single begin 
> What is the meaning of ""?
> Is "REC" a typo?
> The comment seems unnecessarily apologetic. It should be sufficient to say:
> Note: this DTD is NOT normative, any differences from RFC XXX are insidential". (or similar).

Makes sense. The question would be, would we want to modify the standard file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2001886194

From jlu at openjdk.org  Tue Mar 18 20:49:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Mar 2025 20:49:07 GMT
Subject: RFR: 8352275: Clean up dead code in jpackage revealed with
 improved negative test coverage
In-Reply-To: 
References: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
 
Message-ID: 

On Tue, 18 Mar 2025 18:37:17 GMT, Alexey Semenyuk  wrote:

>> Follow up code cleanup for https://github.com/openjdk/jdk/pull/23936 PR.
>> 
>> Details on cleanup actions are given in commit descriptions.
>
> @justin-curtis-lu PTAL. Is it a valid assumption that removing property keys from the main L10N property file only is sufficient, and the L10N team will take care of these removals in translated property files?

@alexeysemenyukoracle Yes, during the L10n drops the localized files should be updated to reflect the original _including removals_.

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

PR Comment: https://git.openjdk.org/jdk/pull/24099#issuecomment-2734685784

From almatvee at openjdk.org  Tue Mar 18 21:27:06 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Mar 2025 21:27:06 GMT
Subject: RFR: 8352293: jpackage tests build rpm packages on Ubuntu test
 machines after JDK-8351372
In-Reply-To: <_aIVIjRlSORV1Q9wreC89nnQdKZvWWUBQ8lt0MZU6bU=.bf6fab10-63bc-4fad-b1db-5462b62871a3@github.com>
References: <_aIVIjRlSORV1Q9wreC89nnQdKZvWWUBQ8lt0MZU6bU=.bf6fab10-63bc-4fad-b1db-5462b62871a3@github.com>
Message-ID: <_Zki8zHVw3HsMjKZ-LzTMHC3dRmhg4yEv7p2NVmjJNY=.943ba069-03bd-4547-b321-5ce8d785c2f8@github.com>

On Tue, 18 Mar 2025 18:11:36 GMT, Alexey Semenyuk  wrote:

> Fix a typo.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24101#pullrequestreview-2696339103

From asemenyuk at openjdk.org  Tue Mar 18 21:39:19 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Mar 2025 21:39:19 GMT
Subject: Integrated: 8352293: jpackage tests build rpm packages on Ubuntu test
 machines after JDK-8351372
In-Reply-To: <_aIVIjRlSORV1Q9wreC89nnQdKZvWWUBQ8lt0MZU6bU=.bf6fab10-63bc-4fad-b1db-5462b62871a3@github.com>
References: <_aIVIjRlSORV1Q9wreC89nnQdKZvWWUBQ8lt0MZU6bU=.bf6fab10-63bc-4fad-b1db-5462b62871a3@github.com>
Message-ID: <_9roGO8SAjReQ910hLiepHrygwyHBLD5YPKKQB7LWNI=.7a2dd2a3-f90b-449f-8b26-a34ed2fdd217@github.com>

On Tue, 18 Mar 2025 18:11:36 GMT, Alexey Semenyuk  wrote:

> Fix a typo.

This pull request has now been integrated.

Changeset: c8a11f28
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/c8a11f28dff58382f943b3615ca8c7e33d6eab8e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8352293: jpackage tests build rpm packages on Ubuntu test machines after JDK-8351372

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/24101

From almatvee at openjdk.org  Tue Mar 18 21:49:08 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 18 Mar 2025 21:49:08 GMT
Subject: RFR: 8352275: Clean up dead code in jpackage revealed with
 improved negative test coverage
In-Reply-To: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
References: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
Message-ID: 

On Tue, 18 Mar 2025 15:25:40 GMT, Alexey Semenyuk  wrote:

> Follow up code cleanup for https://github.com/openjdk/jdk/pull/23936 PR.
> 
> Details on cleanup actions are given in commit descriptions.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24099#pullrequestreview-2696401898

From asemenyuk at openjdk.org  Tue Mar 18 23:10:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 18 Mar 2025 23:10:11 GMT
Subject: Integrated: 8352275: Clean up dead code in jpackage revealed with
 improved negative test coverage
In-Reply-To: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
References: <85sS8D3XdFpoA5HFTcBQ79kgWo1cC1fOGtyFPqTC1eU=.ec44eede-4bfb-45f3-8624-86d88378d110@github.com>
Message-ID: 

On Tue, 18 Mar 2025 15:25:40 GMT, Alexey Semenyuk  wrote:

> Follow up code cleanup for https://github.com/openjdk/jdk/pull/23936 PR.
> 
> Details on cleanup actions are given in commit descriptions.

This pull request has now been integrated.

Changeset: 8e530633
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/8e530633a9d99d7ce585cafd5573cb89212feee7
Stats:     76 lines in 9 files changed: 2 ins; 67 del; 7 mod

8352275: Clean up dead code in jpackage revealed with improved negative test coverage

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/24099

From asemenyuk at openjdk.org  Wed Mar 19 00:14:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 19 Mar 2025 00:14:47 GMT
Subject: RFR: 8352176: Automate setting up environment for mac signing tests
Message-ID: 

Automate setting up an environment for mac signing tests: create keychain(s), self-signing certificates, and register them in the system.

To set up the environment, run `make test-only TEST=test/jdk/tools/jpackage/macosx/base/SigningBase.java JTREG=JAVA_OPTIONS=-Djpackage.test.SignEnv=setup` command.

The above command will create "jpackagerTest.keychain" keychain, one private RSA key, and four self-signed certificates using this key:
| Certificate common name (CN) | Usage |
|----------------------------------|-----|
| Developer ID Application: jpackage.openjdk.java.net|Code sign|
| Developer ID Installer: jpackage.openjdk.java.net|.pkg sign|
| Developer ID Application: jpackage.openjdk.java.net (?)|Code sign|
| Developer ID Installer: jpackage.openjdk.java.net (?)|.pkg sign|

Certificates will be added to the list of trusted certificates using a sequence of `security add-trusted-cert...` commands (one command per certificate). This step will require user interaction to enter the user account password as many times as the number of created certificates (four). A user will be presented with the "Trust certificate" dialog describing which certificate is about to be added to the list of trusted certificates before the dialog prompting the user password pops up:
trust-cert-prompt

When the user presses the "OK" button on the "Trust certificate" dialog, the dialog prompting the user password will pop up:
trust-cert-prompt-2

Suppose the user presses the "Cancel" button on the "Trust certificate" dialog. In that case, the dialog prompting the user password will NOT pop up, and the whole sequence of adding certificates to the list of trusted certificates will abort.

If the user presses the "Cancel" button on the dialog prompting the user password, it will be dismissed, and the user will start over with the same "Trust certificate" dialog.

Every "Trust certificate" dialog has a one-minute timeout. If the dialog is automatically dismissed because of the timeout expiration, adding certificates to the list of trusted certificates will abort.

To tear down the environment, run `make test-only TEST=test/jdk/tools/jpackage/macosx/base/SigningBase.java JTREG=JAVA_OPTIONS=-Djpackage.test.SignEnv=teardown` command. This command will unlink and delete "jpackagerTest.keychain" keychain. It will not call `security remove-trusted-cert...`.

Setting up the environment multiple times without explicitly tearing it down is safe.

This automation doesn't configure the system to install .pkg bundles produced by jpackage tests. It only allows running signed app launchers and installing signed .dmg bundles.

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

Commit messages:
 - Remove MacSignTest.java
 - Applied bin/blessed-modifier-order.sh
 - Can use jtreg to set up and tear down signing environment for jpackage signing tests.
 - Remove trailing whitespace
 - Minor
 - Better UI for adding trusted certificates
 - Automate signing env setup for the existing mac sign tests
 - Encapsulated signing environment setup/teardown in MacSign.
 - Finalized sign setup code. MacSignTest.testAppImage() pass.
 - Minor and documented experience of setting up sign test environment on macOS Sequoia
 - ... and 1 more: https://git.openjdk.org/jdk/compare/8e530633...f4d55824

Changes: https://git.openjdk.org/jdk/pull/24087/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24087&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352176
  Stats: 904 lines in 4 files changed: 900 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24087.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24087/head:pull/24087

PR: https://git.openjdk.org/jdk/pull/24087

From dholmes at openjdk.org  Wed Mar 19 00:32:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Mar 2025 00:32:06 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou  wrote:

> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
> 
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> - jdk/jni/nullCaller/NullCallerTest.java
> - jdk/tools/launcher/JniInvocationTest.java
> 
> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

@jianglizhou  shouldn't these native executables be built differently to work with the static JDK? Otherwise how does a user create a native executable that launches the JVM?

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735014436

From joehw at openjdk.org  Wed Mar 19 00:43:28 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Mar 2025 00:43:28 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: <8tejVEN05-Wgvmqe0gvVALdZi7BGRYrh-PmkO3x4suI=.b953a002-6384-4bd5-ba65-81d0f14ace3e@github.com>
References: 
 
 <8tejVEN05-Wgvmqe0gvVALdZi7BGRYrh-PmkO3x4suI=.b953a002-6384-4bd5-ba65-81d0f14ace3e@github.com>
Message-ID: 

On Tue, 18 Mar 2025 19:05:32 GMT, Roger Riggs  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the test: change variables and etc.
>
> test/jaxp/javax/xml/jaxp/unittest/common/jdkcatalog/JDKCatalogTest.java line 143:
> 
>> 141:     public void testDTDsInJDKCatalog(String publicId, String systemId) {
>> 142:         String matchingPubId = JDKCATALOG.matchPublic(publicId);
>> 143:         String matchingSysId = JDKCATALOG.matchSystem(systemId);
> 
> Isn't there a public API to get these values. It seems a bit of a hack to have to break module encapsulation.

Updated. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2002201631

From joehw at openjdk.org  Wed Mar 19 00:43:28 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Mar 2025 00:43:28 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Schema 1.0 DTDs. The JDK built-in Catalog contains Schema 1.0 files only.
> 
> DTD files: the Schema 1.1 files, XMLSchema.dtd and datatypes.dtd, were removed and replaced with those of Schema 1.0. These files were downloaded from w3.org without modification. The file names were unfortunately the same, which (with the Diffs) made it look like they were modified though they were not.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  replace JDK Catalog in the java.xml module with public API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24039/files
  - new: https://git.openjdk.org/jdk/pull/24039/files/4482d590..0b5a1cc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24039&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24039&range=01-02

  Stats: 18 lines in 1 file changed: 2 ins; 6 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24039/head:pull/24039

PR: https://git.openjdk.org/jdk/pull/24039

From jiangli at openjdk.org  Wed Mar 19 01:00:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Mar 2025 01:00:14 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Mar 2025 00:29:49 GMT, David Holmes  wrote:

> @jianglizhou shouldn't these native executables be built differently to work with the static JDK? Otherwise how does a user create a native executable that launches the JVM?

I think it's the case of using customized launcher and we need to implement new tests to cover for the static support. The test needs to build native (testing launcher) executable by statically linking with the needed JDK and VM static libraries. We haven't discussed this topic in the hermetic Java meetings yet. I think some build system work is needed so the JDK/VM static libraries would also be built when creating the test native binaries. We probably want to add a new `test-static-image` for that purpose, so building the existing `test-image` target is not affected and does not require the static libraries. I'll create a new RFE for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735042103

From jrose at openjdk.org  Wed Mar 19 01:28:16 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 19 Mar 2025 01:28:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg  wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

Hi again Per!

Here are some brief notes from our face-to-face chat at JavaOne.

Debuggers want/need a "hook" for tentative evaluation of stables.
It is an error for a debugger to trigger stable value decisions.
This applies mainly to stable lists because of `toString`.

Just how "mutable" is a stable list?  How "eager to decide"?
Which methods (if any) are tentative: `toString` / `equals` / `hashCode` ?
Currently in the PR, all are decisive.
This might be a case of the ?wrong default?.

Maybe refactor composites to expose systematically "tenative" access API:

 - Less universal: SV.list(My::compute) => List
 - More universal; SV.stableList(My::compute) => List>

BTW, it?s easy to understand a stable-list as a list of stables.
But let?s be sure to leave room for a more compact data structure.
A compact stable-list is a list of stable views into a backing array.
The backing array looks like `@Stable private T[] resolvedValues`.
Not `private final List> stableValues`.

For the record:  I think this is sufficient for correctness:
Use `getAcquire` (resp. `releaseSet`) for all stable reads (resp. writes.
Do the `releaseSet` inside a mutex that serializes computation.
Add a re-entrancy check in the mutex and throw on vicious cycles.

I do NOT think `volatile` is necessary; it has too many fences.
It is a safe default for a naked variable.  But the stable
variables are encapsulated, and do not need aggressive fences.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2735079141

From jiangli at openjdk.org  Wed Mar 19 02:05:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Mar 2025 02:05:09 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou  wrote:

> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
> 
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> - jdk/jni/nullCaller/NullCallerTest.java
> - jdk/tools/launcher/JniInvocationTest.java
> 
> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

I filed https://bugs.openjdk.org/browse/JDK-8352305.

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735134347

From duke at openjdk.org  Wed Mar 19 05:47:19 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Mar 2025 05:47:19 GMT
Subject: Withdrawn: 8346230: [perf] scalability issue for the
 specjvm2008::xml.transform workload
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Jan 2025 23:08:20 GMT, Vladimir Ivanov  wrote:

> The HashMap for caching was deleted. Now it use only ThreadLocal variable without synchronization.
> According to the specjvm2008::xml.transform workload the performance for low threads counts was not affected and improved for high threads counts. 
> For the 2 socket server based on Xeon 6780E reported scores are (average for 3 runs):
> 2x6780E | 1C | 32C | 64C | 96C | 128C | 160C | 192C | 224C | 256C | 288C
> orig        | 138.9567 | 4127.567 | 8203.907 | 12252.07 | 15496.65 | 16222.91 | 15846.48 | 14758.43 | 14612.34 | 13969.25
> patched | 139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 | 21001.52 | 23847.33 | 26481.25 | 28273.93

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23185

From alanb at openjdk.org  Wed Mar 19 07:02:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Mar 2025 07:02:48 GMT
Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth
 Preview) [v6]
In-Reply-To: 
References: 
Message-ID: <_mAf3dgfq3fG-i3P-Qf3lPpYF26FjP3mPxw63ykxEpI=.06f2ae94-9fe6-435c-b3a8-4e9c1017435c@github.com>

> Changes for [JEP draft: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Sync up from loom repo
 - Merge branch 'master' into JDK-8342486
 - Merge branch 'master' into JDK-8342486
 - Fix link
 - Merge branch 'master' into JDK-8342486
 - Sync up impl/tests form loom repo
 - Merge branch 'master' into JDK-8342486
 - Pull latest API docs + impl from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - ... and 1 more: https://git.openjdk.org/jdk/compare/38499b3f...92827f9a

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

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=05
  Stats: 4080 lines in 14 files changed: 1874 ins; 1458 del; 748 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From perini.davide at dpsoftware.org  Wed Mar 19 09:12:20 2025
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Wed, 19 Mar 2025 10:12:20 +0100
Subject: jpackage and Wix 5
Message-ID: 



Hi there,

I'm using jpackage along with Wix3.

The command I use to generate my .exe is:
           jpackage -i ../../target --type exe --main-class 
org.dpsoftware.JavaFXStarter --main-jar 
FireflyLuciferin-jar-with-dependencies.jar --icon 
../../data/img/java_fast_screen_capture_logo.ico --win-menu 
--win-menu-group Luciferin --copyright "Davide Perini" --name "Firefly 
Luciferin"  --vendor DPsoftware --win-dir-chooser --win-shortcut 
--win-per-user-install --win-upgrade-uuid myuuid --app-version 
"${{steps.get-id.outputs.id}}" --win-shortcut --win-shortcut-prompt 
--java-options "-XX:+UseZGC -XX:+UseStringDeduplication -Xms64m 
-Xmx1024m --add-modules=jdk.incubator.vector"

How can I move it to Wix5 using Java 24?

Is there a guide/documentation that help in migrating from Wix 3 to Wix 
5?

Thanks
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.org  Wed Mar 19 09:14:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Mar 2025 09:14:07 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com>
Message-ID: <_cfhL_4tqzKarT8jOhX7HtQZM9C_bsJcXFTgQxYn45w=.fcbf73ff-8c5d-4050-9ee2-9bc18c9d461b@github.com>

On Tue, 18 Mar 2025 12:31:27 GMT, Magnus Ihse Bursie  wrote:

> And to be absolutely clear: this PR is just about adding new functionality that was not present before.

Sure but I think it's also an attractive nuisance. The VM is very tightly coupled to java.base and a few other core modules. I don't think the build should be supporting grabbing libjvm from another build or another location. Point taken that tools to build and test the JDK need to come from somewhere but it's not as tightly coupled as we have with the proposal here.

For the folks targeting embedded/small environments then I think the right thing is to publish the packaged modules (JMOD files) for the target platform and then use `jlink` to create the run-image with the right  VM + small set of modules that are appropriate for the target environment.

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2735829450

From alanb at openjdk.org  Wed Mar 19 09:23:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Mar 2025 09:23:06 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: 
References: 
 
Message-ID: <-KF_r5JKVAoe-6WdwmLeDrCGtDhtUu6Na4jomJjmYQE=.64a71071-fbfa-450a-b8b3-34e5a1413faf@github.com>

On Wed, 19 Mar 2025 02:02:56 GMT, Jiangli Zhou  wrote:

>> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
>> 
>> - runtime/StackGap/TestStackGap.java
>> - runtime/StackGuardPages/TestStackGuardPages.java
>> - runtime/TLS/TestTLS.java
>> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
>> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
>> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> - jdk/jni/nullCaller/NullCallerTest.java
>> - jdk/tools/launcher/JniInvocationTest.java
>> 
>> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.
>
> I filed https://bugs.openjdk.org/browse/JDK-8352305.

> @jianglizhou shouldn't these native executables be built differently to work with the static JDK? Otherwise how does a user create a native executable that launches the JVM?

Right now, jlink creating a modular run-time image, can generate a launch script in the image bin directory. If/when support for creating a static image comes then it will generate a native executable that runs the application. Configuration that is provided at launch time may need to be provided at link time. In that world then it's not clear if there is a real need for custom launcher code. As Jiangli says, we haven't discussed this yet, so can't rule anything in or out right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735857307

From perini.davide at dpsoftware.org  Wed Mar 19 10:19:02 2025
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Wed, 19 Mar 2025 11:19:02 +0100
Subject: jpackage and Wix 5
In-Reply-To: 
References: 
Message-ID: <45143ffd-635b-4041-aaf8-6eef868d60ef@dpsoftware.org>

I add some context:

I installed wix 5 using the donet command globally,
wix is in the path but when I try to run my jpackage command I get this 
error:

jpackage -i ./target --type exe --main-class 
org.dpsoftware.JavaFXStarter --main-jar 
FireflyLuciferin-jar-with-dependencies.jar --icon 
./data/img/luciferin_logo.ico
 ?--win-menu --win-menu-group Ambilight --copyright "Davide Perini" 
--name "Firefly Luciferin"? --vendor DPsoftware --win-dir-chooser 
--win-shortcut --win-per-user-install --win-shortcut 
--win-shortcut-prompt --java-options "-XX:+UseZGC -Xms64m -Xmx1024m"


java.io.IOException: Command [wix.exe, build, -nologo, -pdbtype, none, 
-intermediatefolder, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj, 
-ext, WixToolset.Util.wixext, -arch, x64, -ext, WixToolset.UI
.wixext, -b, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
-loc, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_de.wxl, 
-loc, C:\Users\SBLANT~1\AppData\
Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_en.wxl, 
-loc, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_ja.wxl, 
-loc, C:\Users\SBLANT~1\AppData\Local\Temp\j
dk.jpackage95160440034084538\config\MsiInstallerStrings_zh_CN.wxl, 
-culture, en-us, -d, JpAppDescription=Firefly Luciferin, -d, 
JpStartMenuShortcutPrompt=yes, -d, JpDesktopShortcutPrompt=yes, -d, 
JpProductCode=e0be8901-8911-3da4
-83e2-2c15892e1623, -d, JpAppName=Firefly Luciferin, -d, 
JpAllowDowngrades=yes, -d, 
JpIcon=C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
Luciferin\Firefly Luciferin.exe, -d, JpAp
pSizeKb=409283, -d, JpAppVersion=1.0, -d, 
JpAfterInstallDirDlg=ShortcutPromptDlg, -d, JpAllowUpgrades=yes, -d, 
JpProductUpgradeCode=2b8902a1-d85a-3650-9b08-d990b365e5e9, -d, 
JpAppVendor=DPsoftware, -d, JpConfigDir=C:\Users\SBLAN
T~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\main.wxs, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\bundle.wx
f, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ui.wxf, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ShortcutPromptDlg.wxs, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpack
age95160440034084538\config\InstallDirNotEmptyDlg.wxs, -out, 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj\a.msi] 
in 
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
Luciferin exited with 144 code


Il 19/03/2025 10:12, Davide Perini ha scritto:
>
> Hi there,
>
> I'm using jpackage along with Wix3.
>
> The command I use to generate my .exe is:
> ? ? ? ? ? jpackage -i ../../target --type exe --main-class 
> org.dpsoftware.JavaFXStarter --main-jar 
> FireflyLuciferin-jar-with-dependencies.jar --icon 
> ../../data/img/java_fast_screen_capture_logo.ico --win-menu 
> --win-menu-group Luciferin --copyright "Davide Perini" --name "Firefly 
> Luciferin" ?--vendor DPsoftware --win-dir-chooser --win-shortcut 
> --win-per-user-install --win-upgrade-uuid myuuid --app-version 
> "${{steps.get-id.outputs.id}}" --win-shortcut --win-shortcut-prompt 
> --java-options "-XX:+UseZGC -XX:+UseStringDeduplication -Xms64m 
> -Xmx1024m --add-modules=jdk.incubator.vector"
>
> How can I move it to Wix5 using Java 24?
>
> Is there a guide/documentation that help in migrating from Wix 3 to Wix 5?
>
> Thanks
> Davide
>


From dl at openjdk.org  Wed Mar 19 10:46:08 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 19 Mar 2025 10:46:08 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool [v2]
In-Reply-To: 
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
 
Message-ID: 

On Tue, 18 Mar 2025 09:11:00 GMT, Dmitry Chuyko  wrote:

>> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
>> 
>> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8134852
>> [2] https://bugs.openjdk.org/browse/JDK-8330017
>
> Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aligned with JDK-8319447

Yes, this is the right fix; thanks!

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

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24034#pullrequestreview-2697891682

From alanb at openjdk.org  Wed Mar 19 11:14:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Mar 2025 11:14:15 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool [v2]
In-Reply-To: 
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
 
Message-ID: <9ilRCdb2hzTiSbbOVFQSZ50FrO9VUhiyA41inLr9z1I=.a5c4803e-f7bd-4f11-886d-fedcbf76dbd2@github.com>

On Tue, 18 Mar 2025 09:11:00 GMT, Dmitry Chuyko  wrote:

>> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
>> 
>> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8134852
>> [2] https://bugs.openjdk.org/browse/JDK-8330017
>
> Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aligned with JDK-8319447

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24034#pullrequestreview-2698006904

From dchuyko at openjdk.org  Wed Mar 19 11:38:18 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 19 Mar 2025 11:38:18 GMT
Subject: RFR: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool [v2]
In-Reply-To: 
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
 
Message-ID: 

On Tue, 18 Mar 2025 09:11:00 GMT, Dmitry Chuyko  wrote:

>> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
>> 
>> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8134852
>> [2] https://bugs.openjdk.org/browse/JDK-8330017
>
> Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aligned with JDK-8319447

Thanks for reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2736311757

From dchuyko at openjdk.org  Wed Mar 19 11:38:19 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 19 Mar 2025 11:38:19 GMT
Subject: Integrated: 8351933: Inaccurate masking of TC subfield decrement in
 ForkJoinPool
In-Reply-To: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
References: <4HMH96wPLSQqHOj8SYbmq1lUNi1vgPTMBFlIftzK-4g=.9d54d0a6-4aec-432f-ba60-f2d6f88243d8@github.com>
Message-ID: 

On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko  wrote:

> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) in one case when TC subfield in ctl field is decremented, the applied masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs prior to 19 FJP may stop executing tasks, which requires a long running application restart [2]. Since 19 it is even harder to reproduce because of the separate parallelism field.
> 
> The fix is to replace 'UMASK & (c - TC_UNIT)'  with '(c & RC_MASK) | ((c - TC_UNIT)  & TC_MASK)' which preserves the RC part of the compareAndSetCtl() candidate argument. On 17u and 11u that repairs known tests and applications. This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8134852
> [2] https://bugs.openjdk.org/browse/JDK-8330017

This pull request has now been integrated.

Changeset: fed34e46
Author:    Dmitry Chuyko 
URL:       https://git.openjdk.org/jdk/commit/fed34e46b89bc9b0462d9b5f5e5ab5516fe18c6e
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8351933: Inaccurate masking of TC subfield decrement in ForkJoinPool

Reviewed-by: dl, alanb, liach

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

PR: https://git.openjdk.org/jdk/pull/24034

From dchuyko at openjdk.org  Wed Mar 19 11:43:11 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 19 Mar 2025 11:43:11 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 14 Mar 2025 09:36:43 GMT, Doug Lea 
 wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use TC_MASK in accord with https://bugs.openjdk.org/browse/JDK-8330017 (Unnecessarily for now.)

Not related to delayed task handling performance but related to the TC_MASK cleanup: as noted in the review of the TC masking fix [1], RC is not always masked accurately (though it's harmless), so maybe such cleanup could be made here as well.

[1] https://github.com/openjdk/jdk/pull/24034#issuecomment-2729780512

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

PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2736326165

From duke at openjdk.org  Wed Mar 19 11:46:41 2025
From: duke at openjdk.org (serhiysachkov)
Date: Wed, 19 Mar 2025 11:46:41 GMT
Subject: RFR: 8351843: change
 open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java
 to a manual test
Message-ID: <_kDe9vTIF0NGsNdXYwArfvQzlsJFgKt6jUroIZJHkXA=.aea95ed0-2a97-438a-abb7-46425aeea05a@github.com>

8351843: change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

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

Commit messages:
 - 8351843:change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test

Changes: https://git.openjdk.org/jdk/pull/24113/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351843
  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24113/head:pull/24113

PR: https://git.openjdk.org/jdk/pull/24113

From erikj at openjdk.org  Wed Mar 19 12:48:08 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Mar 2025 12:48:08 GMT
Subject: RFR: 8352044: Add --with-import-jvms to configure
In-Reply-To: <_cfhL_4tqzKarT8jOhX7HtQZM9C_bsJcXFTgQxYn45w=.fcbf73ff-8c5d-4050-9ee2-9bc18c9d461b@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
 <6wnoatyBda28JODbqHgj089FBNgD_pZoGcTbpWTNkLw=.dd25fe66-c59e-4347-ae90-033aabeae513@github.com>
 <_cfhL_4tqzKarT8jOhX7HtQZM9C_bsJcXFTgQxYn45w=.fcbf73ff-8c5d-4050-9ee2-9bc18c9d461b@github.com>
Message-ID: 

On Wed, 19 Mar 2025 09:11:05 GMT, Alan Bateman  wrote:

> For the folks targeting embedded/small environments then I think the right thing is to publish the packaged modules (JMOD files) for the target platform and then use `jlink` to create the run-image with the right VM + small set of modules that are appropriate for the target environment.

Just to make sure I'm understanding you correctly. Are you proposing that instead of building a single JDK distribution with multiple JVMs, they would build a separate JDK for each alternative JVM configuration and publish java.base.jmod from each of them for end users to pick from when generating their run-images?

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

PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2736507794

From tschatzl at openjdk.org  Wed Mar 19 13:17:19 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Mar 2025 13:17:19 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v25]
In-Reply-To: 
References: 
Message-ID: <5Q9-MERAD4KIP-fzgw7JVAtC9u4L1fEFGcNkdHBvkg4=.1917bd58-a5f8-4c5c-b1f9-27b7457c6262@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * fix IR code generation tests that change due to barrier cost changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/c833bc83..f419556e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=23-24

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From tschatzl at openjdk.org  Wed Mar 19 13:27:17 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Mar 2025 13:27:17 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v25]
In-Reply-To: <5Q9-MERAD4KIP-fzgw7JVAtC9u4L1fEFGcNkdHBvkg4=.1917bd58-a5f8-4c5c-b1f9-27b7457c6262@github.com>
References: 
 <5Q9-MERAD4KIP-fzgw7JVAtC9u4L1fEFGcNkdHBvkg4=.1917bd58-a5f8-4c5c-b1f9-27b7457c6262@github.com>
Message-ID: 

On Wed, 19 Mar 2025 13:17:19 GMT, Thomas Schatzl  wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * fix IR code generation tests that change due to barrier cost changes

Commit https://github.com/openjdk/jdk/pull/23739/commits/f419556e9177ecf9fbf22e606dd6c1b850f4330f fixes the failing compiler tests that check whether the compiler emits the correct object graph. Occurs after merging with mainline that significantly reduces total barrier cost calculation.

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2736639357

From rriggs at openjdk.org  Wed Mar 19 13:48:13 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Mar 2025 13:48:13 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 18 Mar 2025 19:55:39 GMT, Joe Wang  wrote:

>> src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd line 8:
>> 
>>> 6:     
>>> 7:          
>>> 8:               
>> 
>> The other XML comments use the multi-line format with a single begin 
>> What is the meaning of ""?
>> Is "REC" a typo?
>> The comment seems unnecessarily apologetic. It should be sufficient to say:
>> Note: this DTD is NOT normative, any differences from RFC XXX are insidential". (or similar).
>
> Makes sense. The question would be, would we want to modify the standard file?

Likely, a number of my comments were due to comparing with the wrong XMLSchema.data version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2003370242

From alexey.semenyuk at oracle.com  Wed Mar 19 13:56:07 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 19 Mar 2025 09:56:07 -0400
Subject: jpackage and Wix 5
In-Reply-To: <45143ffd-635b-4041-aaf8-6eef868d60ef@dpsoftware.org>
References: 
 <45143ffd-635b-4041-aaf8-6eef868d60ef@dpsoftware.org>
Message-ID: <127f3f80-746e-4bde-8140-1466f1f66fc1@oracle.com>

Hi Davide,

jpackage should work seamlessly with WiX5. Could you run your jpackage 
command with `--verbose` arg? It will provide a context for the error.

- Alexey

On 3/19/2025 6:19 AM, Davide Perini wrote:
> I add some context:
>
> I installed wix 5 using the donet command globally,
> wix is in the path but when I try to run my jpackage command I get 
> this error:
>
> jpackage -i ./target --type exe --main-class 
> org.dpsoftware.JavaFXStarter --main-jar 
> FireflyLuciferin-jar-with-dependencies.jar --icon 
> ./data/img/luciferin_logo.ico
> ?--win-menu --win-menu-group Ambilight --copyright "Davide Perini" 
> --name "Firefly Luciferin"? --vendor DPsoftware --win-dir-chooser 
> --win-shortcut --win-per-user-install --win-shortcut 
> --win-shortcut-prompt --java-options "-XX:+UseZGC -Xms64m -Xmx1024m"
>
>
> java.io.IOException: Command [wix.exe, build, -nologo, -pdbtype, none, 
> -intermediatefolder, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj, 
> -ext, WixToolset.Util.wixext, -arch, x64, -ext, WixToolset.UI
> .wixext, -b, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
> -loc, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_de.wxl, 
> -loc, C:\Users\SBLANT~1\AppData\
> Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_en.wxl, 
> -loc, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_ja.wxl, 
> -loc, C:\Users\SBLANT~1\AppData\Local\Temp\j
> dk.jpackage95160440034084538\config\MsiInstallerStrings_zh_CN.wxl, 
> -culture, en-us, -d, JpAppDescription=Firefly Luciferin, -d, 
> JpStartMenuShortcutPrompt=yes, -d, JpDesktopShortcutPrompt=yes, -d, 
> JpProductCode=e0be8901-8911-3da4
> -83e2-2c15892e1623, -d, JpAppName=Firefly Luciferin, -d, 
> JpAllowDowngrades=yes, -d, 
> JpIcon=C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
> Luciferin\Firefly Luciferin.exe, -d, JpAp
> pSizeKb=409283, -d, JpAppVersion=1.0, -d, 
> JpAfterInstallDirDlg=ShortcutPromptDlg, -d, JpAllowUpgrades=yes, -d, 
> JpProductUpgradeCode=2b8902a1-d85a-3650-9b08-d990b365e5e9, -d, 
> JpAppVendor=DPsoftware, -d, JpConfigDir=C:\Users\SBLAN
> T~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\main.wxs, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\bundle.wx 
>
> f, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ui.wxf, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ShortcutPromptDlg.wxs, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpack
> age95160440034084538\config\InstallDirNotEmptyDlg.wxs, -out, 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj\a.msi] 
> in 
> C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly 
> Luciferin exited with 144 code
>
>
> Il 19/03/2025 10:12, Davide Perini ha scritto:
>>
>> Hi there,
>>
>> I'm using jpackage along with Wix3.
>>
>> The command I use to generate my .exe is:
>> ? ? ? ? ? jpackage -i ../../target --type exe --main-class 
>> org.dpsoftware.JavaFXStarter --main-jar 
>> FireflyLuciferin-jar-with-dependencies.jar --icon 
>> ../../data/img/java_fast_screen_capture_logo.ico --win-menu 
>> --win-menu-group Luciferin --copyright "Davide Perini" --name 
>> "Firefly Luciferin" ?--vendor DPsoftware --win-dir-chooser 
>> --win-shortcut --win-per-user-install --win-upgrade-uuid myuuid 
>> --app-version "${{steps.get-id.outputs.id}}" --win-shortcut 
>> --win-shortcut-prompt --java-options "-XX:+UseZGC 
>> -XX:+UseStringDeduplication -Xms64m -Xmx1024m 
>> --add-modules=jdk.incubator.vector"
>>
>> How can I move it to Wix5 using Java 24?
>>
>> Is there a guide/documentation that help in migrating from Wix 3 to 
>> Wix 5?
>>
>> Thanks
>> Davide
>>
>


From rriggs at openjdk.org  Wed Mar 19 13:59:13 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Mar 2025 13:59:13 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 Mar 2025 00:43:28 GMT, Joe Wang  wrote:

>> Add public identifiers to the JDK built-in Catalog; Replace the incorrect Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct Schema 1.0 DTDs. The JDK built-in Catalog contains Schema 1.0 files only.
>> 
>> DTD files: the Schema 1.1 files, XMLSchema.dtd and datatypes.dtd, were removed and replaced with those of Schema 1.0. These files were downloaded from w3.org without modification. The file names were unfortunately the same, which (with the Diffs) made it look like they were modified though they were not.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace JDK Catalog in the java.xml module with public API

The .dtds look fine.
Thanks for the update to the test.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24039#pullrequestreview-2698536636

From rriggs at openjdk.org  Wed Mar 19 13:59:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Mar 2025 13:59:14 GMT
Subject: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 18 Mar 2025 18:27:56 GMT, Roger Riggs  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the test: change variables and etc.
>
> src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd line 20:
> 
>> 18: 
>> 19: 
>> 20: