From ghadi.shayban at nubank.com.br Mon Jul 1 01:18:58 2024 From: ghadi.shayban at nubank.com.br (Ghadi Shayban) Date: Sun, 30 Jun 2024 21:18:58 -0400 Subject: Time-ordered UUID support, for improved database locality In-Reply-To: References: Message-ID: Today, the JDK includes support for generating random UUIDs ("v4") and name-based UUID's ("v3"). These two types have random leading bits, and that results in poor performance in database systems that have sorted indexes (i.e. most of them). RFC 9562 [1], an update to the original UUID RFC, solves this by including standard formats for time-ordered UUIDs, namely the v7 variant: > UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4 ), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic. > Time-ordered monotonic UUIDs benefit from greater database-index locality because the new values are near each other in the index. As a result, objects are more easily clustered together for better performance. The real-world differences in this approach of index locality versus random data inserts can be one order of magnitude or more. Now that v7 UUIDs are well-defined, does anyone think it would be useful to have in-jdk support for their generation? I am willing to do the work to shepherd a proposal forward, given consensus and interest. [1] https://www.rfc-editor.org/rfc/rfc9562.html -- Confidentiality note: This e-mail may contain confidential information from Nu Holdings Ltd and/or its affiliates. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone; for details about what personal information we collect and why, please refer to our privacy policy . -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jul 1 01:48:52 2024 From: duke at openjdk.org (lingjun-cg) Date: Mon, 1 Jul 2024 01:48:52 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v15] In-Reply-To: References: Message-ID: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: 8333396: Performance regression of DecimalFormat.format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19513/files - new: https://git.openjdk.org/jdk/pull/19513/files/b5bdc733..da09d85a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=13-14 Stats: 9 lines in 3 files changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513 From liach at openjdk.org Mon Jul 1 06:21:22 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Jul 2024 06:21:22 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v9] In-Reply-To: References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: On Sun, 30 Jun 2024 18:21:52 GMT, Shaojin Wen wrote: >> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. >> >> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. >> >> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. >> >> Below is a comparison of String.format and concat-based and StringBuilder: >> >> * benchmark java code >> >> public class StringFormat { >> @Benchmark >> public String stringIntFormat() { >> return "%s %d".formatted(s, i); >> } >> >> @Benchmark >> public String stringIntConcat() { >> return s + " " + i; >> } >> >> @Benchmark >> public String stringIntStringBuilder() { >> return new StringBuilder(s).append(" ").append(i).toString(); >> } >> } >> >> >> * benchmark number on macbook m1 pro >> >> Benchmark Mode Cnt Score Error Units >> StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op >> StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op >> StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op >> >> >> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. >> >> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. >> >> d >> x >> X >> s >> >> If necessary, we can add a few more. >> >> >> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op >> -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op >> -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op >> -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op >> -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op >> -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op >> >> +Benchmark ... > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > code style As promising as the performance number is, I think we need to ensure two things: 1. Correctness: this patch adds a lot of special cases; not sure if the current test cases already cover all of them. In addition, format is i18n stuff, which will need extra review besides the review for performance gains. 2. Validity: the existing benchmarks don't have profile pollution: see `ReflectionSpeedBenchmark` https://github.com/openjdk/jdk/blob/d9bcf061450ebfb7fe02b5a50c855db1d9178e5d/test/micro/org/openjdk/bench/java/lang/reflect/ReflectionSpeedBenchmark.java#L291 where the `Method.invoke` and `Constructor.newInstance` are called to tamper JIT's profiling, as JIT can conclude that only one format shape is ever used in your benchmark, which is unlikely in production. You should call `String.format` and `String.formatted` with varied format strings and arguments in setup for profile pollution.
An extreme example would be at https://github.com/openjdk/jdk/pull/14944#issuecomment-1644050455, where `Arrays.hashCode(Object[])` where every element is an `Integer` is extremely fast, but slows down drastically once different arrays are passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2199327844 From asotona at openjdk.org Mon Jul 1 07:26:17 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 1 Jul 2024 07:26:17 GMT Subject: RFR: 8335290: Rename ClassFile::transform to ClassFile::transformClass In-Reply-To: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com> References: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com> Message-ID: On Fri, 28 Jun 2024 22:01:33 GMT, Chen Liang wrote: > `ClassFile::transform` was initially `ClassModel::transform`, which transforms the receiver class model to a new class byte array. This functionality was in parallel with `ClassBuilder::transform`, which accepts a `ClassModel` and a `ClassTransform` and forwards the results to the receiver builder. > > After the `ClassFile` context object introduction, `ClassModel::transform` becomes `ClassFile::transform`; now, its role is more similar to `ClassBuilder::transformMethod`, `ClassBuilder::transformField`, or `MethodBuilder::transformCode` (transforming subtypes), and it is confusing with `ClassFileBuilder::transform` (which accepts the same model type as the built type). We should rename `ClassFile::transform` to `ClassFile::transformClass` to make this method's role more clear. > > This is separate from #19928 as this has much more user impact. Looks good to me. It will require refresh before integration as the number of use cases across JDK is growing instantly. Thanks! ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19952#pullrequestreview-2150617276 From asotona at openjdk.org Mon Jul 1 07:40:19 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 1 Jul 2024 07:40:19 GMT Subject: RFR: 8335060: ClassCastException after JDK-8294960 In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote: > Conversion of `java.lang.invoke` package to Class-File API is failing to execute method handles with specific type conversion requirements. Root cause is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` implementation. Original code has been matching the types by hash code and it mistakenly appeared to be matching the primitive types. > > This patch fixes `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` and adds tests to better cover `TypeConvertingMethodAdapter` functionality. > > Please review. > > Thanks, > Adam Some volunteer to review this P2 fix? Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19898#issuecomment-2199449124 From redestad at openjdk.org Mon Jul 1 07:55:20 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 1 Jul 2024 07:55:20 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v9] In-Reply-To: References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: On Mon, 1 Jul 2024 06:18:55 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> code style > > As promising as the performance number is, I think we need to ensure two things: > 1. Correctness: this patch adds a lot of special cases; not sure if the current test cases already cover all of them. In addition, format is i18n stuff, which will need extra review besides the review for performance gains. > 2. Validity: the existing benchmarks don't have profile pollution: see `ReflectionSpeedBenchmark` https://github.com/openjdk/jdk/blob/d9bcf061450ebfb7fe02b5a50c855db1d9178e5d/test/micro/org/openjdk/bench/java/lang/reflect/ReflectionSpeedBenchmark.java#L291 where the `Method.invoke` and `Constructor.newInstance` are called to tamper JIT's profiling, as JIT can conclude that only one format shape is ever used in your benchmark, which is unlikely in production. You should call `String.format` and `String.formatted` with varied format strings and arguments in setup for profile pollution.
> An extreme example would be at https://github.com/openjdk/jdk/pull/14944#issuecomment-1644050455, where `Arrays.hashCode(Object[])` where every element is an `Integer` is extremely fast, but slows down drastically once different arrays are passed. Fully agree with the points @liach made above that this needs to be scrutinized for correctness and validity. For example we need to better explore cases where detection for the fast path might be costlier, for example a longer format string with or without some acceptable specifiers early, then something that forces us into the slow path only at the end. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2199478317 From sgehwolf at openjdk.org Mon Jul 1 08:50:31 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 1 Jul 2024 08:50:31 GMT Subject: Integrated: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container In-Reply-To: References: Message-ID: <0hEDyLmsRgW-GR23fKnixv3_5edApaB_eoEQ2D_28NU=.32f148cd-e8a2-4bef-b8bc-44ec7cc0dbd0@github.com> On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote: > Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line: > > > [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present > > > This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example: > > > java -XshowSettings:system --version > Operating System Metrics: > Provider: cgroupv1 > System not containerized. > openjdk 23-internal 2024-09-17 > OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk) > OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing) > > > The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed. > > Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system. > > Testing: > > - [x] GHA (risc-v failure seems infra related) > - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests) > - [x] Some manual testing using cri-o > > Thoughts? This pull request has now been integrated. Changeset: 0a6ffa57 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/0a6ffa57954ddf4f92205205a5a1bada813d127a Stats: 411 lines in 20 files changed: 305 ins; 79 del; 27 mod 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container Reviewed-by: stuefe, iklam ------------- PR: https://git.openjdk.org/jdk/pull/18201 From sgehwolf at openjdk.org Mon Jul 1 08:50:29 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 1 Jul 2024 08:50:29 GMT Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container [v8] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf wrote: >> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line: >> >> >> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present >> >> >> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example: >> >> >> java -XshowSettings:system --version >> Operating System Metrics: >> Provider: cgroupv1 >> System not containerized. >> openjdk 23-internal 2024-09-17 >> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk) >> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing) >> >> >> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed. >> >> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system. >> >> Testing: >> >> - [x] GHA (risc-v failure seems infra related) >> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests) >> - [x] Some manual testing using cri-o >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Refactor mount info matching to helper function > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Remove problem listing of PlainRead which is reworked here > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Add doc for mountinfo scanning. > - Unify naming of variables > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - ... and 8 more: https://git.openjdk.org/jdk/compare/486aa11e...1017da35 Thank you for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2199581201 From jpai at openjdk.org Mon Jul 1 11:18:17 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Jul 2024 11:18:17 GMT Subject: RFR: 8335060: ClassCastException after JDK-8294960 In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote: > Conversion of `java.lang.invoke` package to Class-File API is failing to execute method handles with specific type conversion requirements. Root cause is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` implementation. Original code has been matching the types by hash code and it mistakenly appeared to be matching the primitive types. > > This patch fixes `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` and adds tests to better cover `TypeConvertingMethodAdapter` functionality. > > Please review. > > Thanks, > Adam Hello Adam, I'm not familiar with this code. But looking at the call sites of this method and the code in and around those call sites (including code comments), this change looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19898#pullrequestreview-2151108992 From asotona at openjdk.org Mon Jul 1 11:54:25 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 1 Jul 2024 11:54:25 GMT Subject: RFR: 8335060: ClassCastException after JDK-8294960 In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote: > Conversion of `java.lang.invoke` package to Class-File API is failing to execute method handles with specific type conversion requirements. Root cause is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` implementation. Original code has been matching the types by hash code and it mistakenly appeared to be matching the primitive types. > > This patch fixes `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` and adds tests to better cover `TypeConvertingMethodAdapter` functionality. > > Please review. > > Thanks, > Adam Thank you for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19898#issuecomment-2199936345 From asotona at openjdk.org Mon Jul 1 11:54:26 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 1 Jul 2024 11:54:26 GMT Subject: Integrated: 8335060: ClassCastException after JDK-8294960 In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote: > Conversion of `java.lang.invoke` package to Class-File API is failing to execute method handles with specific type conversion requirements. Root cause is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` implementation. Original code has been matching the types by hash code and it mistakenly appeared to be matching the primitive types. > > This patch fixes `TypeConvertingMethodAdapter::primitiveTypeKindFromClass` and adds tests to better cover `TypeConvertingMethodAdapter` functionality. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 3ca2bcd4 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/3ca2bcd402042791d7460dd79ee16a3f88436b3e Stats: 806 lines in 2 files changed: 798 ins; 0 del; 8 mod 8335060: ClassCastException after JDK-8294960 Reviewed-by: liach, jpai ------------- PR: https://git.openjdk.org/jdk/pull/19898 From duke at openjdk.org Mon Jul 1 12:07:01 2024 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 1 Jul 2024 12:07:01 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v10] In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: > We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. > > This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. > > The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. > > Below is a comparison of String.format and concat-based and StringBuilder: > > * benchmark java code > > public class StringFormat { > @Benchmark > public String stringIntFormat() { > return "%s %d".formatted(s, i); > } > > @Benchmark > public String stringIntConcat() { > return s + " " + i; > } > > @Benchmark > public String stringIntStringBuilder() { > return new StringBuilder(s).append(" ").append(i).toString(); > } > } > > > * benchmark number on macbook m1 pro > > Benchmark Mode Cnt Score Error Units > StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op > StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op > StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op > > > From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. > > The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. > > d > x > X > s > > If necessary, we can add a few more. > > > Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op > -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op > -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op > -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op > -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op > -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op > > +Benchmark Mode Cnt Score Error Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd) > +StringFormat.complexF... Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: add StringFormat test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19956/files - new: https://git.openjdk.org/jdk/pull/19956/files/9b2bb485..7e651817 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=08-09 Stats: 303 lines in 1 file changed: 303 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956 PR: https://git.openjdk.org/jdk/pull/19956 From duke at openjdk.org Mon Jul 1 12:53:42 2024 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 1 Jul 2024 12:53:42 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v11] In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: > We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. > > This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. > > The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. > > Below is a comparison of String.format and concat-based and StringBuilder: > > * benchmark java code > > public class StringFormat { > @Benchmark > public String stringIntFormat() { > return "%s %d".formatted(s, i); > } > > @Benchmark > public String stringIntConcat() { > return s + " " + i; > } > > @Benchmark > public String stringIntStringBuilder() { > return new StringBuilder(s).append(" ").append(i).toString(); > } > } > > > * benchmark number on macbook m1 pro > > Benchmark Mode Cnt Score Error Units > StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op > StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op > StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op > > > From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. > > The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. > > d > x > X > s > > If necessary, we can add a few more. > > > Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op > -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op > -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op > -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op > -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op > -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op > > +Benchmark Mode Cnt Score Error Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd) > +StringFormat.complexF... Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: add more test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19956/files - new: https://git.openjdk.org/jdk/pull/19956/files/7e651817..905012af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=09-10 Stats: 50 lines in 1 file changed: 48 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956 PR: https://git.openjdk.org/jdk/pull/19956 From duke at openjdk.org Mon Jul 1 12:57:21 2024 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 1 Jul 2024 12:57:21 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v11] In-Reply-To: References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: On Mon, 1 Jul 2024 12:53:42 GMT, Shaojin Wen wrote: >> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. >> >> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. >> >> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. >> >> Below is a comparison of String.format and concat-based and StringBuilder: >> >> * benchmark java code >> >> public class StringFormat { >> @Benchmark >> public String stringIntFormat() { >> return "%s %d".formatted(s, i); >> } >> >> @Benchmark >> public String stringIntConcat() { >> return s + " " + i; >> } >> >> @Benchmark >> public String stringIntStringBuilder() { >> return new StringBuilder(s).append(" ").append(i).toString(); >> } >> } >> >> >> * benchmark number on macbook m1 pro >> >> Benchmark Mode Cnt Score Error Units >> StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op >> StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op >> StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op >> >> >> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. >> >> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. >> >> d >> x >> X >> s >> >> If necessary, we can add a few more. >> >> >> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op >> -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op >> -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op >> -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op >> -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op >> -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op >> >> +Benchmark ... > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > add more test I added additional tests and debugged all branches in StringFormat to ensure that they were reached. Is there a way to see the test coverage of jdk core lib code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2200070223 From jwaters at openjdk.org Mon Jul 1 14:22:22 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 1 Jul 2024 14:22:22 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10] In-Reply-To: References: Message-ID: <1_svN_dr71GK3QSvKsqyRyva5qwFMlrG0VAWC8Ei-gE=.c7562293-3835-4416-8e61-055c3b2f5948@github.com> On Fri, 28 Jun 2024 19:43:36 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > use instance resolveAndBind + use junit in tests Build Changes look ok ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2151527800 From sgehwolf at openjdk.org Mon Jul 1 14:43:58 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 1 Jul 2024 14:43:58 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: References: Message-ID: > Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges. > > I'm adding those tests in order to not regress another time. > > Testing: > - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1. > - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to JDK-8322420) > - [x] GHA Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into jdk-8333446-systemd-slice-tests - Merge branch 'master' into jdk-8333446-systemd-slice-tests - Fix comments - 8333446: Add tests for hierarchical container support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19530/files - new: https://git.openjdk.org/jdk/pull/19530/files/00b528ae..22141a48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=01-02 Stats: 26334 lines in 522 files changed: 18610 ins; 5830 del; 1894 mod Patch: https://git.openjdk.org/jdk/pull/19530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19530/head:pull/19530 PR: https://git.openjdk.org/jdk/pull/19530 From jvernee at openjdk.org Mon Jul 1 14:56:51 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 1 Jul 2024 14:56:51 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v11] In-Reply-To: References: Message-ID: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: ofInvokeInstruction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/c597f247..5afb3561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=09-10 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774 From duke at openjdk.org Mon Jul 1 16:30:24 2024 From: duke at openjdk.org (ExE Boss) Date: Mon, 1 Jul 2024 16:30:24 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v5] In-Reply-To: References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: <-Fp_E7k01lNePriQNFlzeiakQ_1ulRFtx5Ojkm4wH6o=.d21c8904-4ba5-4bd1-91b0-18e4bc649637@github.com> On Sat, 29 Jun 2024 19:10:51 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/StringFormat.java line 48: >> >>> 46: static String format(String format, Object... args) { >>> 47: if (args != null) { >>> 48: int off = format.indexOf('%'); >> >> nit: instead of not null check, should this short circuit for null/empty args? >> >> Suggestion: >> >> if (args == null || args.length == 0) { >> // no formatting to be done >> return format; >> } >> >> int off = format.indexOf('%'); > > j.u.Formatter supports args == null When?`args ==?null` or?`args.length ==?0`, then?the?format string can?still contain?`%%` or?`%n`, and?those will?be?formatted to?`"%"` and?[`System?.lineSeparator()`]?respectively. [`System?.lineSeparator()`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#lineSeparator() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1661292677 From jlu at openjdk.org Mon Jul 1 17:48:24 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 1 Jul 2024 17:48:24 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v15] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 01:48:52 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Performance regression of DecimalFormat.format test/micro/org/openjdk/bench/java/text/DateFormatterBench.java line 67: > 65: @Benchmark > 66: public void testFormatDate() { > 67: dateFormat.format(date); Since we are no longer using `Blackhole.consume()`, I would expect `return dateFormat.format(date);`. Applies to the other test methods as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1661364046 From psandoz at openjdk.org Mon Jul 1 18:17:18 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 1 Jul 2024 18:17:18 GMT Subject: RFR: 8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException In-Reply-To: References: Message-ID: On Sat, 1 Jun 2024 11:49:39 GMT, Viktor Klang wrote: > This PR improves the test failure output for the failing test case, and the underlying issue is likely going to be addressed by https://github.com/openjdk/jdk/pull/19131 /cc @DougLea Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19508#pullrequestreview-2152007241 From liach at openjdk.org Mon Jul 1 18:27:25 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Jul 2024 18:27:25 GMT Subject: RFR: 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result Message-ID: Clarify that `ParameterizedType.getOwnerType()` always return `null` in a few scenarios. ------------- Commit messages: - 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result Changes: https://git.openjdk.org/jdk/pull/19977/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306039 Stats: 22 lines in 3 files changed: 2 ins; 8 del; 12 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 duke at openjdk.org Mon Jul 1 19:17:50 2024 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 1 Jul 2024 19:17:50 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v12] In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: > We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. > > This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. > > The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. > > Below is a comparison of String.format and concat-based and StringBuilder: > > * benchmark java code > > public class StringFormat { > @Benchmark > public String stringIntFormat() { > return "%s %d".formatted(s, i); > } > > @Benchmark > public String stringIntConcat() { > return s + " " + i; > } > > @Benchmark > public String stringIntStringBuilder() { > return new StringBuilder(s).append(" ").append(i).toString(); > } > } > > > * benchmark number on macbook m1 pro > > Benchmark Mode Cnt Score Error Units > StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op > StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op > StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op > > > From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. > > The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. > > d > x > X > s > > If necessary, we can add a few more. > > > Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op > -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op > -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op > -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op > -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op > -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op > > +Benchmark Mode Cnt Score Error Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd) > +StringFormat.complexF... Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: improve StringFormat benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19956/files - new: https://git.openjdk.org/jdk/pull/19956/files/905012af..39289870 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=10-11 Stats: 117 lines in 1 file changed: 111 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956 PR: https://git.openjdk.org/jdk/pull/19956 From liach at openjdk.org Mon Jul 1 19:25:25 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Jul 2024 19:25:25 GMT Subject: RFR: 8250659: Clarify in ParameterizedType.getRawType() doc that only Class is returned Message-ID: Clarify that only `Class` is returned for core reflection implementation, and the return type is `Type` to support other implementations, such as ones modeling unloaded or remote types. ------------- Commit messages: - 8250659: Clarify in ParameterizedType.getRawType() doc that only Class is returned Changes: https://git.openjdk.org/jdk/pull/19978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8250659 Stats: 12 lines in 1 file changed: 7 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19978/head:pull/19978 PR: https://git.openjdk.org/jdk/pull/19978 From duke at openjdk.org Mon Jul 1 21:23:19 2024 From: duke at openjdk.org (David Schlosnagle) Date: Mon, 1 Jul 2024 21:23:19 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v5] In-Reply-To: <-Fp_E7k01lNePriQNFlzeiakQ_1ulRFtx5Ojkm4wH6o=.d21c8904-4ba5-4bd1-91b0-18e4bc649637@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> <-Fp_E7k01lNePriQNFlzeiakQ_1ulRFtx5Ojkm4wH6o=.d21c8904-4ba5-4bd1-91b0-18e4bc649637@github.com> Message-ID: <0gzOwxj2jI3DCuLEn_gsR9T_klQKD_iRp9tLSHb_UZ0=.f5cef84d-5dc9-40eb-a5d3-e22be79251d3@github.com> On Mon, 1 Jul 2024 16:28:09 GMT, ExE Boss wrote: >> j.u.Formatter supports args == null > > When?`args ==?null` or?`args.length ==?0`, then?the?format string can?still contain?`%%` or?`%n`, and?those will?be?formatted to?`"%"` and?[`System?.lineSeparator()`]?respectively. > > [`System?.lineSeparator()`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#lineSeparator() Yeah, if args is null or empty and there are format specifiers in the format string it should throw `IllegalFormatException`. To @liach ?s earlier comments, `String.format` likely needs more exhaustive unit tests covering various positive and negative test cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19956#discussion_r1661553502 From liach at openjdk.org Mon Jul 1 21:53:44 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Jul 2024 21:53:44 GMT Subject: RFR: 8335478: Add notes for Error handling in Method.invoke and Constructor.newInstance Message-ID: `Method.invoke` and `Constructor.newInstance` wraps `Error` in `InvocationTargetException`, which is bug-prone for users. Worse, this is only ambiguously mentioned in the API specification. This patch proposes to explicitly mention that `InvocationTargetException` wraps any throwable, and adds an API notes section describing the risk of not handling `InvocationTargetException` (and thereby ignoring the wrapped errors), to advise against future user errors. ------------- Commit messages: - 8335478: Add notes for Error handling in Method.invoke and Constructor.newInstance Changes: https://git.openjdk.org/jdk/pull/19980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335478 Stats: 21 lines in 2 files changed: 19 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19980/head:pull/19980 PR: https://git.openjdk.org/jdk/pull/19980 From liach at openjdk.org Mon Jul 1 22:59:26 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Jul 2024 22:59:26 GMT Subject: RFR: 8335475: ClassBuilder incorrectly calculates max_locals in some cases Message-ID: Trivial fix for the bug where `StackMapGenerator` is pre-allocating the locals incorrectly, affecting static methods with 0 locals. `StackCounter` was not affected. ------------- Commit messages: - 8335475: ClassBuilder incorrectly calculates max_locals in some cases Changes: https://git.openjdk.org/jdk/pull/19981/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19981&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335475 Stats: 32 lines in 2 files changed: 28 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19981/head:pull/19981 PR: https://git.openjdk.org/jdk/pull/19981 From duke at openjdk.org Tue Jul 2 00:57:35 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 2 Jul 2024 00:57:35 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v12] In-Reply-To: References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: On Mon, 1 Jul 2024 19:17:50 GMT, Shaojin Wen wrote: >> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. >> >> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. >> >> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. >> >> Below is a comparison of String.format and concat-based and StringBuilder: >> >> * benchmark java code >> >> public class StringFormat { >> @Benchmark >> public String stringIntFormat() { >> return "%s %d".formatted(s, i); >> } >> >> @Benchmark >> public String stringIntConcat() { >> return s + " " + i; >> } >> >> @Benchmark >> public String stringIntStringBuilder() { >> return new StringBuilder(s).append(" ").append(i).toString(); >> } >> } >> >> >> * benchmark number on macbook m1 pro >> >> Benchmark Mode Cnt Score Error Units >> StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op >> StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op >> StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op >> >> >> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. >> >> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. >> >> d >> x >> X >> s >> >> If necessary, we can add a few more. >> >> >> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op >> -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op >> -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op >> -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op >> -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op >> -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op >> >> +Benchmark ... > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > improve StringFormat benchmark I updated the StringFormat benchmark. Here are the performance numbers on a MacBook M1 Pro: # baseline 5d866bf17d96bd0f0e4545d7eee5912eda2e3a94 -Benchmark Mode Cnt Score Error Units -StringFormat.complexFormat avgt 15 980.323 ? 77.227 ns/op -StringFormat.decimalFormat avgt 15 277.042 ? 17.070 ns/op -StringFormat.intFormat avgt 15 61.400 ? 0.269 ns/op -StringFormat.intFormatUtf16 avgt 15 126.581 ? 2.270 ns/op -StringFormat.intHexFormat avgt 15 232.125 ? 79.431 ns/op -StringFormat.intHexFormatUtf16 avgt 15 113.980 ? 1.537 ns/op -StringFormat.intHexUFormat avgt 15 202.426 ? 10.029 ns/op -StringFormat.intHexUFormatUtf16 avgt 15 132.994 ? 3.183 ns/op -StringFormat.intIntFormat avgt 15 138.301 ? 7.932 ns/op -StringFormat.intIntFormatUtf16 avgt 15 131.910 ? 7.142 ns/op -StringFormat.intOctalFormat avgt 15 249.411 ? 89.041 ns/op -StringFormat.intOctalFormatUtf16 avgt 15 117.244 ? 1.426 ns/op -StringFormat.stringFormat avgt 15 63.645 ? 3.791 ns/op -StringFormat.stringFormatUtf16 avgt 15 150.495 ? 9.363 ns/op -StringFormat.stringIntFormat avgt 15 123.888 ? 4.177 ns/op -StringFormat.stringIntFormatUtf16 avgt 15 174.825 ? 18.766 ns/op -StringFormat.stringIntHexFormat avgt 15 150.750 ? 4.177 ns/op -StringFormat.stringIntHexUFormat avgt 15 162.287 ? 5.530 ns/op -StringFormat.stringIntOctalFormat avgt 15 157.474 ? 6.569 ns/op -StringFormat.stringIntOctalFormatUtf16 avgt 15 151.507 ? 20.590 ns/op -StringFormat.stringIntRFormat avgt 15 135.326 ? 1.884 ns/op -StringFormat.stringIntRFormatUtf16 avgt 15 196.023 ? 6.874 ns/op -StringFormat.stringWidthIntFormat avgt 15 151.324 ? 2.308 ns/op -StringFormat.stringWidthIntFormatUtf16 avgt 15 136.286 ? 2.770 ns/op -StringFormat.widthStringFormat avgt 15 93.960 ? 22.499 ns/op -StringFormat.widthStringFormatUtf16 avgt 15 127.997 ? 18.408 ns/op -StringFormat.widthStringIntFormat avgt 15 150.131 ? 12.496 ns/op -StringFormat.widthStringIntFormatUtf16 avgt 15 159.734 ? 3.821 ns/op # current 392898703ce9907b84d51098ef7b8f536d355742 +Benchmark Mode Cnt Score Error Units +StringFormat.complexFormat avgt 15 909.352 ? 46.681 ns/op +StringFormat.decimalFormat avgt 15 290.069 ? 20.778 ns/op +StringFormat.intFormat avgt 15 11.211 ? 0.047 ns/op +StringFormat.intFormatUtf16 avgt 15 11.799 ? 0.032 ns/op +StringFormat.intHexFormat avgt 15 35.550 ? 7.420 ns/op +StringFormat.intHexFormatUtf16 avgt 15 35.680 ? 1.608 ns/op +StringFormat.intHexUFormat avgt 15 31.229 ? 3.043 ns/op +StringFormat.intHexUFormatUtf16 avgt 15 46.915 ? 7.014 ns/op +StringFormat.intIntFormat avgt 15 31.573 ? 0.539 ns/op +StringFormat.intIntFormatUtf16 avgt 15 31.595 ? 0.345 ns/op +StringFormat.intOctalFormat avgt 15 265.869 ? 60.233 ns/op +StringFormat.intOctalFormatUtf16 avgt 15 153.843 ? 18.901 ns/op +StringFormat.stringFormat avgt 15 10.852 ? 0.009 ns/op +StringFormat.stringFormatUtf16 avgt 15 13.422 ? 0.203 ns/op +StringFormat.stringIntFormat avgt 15 36.833 ? 5.495 ns/op +StringFormat.stringIntFormatUtf16 avgt 15 21.482 ? 0.043 ns/op +StringFormat.stringIntHexFormat avgt 15 19.926 ? 0.041 ns/op +StringFormat.stringIntHexUFormat avgt 15 19.954 ? 0.055 ns/op +StringFormat.stringIntOctalFormat avgt 15 137.748 ? 1.796 ns/op +StringFormat.stringIntOctalFormatUtf16 avgt 15 126.615 ? 13.933 ns/op +StringFormat.stringIntRFormat avgt 15 37.231 ? 2.449 ns/op +StringFormat.stringIntRFormatUtf16 avgt 15 38.406 ? 0.577 ns/op +StringFormat.stringWidthIntFormat avgt 15 43.897 ? 6.464 ns/op +StringFormat.stringWidthIntFormatUtf16 avgt 15 28.683 ? 2.147 ns/op +StringFormat.widthStringFormat avgt 15 11.421 ? 0.021 ns/op +StringFormat.widthStringFormatUtf16 avgt 15 12.228 ? 0.023 ns/op +StringFormat.widthStringIntFormat avgt 15 38.051 ? 6.635 ns/op +StringFormat.widthStringIntFormatUtf16 avgt 15 23.347 ? 1.049 ns/op+ In the scenario where the performance is improved or worse through fastpath and then falls back to j.u.Formatter, it is confusing. | | baseline | current | delta | | --- | --- | --- | --- | | StringFormat.complexFormat | 980.323 | 909.352 | 7.80% | | StringFormat.decimalFormat | 277.042 | 290.069 | -4.49% | | StringFormat.intOctalFormat | 249.411 | 265.869 | -6.19% | | StringFormat.intOctalFormatUtf16 | 117.244 | 153.843 | -23.79% | | StringFormat.stringIntOctalFormat | 157.474 | 137.748 | 14.32% | | StringFormat.stringIntOctalFormatUtf16 | 151.507 | 126.615 | 19.66% | In other scenarios hit by fastpath, the performance is significantly improved. | | baseline | current | delta | | --- | --- | --- | --- | | StringFormat.intFormat | 61.400 | 11.211 | 447.68% | | StringFormat.intFormatUtf16 | 126.581 | 11.799 | 972.81% | | StringFormat.intHexFormat | 232.125 | 35.550 | 552.95% | | StringFormat.intHexFormatUtf16 | 113.980 | 35.680 | 219.45% | | StringFormat.intHexUFormat | 202.426 | 31.229 | 548.20% | | StringFormat.intHexUFormatUtf16 | 132.994 | 46.915 | 183.48% | | StringFormat.intIntFormat | 138.301 | 31.573 | 338.04% | | StringFormat.intIntFormatUtf16 | 131.910 | 31.595 | 317.50% | | StringFormat.stringFormat | 63.645 | 10.852 | 486.48% | | StringFormat.stringFormatUtf16 | 150.495 | 13.422 | 1021.26% | | StringFormat.stringIntFormat | 123.888 | 36.833 | 236.35% | | StringFormat.stringIntFormatUtf16 | 174.825 | 21.482 | 713.82% | | StringFormat.stringIntHexFormat | 150.750 | 19.926 | 656.55% | | StringFormat.stringIntHexUFormat | 162.287 | 19.954 | 713.31% | | StringFormat.stringIntRFormat | 135.326 | 37.231 | 263.48% | | StringFormat.stringIntRFormatUtf16 | 196.023 | 38.406 | 410.40% | | StringFormat.stringWidthIntFormat | 151.324 | 43.897 | 244.73% | | StringFormat.stringWidthIntFormatUtf16 | 136.286 | 28.683 | 375.15% | | StringFormat.widthStringFormat | 93.960 | 11.421 | 722.70% | | StringFormat.widthStringFormatUtf16 | 127.997 | 12.228 | 946.75% | | StringFormat.widthStringIntFormat | 150.131 | 38.051 | 294.55% | | StringFormat.widthStringIntFormatUtf16 | 159.734 | 23.347 | 584.17% | ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2201575948 From duke at openjdk.org Tue Jul 2 01:20:51 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 2 Jul 2024 01:20:51 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v20] In-Reply-To: References: Message-ID: <_E-U8W41Px4E62MdEkHoTWru8oDHpa-D0tRG0XStJ8c=.4e94d76c-62b5-48cd-9245-0acb4eea9eba@github.com> > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 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 51 additional commits since the last revision: - Merge branch 'openjdk:master' into patchSqrt - Added documentation - An optimization - Reverted changes in BigDecimal - Merge branch 'openjdk:master' into patchSqrt - Added "throw" to throw the ArithmeticException created - Correct BigDecimal.sqrt() - Simplified computing square root of BigDecimal using BigInteger.sqrt() - Removed unnecessary variable - Optimized to compute the remainder only if needed - ... and 41 more: https://git.openjdk.org/jdk/compare/1e0f947d...468fdd83 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/af3a36fd..468fdd83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=18-19 Stats: 3707 lines in 108 files changed: 3063 ins; 373 del; 271 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Tue Jul 2 01:44:43 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 2 Jul 2024 01:44:43 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Ensure normalized value in MutableBigInteger initialization with ints ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/468fdd83..b28f034b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=19-20 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Tue Jul 2 02:13:50 2024 From: duke at openjdk.org (lingjun-cg) Date: Tue, 2 Jul 2024 02:13:50 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v16] In-Reply-To: References: Message-ID: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com> > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: 8333396: Performance regression of DecimalFormat.format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19513/files - new: https://git.openjdk.org/jdk/pull/19513/files/da09d85a..7122c2c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=14-15 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513 From asotona at openjdk.org Tue Jul 2 08:47:19 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 2 Jul 2024 08:47:19 GMT Subject: RFR: 8335475: ClassBuilder incorrectly calculates max_locals in some cases In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 22:54:16 GMT, Chen Liang wrote: > Trivial fix for the bug where `StackMapGenerator` is pre-allocating the locals incorrectly, affecting static methods with 0 locals. `StackCounter` was not affected. Looks good to me, thanks for the fix. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19981#pullrequestreview-2153129835 From ysuenaga at openjdk.org Tue Jul 2 12:32:43 2024 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 2 Jul 2024 12:32:43 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided Message-ID: We cannot pass GNU style options like `--enable-preview` to `jlink --add-option`. It is hard to use for complex application. We have workaround for this issue (see JBS), but I think it is better to fix on JDK side. ------------- Commit messages: - 8303884: jlink --add-options plugin does not allow GNU style options to be provided Changes: https://git.openjdk.org/jdk/pull/19987/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19987&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303884 Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19987.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19987/head:pull/19987 PR: https://git.openjdk.org/jdk/pull/19987 From jlahoda at openjdk.org Tue Jul 2 12:50:19 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 2 Jul 2024 12:50:19 GMT Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v4] In-Reply-To: References: Message-ID: On Thu, 27 Jun 2024 19:30:39 GMT, Jan Lahoda wrote: >> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input. >> >> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like: >> >> >> enum E {A, B, C} >> E e = ...; >> switch (e) { >> case null -> {} >> case A a -> {} >> case C c -> {} >> case B b -> {} >> } >> >> >> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums. >> >> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly). >> >> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`). >> >> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index. >> >> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used. >> >> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like: >> >> Benchmark Mode Cnt Score Error Units >> SwitchEnum.enumSwitchTraditional avgt 15 11.719 ? 0.333 ns/op >> Swi... > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Clone the labels. Any input on the current version of the patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19906#issuecomment-2203073610 From jpai at openjdk.org Tue Jul 2 12:54:25 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Jul 2024 12:54:25 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes [v5] In-Reply-To: References: Message-ID: On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bj?rsn?s wrote: >> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`. >> >> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` >> >> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. >> >> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly. >> >> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. >> >> As a note to reviewers, this PR includes the following intended updates: >> >> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes` >> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` >> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected` >> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes` >> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected` >> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected` >> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method >> - Updated copyright in all affected files >> >> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. >> >> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: >> >> >> make test TEST="test/jdk/java/util/jar" >> make test TEST="test/jdk/java/util/zip" > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into zipentry-external-attributes > - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes > - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes > - For clarity, use "externalFileAttributes" instead of "externalAttributes" > - Merge branch 'master' into zipentry-external-attributes > - Update copyright years for 2024 > - Merge branch 'master' into zipentry-external-attributes > - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes Marked as reviewed by jpai (Reviewer). Hello Eirik, the latest changes in this PR (`292d6801`) look good to me. However, these changes cause some (expected) compilation failures in some of the internal classes within some Oracle specific JDK classes. Those tests aren't accessible for external contributors. I will be updating that code to address those failures. That would mean that the integration of this PR will have to be co-ordinated. Can you issue a `/integrate delegate` command on this PR so that it then allows me to do the actual integration along with the Oracle side of changes? ------------- PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-2153714037 PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2203081198 From liach at openjdk.org Tue Jul 2 13:19:21 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Jul 2024 13:19:21 GMT Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v4] In-Reply-To: References: Message-ID: On Thu, 27 Jun 2024 19:30:39 GMT, Jan Lahoda wrote: >> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input. >> >> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like: >> >> >> enum E {A, B, C} >> E e = ...; >> switch (e) { >> case null -> {} >> case A a -> {} >> case C c -> {} >> case B b -> {} >> } >> >> >> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums. >> >> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly). >> >> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`). >> >> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index. >> >> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used. >> >> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like: >> >> Benchmark Mode Cnt Score Error Units >> SwitchEnum.enumSwitchTraditional avgt 15 11.719 ? 0.333 ns/op >> Swi... > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Clone the labels. Marked as reviewed by liach (Committer). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 288: > 286: labels[i] = convertedLabel; > 287: if (constantsOnly) > 288: constantsOnly = EnumDesc.class.isAssignableFrom(convertedLabel.getClass()); Feels a bit weird when we can use `convertedLabel instanceof EnumDesc` ------------- PR Review: https://git.openjdk.org/jdk/pull/19906#pullrequestreview-2153775847 PR Review Comment: https://git.openjdk.org/jdk/pull/19906#discussion_r1662498068 From rriggs at openjdk.org Tue Jul 2 13:54:23 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 2 Jul 2024 13:54:23 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v12] In-Reply-To: References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: On Mon, 1 Jul 2024 19:17:50 GMT, Shaojin Wen wrote: >> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. >> >> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. >> >> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. >> >> Below is a comparison of String.format and concat-based and StringBuilder: >> >> * benchmark java code >> >> public class StringFormat { >> @Benchmark >> public String stringIntFormat() { >> return "%s %d".formatted(s, i); >> } >> >> @Benchmark >> public String stringIntConcat() { >> return s + " " + i; >> } >> >> @Benchmark >> public String stringIntStringBuilder() { >> return new StringBuilder(s).append(" ").append(i).toString(); >> } >> } >> >> >> * benchmark number on macbook m1 pro >> >> Benchmark Mode Cnt Score Error Units >> StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op >> StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op >> StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op >> >> >> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. >> >> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. >> >> d >> x >> X >> s >> >> If necessary, we can add a few more. >> >> >> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op >> -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op >> -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op >> -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op >> -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op >> -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op >> >> +Benchmark ... > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > improve StringFormat benchmark I have serious concerns about going forward with this optimization. It creates duplicate and fragile code that becomes a maintenance overhead. It reduces the performance of the non-covered cases and does nothing for the other cases using Formatter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2203237835 From duke at openjdk.org Tue Jul 2 14:04:52 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 2 Jul 2024 14:04:52 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v13] In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com> > We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. > > This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. > > The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. > > Below is a comparison of String.format and concat-based and StringBuilder: > > * benchmark java code > > public class StringFormat { > @Benchmark > public String stringIntFormat() { > return "%s %d".formatted(s, i); > } > > @Benchmark > public String stringIntConcat() { > return s + " " + i; > } > > @Benchmark > public String stringIntStringBuilder() { > return new StringBuilder(s).append(" ").append(i).toString(); > } > } > > > * benchmark number on macbook m1 pro > > Benchmark Mode Cnt Score Error Units > StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op > StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op > StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op > > > From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. > > The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. > > d > x > X > s > > If necessary, we can add a few more. > > > Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op > -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op > -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op > -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op > -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op > -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op > > +Benchmark Mode Cnt Score Error Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd) > +StringFormat.complexF... Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: optimize width padding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19956/files - new: https://git.openjdk.org/jdk/pull/19956/files/39289870..f1ae26a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=11-12 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956 PR: https://git.openjdk.org/jdk/pull/19956 From aefimov at openjdk.org Tue Jul 2 15:19:25 2024 From: aefimov at openjdk.org (Aleksei Efimov) Date: Tue, 2 Jul 2024 15:19:25 GMT Subject: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v3] In-Reply-To: References: Message-ID: <5pj76PQYnuPApAT_qa6s8o4OzCwEA5OtzLJ5kxLla9o=.90e4f6c6-f957-46a2-9a98-b85b1d00e65e@github.com> On Fri, 28 Jun 2024 10:44:05 GMT, Nizar Benalla wrote: >> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files. >> >> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `` and ``. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file. >> >> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Improve package description based on Efimov's suggestion Package descriptions generated from new `package-info.java` files look good and have the same content as the ones generated from `package.html` files. A minor issue - two leftover tags need to be removed: src/java.naming/share/classes/javax/naming/event/package-info.java line 60: > 58: * An application, for example, can register its interest in changes to > 59: * objects in a context as follows: > 60: *
The leftover `
` can be removed: Suggestion: src/java.naming/share/classes/javax/naming/event/package-info.java line 76: > 74: * } > 75: * } > 76: *
The leftover `
` can be removed: Suggestion: ------------- Changes requested by aefimov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19529#pullrequestreview-2154146953 PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1662721260 PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1662721369 From sgehwolf at openjdk.org Tue Jul 2 15:47:26 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 2 Jul 2024 15:47:26 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v9] In-Reply-To: <-SpzkAC5lqKUTFCx8RWd4H5YtruoJ4wi7tqXhVPe0w0=.0ceb0034-f89c-47b2-9153-8dcf25f947f7@github.com> References: <-SpzkAC5lqKUTFCx8RWd4H5YtruoJ4wi7tqXhVPe0w0=.0ceb0034-f89c-47b2-9153-8dcf25f947f7@github.com> Message-ID: On Wed, 8 May 2024 03:00:50 GMT, Jan Kratochvil wrote: >> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits: >> >> - centos7 compat >> - 64a5feb6: >> - fixes >> - e514824f: >> - ebb459e9: >> - Merge branch 'jerboaarefactor-merge' into jerboaarefactor-merge-cgroup >> - Merge branch 'jerboaarefactor' into jerboaarefactor-merge >> - Merge remote-tracking branch 'origin/master' into jerboaarefactor >> - Merge remote-tracking branch 'origin/master' into jerboaarefactor-merge >> - Merge branch 'master-cgroup' into jerboaarefactor-merge-cgroup >> - ... and 39 more: https://git.openjdk.org/jdk/compare/9347bb7d...3da3a9e5 > > Your patch https://github.com/jerboaa/jdk/commit/92aaa6fd7e3ff8b64de064fecfcd725a157cb5bb#diff-1c49a6b40a810aef82b7da9bfea8f03e07a43062977ba65f75df63c4b7c5b149R89 contains a tab. @jankratochvil Please merge master and try to use the new code from https://bugs.openjdk.org/browse/JDK-8331560 to query the limits. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2203599274 From nbenalla at openjdk.org Tue Jul 2 16:24:49 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Jul 2024 16:24:49 GMT Subject: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v4] In-Reply-To: References: Message-ID: <4NNYLPZ9U3u99gtU-WnyGnZKAFfZcFYy1v_4YZzAwUQ=.f8ea3e18-5d83-4879-8e5f-35b922b861a7@github.com> > Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files. > > The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `` and ``. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file. > > I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: remove two unnecessary tags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19529/files - new: https://git.openjdk.org/jdk/pull/19529/files/0104e4ac..657ef5c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19529&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19529&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19529/head:pull/19529 PR: https://git.openjdk.org/jdk/pull/19529 From nbenalla at openjdk.org Tue Jul 2 16:24:50 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Jul 2024 16:24:50 GMT Subject: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v3] In-Reply-To: <5pj76PQYnuPApAT_qa6s8o4OzCwEA5OtzLJ5kxLla9o=.90e4f6c6-f957-46a2-9a98-b85b1d00e65e@github.com> References: <5pj76PQYnuPApAT_qa6s8o4OzCwEA5OtzLJ5kxLla9o=.90e4f6c6-f957-46a2-9a98-b85b1d00e65e@github.com> Message-ID: On Tue, 2 Jul 2024 15:09:49 GMT, Aleksei Efimov wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve package description based on Efimov's suggestion > > src/java.naming/share/classes/javax/naming/event/package-info.java line 60: > >> 58: * An application, for example, can register its interest in changes to >> 59: * objects in a context as follows: >> 60: *
> > The leftover `
` can be removed: > Suggestion: Fixed both in [657ef5c](https://github.com/openjdk/jdk/pull/19529/commits/657ef5c7532bc587cdead80d35486f30bb931d5e), thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19529#discussion_r1662823840 From liach at openjdk.org Tue Jul 2 16:25:44 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Jul 2024 16:25:44 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved Message-ID: Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. ------------- Commit messages: - 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved Changes: https://git.openjdk.org/jdk/pull/19991/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19991&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304929 Stats: 26 lines in 2 files changed: 15 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/19991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19991/head:pull/19991 PR: https://git.openjdk.org/jdk/pull/19991 From duke at openjdk.org Tue Jul 2 16:50:28 2024 From: duke at openjdk.org (duke) Date: Tue, 2 Jul 2024 16:50:28 GMT Subject: Withdrawn: 8263261: Extend String::translateEscapes to support unicode escapes In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 18:50:56 GMT, Jim Laskey wrote: > Currently String::translateEscapes does not support unicode escapes, reported as a IllegalArgumentException("Invalid escape sequence: ..."). String::translateEscapes should translate unicode escape sequences to provide full coverage, This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17491 From duke at openjdk.org Tue Jul 2 17:59:31 2024 From: duke at openjdk.org (Suryanarayana Garlapati) Date: Tue, 2 Jul 2024 17:59:31 GMT Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for poll() [v10] In-Reply-To: References: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com> Message-ID: On Thu, 10 Aug 2023 15:03:18 GMT, Doug Lea
wrote: >> Thanks for making the fixes Doug! >> Would it also be possible to backport these fixes to Java 17? >> >> It seems to be a very common issue for openHAB users now that they upgrade to openHAB 4 which requires Java 17. >> >> See: >> >> * https://community.openhab.org/t/consistent-100-cpu-use-of-safecall-queue-thread/143792 >> * https://community.openhab.org/t/high-cpu-usage-after-migration-to-oh4/148200 > > @wborn I think 17 should also be OK modulo deleting 2 lines for pre-21 mentioned above. I only checked with 19 though.. @DougLea is there any timeline where we can expect the backport of this fix into jdk17? or any other work around? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-2203971692 From lancea at openjdk.org Tue Jul 2 18:35:26 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 2 Jul 2024 18:35:26 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes [v5] In-Reply-To: References: Message-ID: On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bj?rsn?s wrote: >> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`. >> >> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` >> >> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. >> >> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly. >> >> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. >> >> As a note to reviewers, this PR includes the following intended updates: >> >> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes` >> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` >> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected` >> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes` >> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected` >> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected` >> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method >> - Updated copyright in all affected files >> >> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. >> >> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: >> >> >> make test TEST="test/jdk/java/util/jar" >> make test TEST="test/jdk/java/util/zip" > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into zipentry-external-attributes > - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes > - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes > - For clarity, use "externalFileAttributes" instead of "externalAttributes" > - Merge branch 'master' into zipentry-external-attributes > - Update copyright years for 2024 > - Merge branch 'master' into zipentry-external-attributes > - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-2154579839 From eirbjo at openjdk.org Tue Jul 2 18:41:19 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 2 Jul 2024 18:41:19 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes [v5] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 12:51:26 GMT, Jaikiran Pai wrote: > Can you issue a `/integrate delegate` command on this PR so that it then allows me to do the actual integration along with the Oracle side of changes? Done. And big thanks for your help getting this long-lasting change across the finish line! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2204042346 From dl at openjdk.org Tue Jul 2 19:31:28 2024 From: dl at openjdk.org (Doug Lea) Date: Tue, 2 Jul 2024 19:31:28 GMT Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for poll() [v10] In-Reply-To: References: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com> Message-ID: On Tue, 2 Jul 2024 17:55:31 GMT, Suryanarayana Garlapati wrote: >> @wborn I think 17 should also be OK modulo deleting 2 lines for pre-21 mentioned above. I only checked with 19 though.. > > @DougLea is there any timeline where we can expect the backport of this fix into jdk17? or any other work around? @suryag10 Sorry I'm not the right person to ask about backports. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-2204174455 From vklang at openjdk.org Tue Jul 2 20:30:25 2024 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 2 Jul 2024 20:30:25 GMT Subject: Integrated: 8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException In-Reply-To: References: Message-ID: On Sat, 1 Jun 2024 11:49:39 GMT, Viktor Klang wrote: > This PR improves the test failure output for the failing test case, and the underlying issue is likely going to be addressed by https://github.com/openjdk/jdk/pull/19131 /cc @DougLea This pull request has now been integrated. Changeset: 27982c8f Author: Viktor Klang URL: https://git.openjdk.org/jdk/commit/27982c8f5dad0e2d080846f803055c84bac9fddd Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/19508 From duke at openjdk.org Tue Jul 2 20:51:25 2024 From: duke at openjdk.org (duke) Date: Tue, 2 Jul 2024 20:51:25 GMT Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3] In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> References: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> Message-ID: <7MY3EAfeQYRlSLnyELgdm-yZ1_t1BrAtGASTdlzde-Q=.84327af4-9564-45f1-b47e-97fe7259b6f7@github.com> On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote: >> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > Signed-off-by: sendaoYan @sendaoYan Your change (at version d1eb4fac03a1ebd4a519f132332cd527afe2090b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1906039488 From dlong at openjdk.org Tue Jul 2 20:51:25 2024 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Jul 2024 20:51:25 GMT Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3] In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> References: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> Message-ID: On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote: >> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > Signed-off-by: sendaoYan Why does 8M trigger the OOM Killer, but 1M does not? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-2204387282 From duke at openjdk.org Tue Jul 2 22:17:30 2024 From: duke at openjdk.org (duke) Date: Tue, 2 Jul 2024 22:17:30 GMT Subject: Withdrawn: 8325438: Add exhaustive tests for Math.round intrinsics In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 16:07:02 GMT, Hamlin Li wrote: > HI, > Can you have a look at this patch adding some tests for Math.round instrinsics? > Thanks! > > ### FYI: > During the development of RoundVF/RoundF, we faced the issues which were only spotted by running test exhaustively against 32/64 bits range of int/long. > It's helpful to add these exhaustive tests in jdk for future possible usage, rather than build it everytime when needed. > Of course, we need to put it in `manual` mode, so it's not run when `-automatic` jtreg option is specified which I guess is the mode CI used, please correct me if I'm assume incorrectly. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17753 From liach at openjdk.org Tue Jul 2 23:18:20 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Jul 2024 23:18:20 GMT Subject: Integrated: 8335475: ClassBuilder incorrectly calculates max_locals in some cases In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 22:54:16 GMT, Chen Liang wrote: > Trivial fix for the bug where `StackMapGenerator` is pre-allocating the locals incorrectly, affecting static methods with 0 locals. `StackCounter` was not affected. This pull request has now been integrated. Changeset: 1ef34c18 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/1ef34c183315b70ddc27c177a2867e30132609f5 Stats: 32 lines in 2 files changed: 28 ins; 0 del; 4 mod 8335475: ClassBuilder incorrectly calculates max_locals in some cases Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/19981 From syan at openjdk.org Wed Jul 3 01:30:35 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Jul 2024 01:30:35 GMT Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3] In-Reply-To: References: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> Message-ID: On Tue, 2 Jul 2024 20:49:05 GMT, Dean Long wrote: > Why does 8M trigger the OOM Killer, but 1M does not? 8M trigger the OOM killer on some environments, maybe there are some test machines that 8M trigger the OOM exception rather than OOM killer. The intention of change `8M chunks per iteration` to `1M chunks per iteration`, is make sure this testcase throw OOM exception and then [break the memory allocation loop](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L88) before jvm process OOM killed by docker container. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-2204847751 From jpai at openjdk.org Wed Jul 3 01:33:35 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Jul 2024 01:33:35 GMT Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for poll() [v10] In-Reply-To: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com> References: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com> Message-ID: On Fri, 21 Jul 2023 16:42:25 GMT, Doug Lea
wrote: >> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue). Pasting from internal doc summary of changes: >> * * Class DualNode replaces Qnode, with fields and methods >> * that apply to any match-based dual data structure, and now >> * usable in other j.u.c classes. in particular, SynchronousQueue. >> * * Blocking control (in class DualNode) accommodates >> * VirtualThreads and (perhaps virtualized) uniprocessors. >> * * All fields of this class (LinkedTransferQueue) are >> * default-initializable (to null), allowing further extension >> * (in particular, SynchronousQueue.Transferer) >> * * Head and tail fields are lazily initialized rather than set >> * to a dummy node, while also reducing retries under heavy >> * contention and misorderings, and relaxing some accesses, >> * requiring accommodation in many places (as well as >> * adjustments in WhiteBox tests). > > 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 13 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8301341 > - Address more review comments > - Address review comments > - nitpicks > - Merge branch 'openjdk:master' into JDK-8301341 > - Accommodate white-box tests; use consistent constructions; minor improvements > - Merge branch 'openjdk:master' into JDK-8301341 > - Simplify contention handling; fix test > - Fix inverted test assert; improve internal documentation; simplify code > - Merge branch 'openjdk:master' into JDK-8301341 > - ... and 3 more: https://git.openjdk.org/jdk/compare/37ac993c...f53cee67 Like Doug notes, the JDK backports are managed as a separate project. Details are available here https://openjdk.org/projects/jdk-updates/. For JDK 17 the corresponding project is https://wiki.openjdk.org/display/JDKUpdates/JDK+17u which has the necessary details about the process as well as the mailing list details where you can bring up the backporting question. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-2204851286 From liach at openjdk.org Wed Jul 3 02:43:44 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 02:43:44 GMT Subject: [jdk23] RFR: 8335475: ClassBuilder incorrectly calculates max_locals in some cases Message-ID: <2Gb-4i4BJzRxL2YimwmG1ITHcC5TSvpk1NHUr0Une3Q=.100470b5-f8f4-4d04-92a6-a33dbacaf47b@github.com> Please review this clean backport of #19981 onto JDK 23, fixing `StackMapGenerator` generating static methods with no declared local variable a max local of 1. ------------- Commit messages: - Backport 1ef34c183315b70ddc27c177a2867e30132609f5 Changes: https://git.openjdk.org/jdk/pull/19993/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19993&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335475 Stats: 32 lines in 2 files changed: 28 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19993/head:pull/19993 PR: https://git.openjdk.org/jdk/pull/19993 From liach at openjdk.org Wed Jul 3 02:45:22 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 02:45:22 GMT Subject: Integrated: 8334726: Remove accidentally exposed individual methods from Class-File API In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 14:38:44 GMT, Chen Liang wrote: > In preparation of Class-File API exiting review, we are housekeeping our API surface. These 3 method removals are the most obvious and simple ones. > > This is separated from more throughout and (possibly controversial) changes for the future, to make reviews (both code and CSR) easier. This pull request has now been integrated. Changeset: 3a2d4264 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/3a2d426489ead9672512e0c5a6862284a54734ba Stats: 37 lines in 7 files changed: 0 ins; 30 del; 7 mod 8334726: Remove accidentally exposed individual methods from Class-File API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/19832 From liach at openjdk.org Wed Jul 3 02:46:23 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 02:46:23 GMT Subject: Integrated: 8334734: Remove specialized readXxxEntry methods from ClassReader In-Reply-To: <7G5zGUXmAmiZUZ1g8K4ksYA73NmGnF2EZIIAO4cmf1I=.529a63f1-1592-450e-a9fb-f3679e670741@github.com> References: <7G5zGUXmAmiZUZ1g8K4ksYA73NmGnF2EZIIAO4cmf1I=.529a63f1-1592-450e-a9fb-f3679e670741@github.com> Message-ID: On Fri, 21 Jun 2024 15:52:44 GMT, Chen Liang wrote: > `ClassReader.readXxxEntry` were added before we had generic, type-aware `readEntry` and `readEntryOrNull` APIs (#19330). We should remove these specialized versions in favor of the generic version to reduce API bloating. This pull request has now been integrated. Changeset: 8a664a4c Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/8a664a4c359deefd7237f3672b62d7d8c1ffb453 Stats: 169 lines in 9 files changed: 1 ins; 111 del; 57 mod 8334734: Remove specialized readXxxEntry methods from ClassReader Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/19833 From liach at openjdk.org Wed Jul 3 02:52:22 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 02:52:22 GMT Subject: Integrated: 8335110: Fix instruction name and API spec inconsistencies in CodeBuilder In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 17:27:27 GMT, Chen Liang wrote: > This is a collection of fixes and improvements to CodeBuilder, plus 2 renames. > > Fixes include: > 1. `CodeBuilder::receiverSlot` typo > 2. `CodeAttribute::labelToBci` update spec > 3. `CodeBuilder::exceptionCatch` implementation > 4. `CodeBuilder::if_nonnull`/`if_null` -> `ifnonnull`/`ifnull` > 5. Docs for what instructions factories emit, and to explain why some factories have name mismatch; also a section in summary. This pull request has now been integrated. Changeset: f7af4504 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/f7af4504a804711d93208b763b3e41eafcf61735 Stats: 121 lines in 6 files changed: 105 ins; 1 del; 15 mod 8335110: Fix instruction name and API spec inconsistencies in CodeBuilder Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/19889 From duke at openjdk.org Wed Jul 3 04:11:40 2024 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Jul 2024 04:11:40 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2] In-Reply-To: References: Message-ID: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> > Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. > > The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: 8325525 Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19536/files - new: https://git.openjdk.org/jdk/pull/19536/files/86837571..4d22961a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=00-01 Stats: 309 lines in 3 files changed: 104 ins; 204 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19536/head:pull/19536 PR: https://git.openjdk.org/jdk/pull/19536 From duke at openjdk.org Wed Jul 3 04:14:29 2024 From: duke at openjdk.org (Suryanarayana Garlapati) Date: Wed, 3 Jul 2024 04:14:29 GMT Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for poll() [v10] In-Reply-To: References: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com> Message-ID: On Tue, 2 Jul 2024 19:28:58 GMT, Doug Lea
wrote: >> @DougLea is there any timeline where we can expect the backport of this fix into jdk17? or any other work around? > > @suryag10 Sorry I'm not the right person to ask about backports. Thanks for the info @DougLea and @jaikiran ------------- PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-2205061210 From duke at openjdk.org Wed Jul 3 04:17:23 2024 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Jul 2024 04:17:23 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 15:45:11 GMT, Alexey Semenyuk wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > The test builds an installer that must be installed as a part of the test. This will not work in an environment where tests are executed under a user account with restricted permissions. Building app image instead of an installer is sufficient for this test. > > There are helper classes for writing jpackage tests in https://github.com/openjdk/jdk/tree/master/test/jdk/tools/jpackage/helpers/jdk/jpackage/test folder. > > I'd not use a file to communicate PID of the started process between the launcher and the test. I'd use stdout instead: > > public class ThirdPartyAppLauncher { > public static void main(String[] args) throws IOException { > Process process = new ProcessBuilder("regedit").start(); > System.out.println("RegEdit PID=" + process.pid()); > } > } > > > Compiling, jarring, and running jpackage that will create app image from the jar with these helpers would be as follows: > > JPackageCommand.helloAppImage(TKit.TEST_SRC_ROOT.resolve("apps/ThirdPartyAppLauncher.java") + "*Hello").executeAndAssertImageCreated(); > > > Then you run "ThirdPartyAppLauncher" class using jpackage launcher and capture its stdout: > > String pidStr = new Executor().saveOutput().dumpOutput().setExecutable(cmd.appLauncherPath().toAbsolutePath()).execute(0).getFirstLineOfOutput(); > > // parse regedit PID > long regeditPid = Long.parseLong(pidStr.split("=", 2)[1]); > > // Run your checks > ... > > // Kill only a specific regedit instance > Runtime.getRuntime().exec("taskkill /F /PID " + regeditPid); > > > You may use one of the existing jpackage tests for the reference (https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jpackage/share/AppLauncherEnvTest.java is a good example) Thanks for the inputs @alexeysemenyukoracle. I have addressed the review comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19536#issuecomment-2205063074 From eirbjo at openjdk.org Wed Jul 3 04:39:23 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 3 Jul 2024 04:39:23 GMT Subject: Integrated: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bj?rsn?s wrote: > Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`. > > This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` > > The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. > > To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly. > > While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. > > As a note to reviewers, this PR includes the following intended updates: > > - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes` > - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` > - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected` > - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes` > - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected` > - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected` > - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method > - Updated copyright in all affected files > > If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. > > I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: > > > make test TEST="test/jdk/java/util/jar" > make test TEST="test/jdk/java/util/zip" This pull request has now been integrated. Changeset: d51141e5 Author: Eirik Bj?rsn?s Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/d51141e5fc84f9f933e78d0eb25af86e41798ad5 Stats: 56 lines in 12 files changed: 0 ins; 4 del; 52 mod 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes Reviewed-by: lancea, jpai ------------- PR: https://git.openjdk.org/jdk/pull/16952 From liach at openjdk.org Wed Jul 3 05:06:22 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 05:06:22 GMT Subject: RFR: 8335290: Rename ClassFile::transform to ClassFile::transformClass In-Reply-To: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com> References: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com> Message-ID: On Fri, 28 Jun 2024 22:01:33 GMT, Chen Liang wrote: > `ClassFile::transform` was initially `ClassModel::transform`, which transforms the receiver class model to a new class byte array. This functionality was in parallel with `ClassBuilder::transform`, which accepts a `ClassModel` and a `ClassTransform` and forwards the results to the receiver builder. > > After the `ClassFile` context object introduction, `ClassModel::transform` becomes `ClassFile::transform`; now, its role is more similar to `ClassBuilder::transformMethod`, `ClassBuilder::transformField`, or `MethodBuilder::transformCode` (transforming subtypes), and it is confusing with `ClassFileBuilder::transform` (which accepts the same model type as the built type). We should rename `ClassFile::transform` to `ClassFile::transformClass` to make this method's role more clear. > > This is separate from #19928 as this has much more user impact. Merged fac74b118f5fda4ec297e46238d34ce5b9be1e21 (one commit before master at the time of comment) locally and tested tier 1-3 again; tests pass. Integrating now to avoid potential future conflicts. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19952#issuecomment-2205105705 From liach at openjdk.org Wed Jul 3 05:06:22 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 05:06:22 GMT Subject: Integrated: 8335290: Rename ClassFile::transform to ClassFile::transformClass In-Reply-To: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com> References: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com> Message-ID: <963ClZwjydsEWfBdhMEDiV_Szhe_2Q-6gYS12AtmDrk=.72881d71-2a08-4067-b97f-caca7ad832e8@github.com> On Fri, 28 Jun 2024 22:01:33 GMT, Chen Liang wrote: > `ClassFile::transform` was initially `ClassModel::transform`, which transforms the receiver class model to a new class byte array. This functionality was in parallel with `ClassBuilder::transform`, which accepts a `ClassModel` and a `ClassTransform` and forwards the results to the receiver builder. > > After the `ClassFile` context object introduction, `ClassModel::transform` becomes `ClassFile::transform`; now, its role is more similar to `ClassBuilder::transformMethod`, `ClassBuilder::transformField`, or `MethodBuilder::transformCode` (transforming subtypes), and it is confusing with `ClassFileBuilder::transform` (which accepts the same model type as the built type). We should rename `ClassFile::transform` to `ClassFile::transformClass` to make this method's role more clear. > > This is separate from #19928 as this has much more user impact. This pull request has now been integrated. Changeset: 0db9bc57 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/0db9bc57de07f8f1d0bf657621cb1b8fd7b01211 Stats: 176 lines in 58 files changed: 2 ins; 5 del; 169 mod 8335290: Rename ClassFile::transform to ClassFile::transformClass Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/19952 From vklang at openjdk.org Wed Jul 3 09:32:19 2024 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 3 Jul 2024 09:32:19 GMT Subject: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException In-Reply-To: References: Message-ID: On Fri, 10 May 2024 01:24:15 GMT, Chen Liang wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > @stuart-marks Can you take a look at this? I've had a look here, and it functionally looks good to me. The remaining challenge is the impact of the change on existing code (likely written between 11 and now, as <10 code would not have the problem AFAICT). /cc @liach ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2205561866 From vklang at openjdk.org Wed Jul 3 09:35:31 2024 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 3 Jul 2024 09:35:31 GMT Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for poll() [v10] In-Reply-To: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com> References: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com> Message-ID: On Fri, 21 Jul 2023 16:42:25 GMT, Doug Lea
wrote: >> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue). Pasting from internal doc summary of changes: >> * * Class DualNode replaces Qnode, with fields and methods >> * that apply to any match-based dual data structure, and now >> * usable in other j.u.c classes. in particular, SynchronousQueue. >> * * Blocking control (in class DualNode) accommodates >> * VirtualThreads and (perhaps virtualized) uniprocessors. >> * * All fields of this class (LinkedTransferQueue) are >> * default-initializable (to null), allowing further extension >> * (in particular, SynchronousQueue.Transferer) >> * * Head and tail fields are lazily initialized rather than set >> * to a dummy node, while also reducing retries under heavy >> * contention and misorderings, and relaxing some accesses, >> * requiring accommodation in many places (as well as >> * adjustments in WhiteBox tests). > > 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 13 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8301341 > - Address more review comments > - Address review comments > - nitpicks > - Merge branch 'openjdk:master' into JDK-8301341 > - Accommodate white-box tests; use consistent constructions; minor improvements > - Merge branch 'openjdk:master' into JDK-8301341 > - Simplify contention handling; fix test > - Fix inverted test assert; improve internal documentation; simplify code > - Merge branch 'openjdk:master' into JDK-8301341 > - ... and 3 more: https://git.openjdk.org/jdk/compare/633a84d0...f53cee67 Just my 2 cents?given the size of this change, I'd be hesitant to have it backported. Also, more than this PR would need to be backported, for instance: https://github.com/openjdk/jdk/pull/19271 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-2205567436 From jpai at openjdk.org Wed Jul 3 10:09:23 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Jul 2024 10:09:23 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v6] In-Reply-To: <5qJEY-WPndRHH2bFUGB5BC-L0zbhsebcepWFxlEq310=.3ccf6e2e-b610-4152-88aa-83e737375436@github.com> References: <5qJEY-WPndRHH2bFUGB5BC-L0zbhsebcepWFxlEq310=.3ccf6e2e-b610-4152-88aa-83e737375436@github.com> Message-ID: On Thu, 30 May 2024 20:26:38 GMT, Liam Miller-Cushon wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Move test to test/jdk/tools/launcher > > @bridgekeeper please keep this open Hello Liam @cushon, please keep this open. Some of us have this on our list to review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2205652636 From jvernee at openjdk.org Wed Jul 3 12:02:18 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 3 Jul 2024 12:02:18 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 16:20:54 GMT, Chen Liang wrote: > Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 226: > 224: } > 225: }); > 226: mtype = mt; Can you drop this intermediate variable, and just assign to `mtype` directly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1664072718 From liach at openjdk.org Wed Jul 3 12:07:19 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 12:07:19 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 11:57:31 GMT, Jorn Vernee wrote: >> Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. > > src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 226: > >> 224: } >> 225: }); >> 226: mtype = mt; > > Can you drop this intermediate variable, and just assign to `mtype` directly? Then I would have to suppress the deprecation warning for the security manager over the whole method. Is that acceptable? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1664081082 From jvernee at openjdk.org Wed Jul 3 13:15:18 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 3 Jul 2024 13:15:18 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 16:20:54 GMT, Chen Liang wrote: > Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19991#pullrequestreview-2156417137 From jvernee at openjdk.org Wed Jul 3 13:15:20 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 3 Jul 2024 13:15:20 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 12:04:37 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 226: >> >>> 224: } >>> 225: }); >>> 226: mtype = mt; >> >> Can you drop this intermediate variable, and just assign to `mtype` directly? > > Then I would have to suppress the deprecation warning for the security manager over the whole method. Is that acceptable? Ah, I see. It's fine like this then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1664171625 From jvernee at openjdk.org Wed Jul 3 13:44:19 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 3 Jul 2024 13:44:19 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 16:20:54 GMT, Chen Liang wrote: > Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 228: > 226: mtype = mt; > 227: } catch (TypeNotPresentException ex) { > 228: throw (ClassNotFoundException) ex.getCause(); On a side note, I wonder if it's better to re-wrap the exception here as a `ReflectiveOperationException`, instead of just getting the cause. That will retain the entire stack trace. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1664215860 From liach at openjdk.org Wed Jul 3 14:16:19 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 14:16:19 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:41:29 GMT, Jorn Vernee wrote: >> Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. > > src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 228: > >> 226: mtype = mt; >> 227: } catch (TypeNotPresentException ex) { >> 228: throw (ClassNotFoundException) ex.getCause(); > > On a side note, I wonder if it's better to re-wrap the exception here as a `ReflectiveOperationException`, instead of just getting the cause. That will retain the entire stack trace. Fyi the exception was thrown at https://github.com/openjdk/jdk/blob/5a8af2b8b93672de9b3a3e73e6984506980da932/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java#L95. I will make builds with both approaches, and see how their traces differ. I will stay on rethrow only if the original stacktrace is already informative enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1664266161 From nbenalla at openjdk.org Wed Jul 3 14:31:23 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Jul 2024 14:31:23 GMT Subject: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v4] In-Reply-To: <4NNYLPZ9U3u99gtU-WnyGnZKAFfZcFYy1v_4YZzAwUQ=.f8ea3e18-5d83-4879-8e5f-35b922b861a7@github.com> References: <4NNYLPZ9U3u99gtU-WnyGnZKAFfZcFYy1v_4YZzAwUQ=.f8ea3e18-5d83-4879-8e5f-35b922b861a7@github.com> Message-ID: On Tue, 2 Jul 2024 16:24:49 GMT, Nizar Benalla wrote: >> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files. >> >> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `` and ``. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file. >> >> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > remove two unnecessary tags Thank you Aleksei for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19529#issuecomment-2206291461 From aefimov at openjdk.org Wed Jul 3 14:31:22 2024 From: aefimov at openjdk.org (Aleksei Efimov) Date: Wed, 3 Jul 2024 14:31:22 GMT Subject: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v4] In-Reply-To: <4NNYLPZ9U3u99gtU-WnyGnZKAFfZcFYy1v_4YZzAwUQ=.f8ea3e18-5d83-4879-8e5f-35b922b861a7@github.com> References: <4NNYLPZ9U3u99gtU-WnyGnZKAFfZcFYy1v_4YZzAwUQ=.f8ea3e18-5d83-4879-8e5f-35b922b861a7@github.com> Message-ID: On Tue, 2 Jul 2024 16:24:49 GMT, Nizar Benalla wrote: >> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files. >> >> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `` and ``. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file. >> >> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > remove two unnecessary tags The latest changes look good to me ------------- Marked as reviewed by aefimov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19529#pullrequestreview-2156608099 From duke at openjdk.org Wed Jul 3 14:31:23 2024 From: duke at openjdk.org (duke) Date: Wed, 3 Jul 2024 14:31:23 GMT Subject: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v4] In-Reply-To: <4NNYLPZ9U3u99gtU-WnyGnZKAFfZcFYy1v_4YZzAwUQ=.f8ea3e18-5d83-4879-8e5f-35b922b861a7@github.com> References: <4NNYLPZ9U3u99gtU-WnyGnZKAFfZcFYy1v_4YZzAwUQ=.f8ea3e18-5d83-4879-8e5f-35b922b861a7@github.com> Message-ID: <-ptgeMI_Mx_lTeBmakwzxnni1tOFTK7efbTPq0jdQrE=.af6ab966-1bc4-470a-a0d7-16ca41960d9e@github.com> On Tue, 2 Jul 2024 16:24:49 GMT, Nizar Benalla wrote: >> Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files. >> >> The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `` and ``. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file. >> >> I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > remove two unnecessary tags @nizarbenalla Your change (at version 657ef5c7532bc587cdead80d35486f30bb931d5e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19529#issuecomment-2206293817 From asemenyuk at openjdk.org Wed Jul 3 16:49:20 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Jul 2024 16:49:20 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2] In-Reply-To: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> References: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> Message-ID: On Wed, 3 Jul 2024 04:11:40 GMT, Vanitha B P wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > 8325525 Addressed review comments test/jdk/tools/jpackage/apps/ThirdPartyAppLauncher.java line 34: > 32: ProcessBuilder processBuilder = new ProcessBuilder("regedit"); > 33: Process process = processBuilder.start(); > 34: logger.info("RegEdit id=" + process.pid()); Logging is excessive and not applicable here as it can be redirected. The test shall print the PID to stdout. test/jdk/tools/jpackage/share/JpackageTest.java line 59: > 57: @Test > 58: public static void test() throws Throwable { > 59: JpackageTest test = new JpackageTest(); There is no need to explicitly call the ctor ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664484472 PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664485737 From naoto at openjdk.org Wed Jul 3 16:58:26 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Jul 2024 16:58:26 GMT Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in java.base [v7] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 11:11:51 GMT, Nizar Benalla wrote: >> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix. >> This is related to #18934 and my work around the `@since` checker feature. >> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker. >> >> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N" >> >> Screenshot 2024-05-06 at 00 06 57 >> >> >> >> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended. >> >> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed. >> >> Screenshot 2024-05-06 at 00 07 16 >> >> Screenshot 2024-05-06 at 00 08 06 >> >> Screenshot 2024-05-06 at 00 09 03 >> >> >> TIA > > Nizar Benalla 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 14 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8330954 > - Add new line when having multi-line doc comment > - Merge remote-tracking branch 'upstream/master' into 8330954 > - Merge remote-tracking branch 'upstream/master' into 8330954 > - (C) > - (C) > - Move security classes changes to pr18373 > - remove couple extra lines > - Pull request is now only about `@since` tags, might add an other commit > - add one more `{inheritDoc}` to `CompletableFuture.state` > - ... and 4 more: https://git.openjdk.org/jdk/compare/36d15a13...afca07bf OK, I look at other areas and I believe they are fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2206794418 From asemenyuk at openjdk.org Wed Jul 3 17:02:23 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Jul 2024 17:02:23 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2] In-Reply-To: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> References: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> Message-ID: On Wed, 3 Jul 2024 04:11:40 GMT, Vanitha B P wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > 8325525 Addressed review comments test/jdk/tools/jpackage/share/JpackageTest.java line 79: > 77: // parse to get regedit PID > 78: regeditPid = Long.parseLong(pidStr.split("=", 2)[1]); > 79: logger.info("Regedit PID is " + regeditPid); We use `TKit.log()` for logging in jpackage tests. You can do `TKit.log("Regedit PID is " + regeditPid)` test/jdk/tools/jpackage/share/JpackageTest.java line 97: > 95: throw new RuntimeException( > 96: "Test failed: Third party software is terminated"); > 97: } Use `TKit.assertTrue(isAlive, "Check is regedit process is alive");` instead ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664497233 PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664499364 From liach at openjdk.org Wed Jul 3 19:14:19 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 19:14:19 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:41:29 GMT, Jorn Vernee wrote: >> Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. > > src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 228: > >> 226: mtype = mt; >> 227: } catch (TypeNotPresentException ex) { >> 228: throw (ClassNotFoundException) ex.getCause(); > > On a side note, I wonder if it's better to re-wrap the exception here as a `ReflectiveOperationException`, instead of just getting the cause. That will retain the entire stack trace. @JornVernee Here are a few traces for comparison: https://gist.github.com/5d441ab2159833e808303d1accb66ee8 In all cases, the entire stacktrace is retained; this ClassNotFoundException has the `MethodTypeDescImpl::resolveConstantDesc` in its trace already. I believe directly unwrapping the `ClassNotFoundException` is the best: 1. In future optimization, we can parse the individual classes more directly (such as via `ClassDesc.resolveConstantDesc`) and the new code can just throw the CNFE directly without extra wrapping, as user don't anticipate wrapped causes. 2. `IllegalAccessException` throwing is done directly. Also, would you mind to review the associated CSR as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1664635640 From hgreule at openjdk.org Wed Jul 3 19:47:39 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 3 Jul 2024 19:47:39 GMT Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception Message-ID: Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods. The exception message is less exact, but I think that's acceptable. ------------- Commit messages: - add test (and find missing method) - make reflective calls to signature polymorphic methods in VarHandle throw UOE Changes: https://git.openjdk.org/jdk/pull/20015/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20015&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335638 Stats: 75 lines in 2 files changed: 71 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20015/head:pull/20015 PR: https://git.openjdk.org/jdk/pull/20015 From almatvee at openjdk.org Wed Jul 3 20:08:21 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 3 Jul 2024 20:08:21 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2] In-Reply-To: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> References: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> Message-ID: On Wed, 3 Jul 2024 04:11:40 GMT, Vanitha B P wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > 8325525 Addressed review comments test/jdk/tools/jpackage/apps/ThirdPartyAppLauncher.java line 27: > 25: import java.util.logging.Logger; > 26: > 27: public class ThirdPartyAppLauncher { Maybe `ChildProcessAppLauncher` to match test name? test/jdk/tools/jpackage/apps/ThirdPartyAppLauncher.java line 32: > 30: > 31: public static void main(String[] args) throws IOException { > 32: ProcessBuilder processBuilder = new ProcessBuilder("regedit"); `regedit` will trigger elevation prompt if UAC is enabled, so this test will not be able to run without user interaction. My suggestion is to use something that does not requires elevation. For example: `calc.exe`. Also, use full path to executable, otherwise it is not clear what will be run. I think `System.getenv("SYSTEM")` should give path to `%WINDIR%\system32` where `calc` is located. test/jdk/tools/jpackage/share/JpackageTest.java line 51: > 49: import jdk.jpackage.test.TKit; > 50: > 51: public class JpackageTest { Can we put it under `test/jdk/tools/jpackage/windows`, since it is Windows only test? Also, it needs better name. For example: `WinChildProcessTest`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664685484 PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664702036 PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1664681991 From liach at openjdk.org Wed Jul 3 20:36:22 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 20:36:22 GMT Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 19:43:05 GMT, Hannes Greule wrote: > Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods. > > The exception message is less exact, but I think that's acceptable. Great work! src/hotspot/share/prims/methodHandles.cpp line 1372: > 1370: */ > 1371: JVM_ENTRY(jobject, VH_UOE(JNIEnv* env, jobject mh, jobjectArray args)) { > 1372: THROW_MSG_NULL(vmSymbols::java_lang_UnsupportedOperationException(), "VarHandle access mode method a cannot be invoked reflectively"); Suggestion: THROW_MSG_NULL(vmSymbols::java_lang_UnsupportedOperationException(), "VarHandle access mode methods cannot be invoked reflectively"); Looks like a typo to me. src/hotspot/share/prims/methodHandles.cpp line 1419: > 1417: static JNINativeMethod VH_methods[] = { > 1418: // UnsupportedOperationException throwers > 1419: {CC "compareAndExchange", CC "([" OBJ ")" OBJ, FN_PTR(VH_UOE)}, I recommend ordering these by the order in `AccessMode`, which is also the declaration order in `VarHandle`; that way, if we add a new access mode, it's easier for us to maintain this list. src/hotspot/share/prims/methodHandles.cpp line 1457: > 1455: JVM_ENTRY(void, JVM_RegisterMethodHandleMethods(JNIEnv *env, jclass MHN_class)) { > 1456: assert(!MethodHandles::enabled(), "must not be enabled"); > 1457: assert(vmClasses::MethodHandle_klass() != nullptr, "should be present"); Should we duplicate this assert for `vmClasses::VarHandle_klass()` too? test/jdk/java/lang/invoke/VarHandles/VarHandleTestReflection.java line 1: > 1: /* The copyright header's year needs an update. test/jdk/java/lang/invoke/VarHandles/VarHandleTestReflection.java line 69: > 67: VarHandle v = handle(); > 68: > 69: // Try a reflective invoke using a Method, with an array of 0 arguments Suggestion: // Try a reflective invoke using a Method, with the minimal required argument test/jdk/java/lang/invoke/VarHandles/VarHandleTestReflection.java line 72: > 70: > 71: Method vhm = VarHandle.class.getMethod(accessMode.methodName(), Object[].class); > 72: Object args = new Object[0]; I recommend naming this `arg`, as this is the single arg to the reflected method. Had you inlined this, you would have called `vhm.invoke(v, (Object) new Object[0]);` ------------- PR Review: https://git.openjdk.org/jdk/pull/20015#pullrequestreview-2157341254 PR Review Comment: https://git.openjdk.org/jdk/pull/20015#discussion_r1664744641 PR Review Comment: https://git.openjdk.org/jdk/pull/20015#discussion_r1664741601 PR Review Comment: https://git.openjdk.org/jdk/pull/20015#discussion_r1664737631 PR Review Comment: https://git.openjdk.org/jdk/pull/20015#discussion_r1664753008 PR Review Comment: https://git.openjdk.org/jdk/pull/20015#discussion_r1664751627 PR Review Comment: https://git.openjdk.org/jdk/pull/20015#discussion_r1664751688 From psandoz at openjdk.org Wed Jul 3 21:34:18 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 3 Jul 2024 21:34:18 GMT Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 19:43:05 GMT, Hannes Greule wrote: > Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods. > > The exception message is less exact, but I think that's acceptable. src/hotspot/share/prims/methodHandles.cpp line 1371: > 1369: * invoked directly. > 1370: */ > 1371: JVM_ENTRY(jobject, VH_UOE(JNIEnv* env, jobject mh, jobjectArray args)) { Suggestion: JVM_ENTRY(jobject, VH_UOE(JNIEnv* env, jobject vh, jobjectArray args)) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20015#discussion_r1664836522 From duke at openjdk.org Wed Jul 3 21:51:37 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 3 Jul 2024 21:51:37 GMT Subject: RFR: 8335645: j.u.Formatter#trailingZeros improved with String repeat Message-ID: In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros ------------- Commit messages: - use StringBuilder#repeat Changes: https://git.openjdk.org/jdk/pull/20018/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20018&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335645 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20018/head:pull/20018 PR: https://git.openjdk.org/jdk/pull/20018 From liach at openjdk.org Wed Jul 3 21:55:20 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 21:55:20 GMT Subject: RFR: 8335645: j.u.Formatter#trailingZeros improved with String repeat In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote: > In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20018#pullrequestreview-2157534378 From jlu at openjdk.org Wed Jul 3 22:19:18 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Jul 2024 22:19:18 GMT Subject: RFR: 8335645: j.u.Formatter#trailingZeros improved with String repeat In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote: > In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros +1 ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/20018#pullrequestreview-2157583915 From naoto at openjdk.org Wed Jul 3 22:36:18 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Jul 2024 22:36:18 GMT Subject: RFR: 8335645: j.u.Formatter#trailingZeros improved with String repeat In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote: > In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20018#pullrequestreview-2157610512 From duke at openjdk.org Wed Jul 3 22:56:18 2024 From: duke at openjdk.org (duke) Date: Wed, 3 Jul 2024 22:56:18 GMT Subject: RFR: 8335645: j.u.Formatter#trailingZeros improved with String repeat In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote: > In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros @wenshao Your change (at version a98bd05c857d0a04dfad471dd28f905be1345376) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20018#issuecomment-2207438128 From naoto at openjdk.org Wed Jul 3 23:10:18 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Jul 2024 23:10:18 GMT Subject: RFR: 8335645: j.u.Formatter#trailingZeros improved with String repeat In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote: > In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros As a general rule, please wait for at least 24 hours to integrate, for devs around the globe to take a look (unless emergency such as a build break). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20018#issuecomment-2207447047 From liach at openjdk.org Wed Jul 3 23:13:18 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 23:13:18 GMT Subject: RFR: 8335645: j.u.Formatter#trailingZeros improved with String repeat In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote: > In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros See https://openjdk.org/guide/#life-of-a-pr point 6 for the 24-hour wait rule. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20018#issuecomment-2207452838 From duke at openjdk.org Thu Jul 4 00:39:19 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 4 Jul 2024 00:39:19 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v13] In-Reply-To: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com> Message-ID: On Tue, 2 Jul 2024 14:04:52 GMT, Shaojin Wen wrote: >> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. >> >> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. >> >> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. >> >> Below is a comparison of String.format and concat-based and StringBuilder: >> >> * benchmark java code >> >> public class StringFormat { >> @Benchmark >> public String stringIntFormat() { >> return "%s %d".formatted(s, i); >> } >> >> @Benchmark >> public String stringIntConcat() { >> return s + " " + i; >> } >> >> @Benchmark >> public String stringIntStringBuilder() { >> return new StringBuilder(s).append(" ").append(i).toString(); >> } >> } >> >> >> * benchmark number on macbook m1 pro >> >> Benchmark Mode Cnt Score Error Units >> StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op >> StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op >> StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op >> >> >> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. >> >> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. >> >> d >> x >> X >> s >> >> If necessary, we can add a few more. >> >> >> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op >> -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op >> -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op >> -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op >> -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op >> -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op >> >> +Benchmark ... > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > optimize width padding As you said above, this optimization has costs, including maintenance and fallback costs. I plan to optimize j.u.Formatter. however, the performance optimization on j.u.Formatter cannot achieve this optimization effect. The benefit of this optimization is that it approaches the performance of String.concat and hand-written StringBuilder, but exceeds them in ease of use based on String.format. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2207674846 From duke at openjdk.org Thu Jul 4 01:37:28 2024 From: duke at openjdk.org (lingjun-cg) Date: Thu, 4 Jul 2024 01:37:28 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v8] In-Reply-To: References: <9wfX11Q5vvdU34RirD2GmHPdi7zxb0SJe0PrgbdIMho=.438021fe-0e18-425a-b6b2-37ec554115bf@github.com> Message-ID: On Tue, 25 Jun 2024 19:33:02 GMT, Naoto Sato wrote: >> I did not mean to introduce a public API for this change (if we do, the fix cannot be backported). I thought we could define a package private one, but based on your observation, it may get messier... So I agree that falling back to `StringBuf` is the way to go, IMO. > >> So, considering all the information given, is it enough to start our new review process? @naotoj @liach @justin-curtis-lu > > Well, I was suggesting the same buffer proxying for other Format classes than NumberFormat subclasses, such as DateFormat so that they would have the same performance benefit. Would you be willing to do that too? Thanks all for your valuable suggestions. All suggestions were accepted. Is it enough to start our new review process? @naotoj @justin-curtis-lu @liach @irisclark ------------- PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2207831524 From hgreule at openjdk.org Thu Jul 4 06:22:31 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Thu, 4 Jul 2024 06:22:31 GMT Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception [v2] In-Reply-To: References: Message-ID: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com> > Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods. > > The exception message is less exact, but I think that's acceptable. Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20015/files - new: https://git.openjdk.org/jdk/pull/20015/files/fe43b749..e329ceb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20015&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20015&range=00-01 Stats: 43 lines in 2 files changed: 17 ins; 16 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/20015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20015/head:pull/20015 PR: https://git.openjdk.org/jdk/pull/20015 From jlu at openjdk.org Thu Jul 4 07:29:27 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 4 Jul 2024 07:29:27 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v16] In-Reply-To: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com> References: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com> Message-ID: On Tue, 2 Jul 2024 02:13:50 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Performance regression of DecimalFormat.format Thanks @lingjun-cg for your updates. I went through the newest version and the implementation changes look OK to me. It is a little easier to review without the intermediate StringBuilder method. It is a large change, so it is good there are multiple sets of eyes here. We will of course still need approval from a **Reviewer**. Something to note is that there is now some wording in the specification of some java.text.Format.* classes that is technically untrue. For example, in `Format.format(Object obj)`, it states the method is equivalent to calling `Format.format(obj, new StringBuffer(), new FieldPosition(0)).toString())`. It is not the biggest deal since it is just minor supplementary info and can probably simply be removed. However, this should be done as a separate issue, since we would like to backport the changes in this PR. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2158180263 From kevinw at openjdk.org Thu Jul 4 11:12:40 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 4 Jul 2024 11:12:40 GMT Subject: RFR: 8335684: ThreadCpuTime.java should pause like ThreadCpuTimeArray.java Message-ID: There are two similarly names tests. Recently: JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. Also removing an old comment about a Solaris issue. ------------- Commit messages: - 8335684: ThreadCpuTime.java should pause like ThreadCpuTimeArray.java Changes: https://git.openjdk.org/jdk/pull/20025/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335684 Stats: 12 lines in 1 file changed: 2 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20025/head:pull/20025 PR: https://git.openjdk.org/jdk/pull/20025 From liach at openjdk.org Thu Jul 4 11:51:19 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Jul 2024 11:51:19 GMT Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception [v2] In-Reply-To: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com> References: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com> Message-ID: On Thu, 4 Jul 2024 06:22:31 GMT, Hannes Greule wrote: >> Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods. >> >> The exception message is less exact, but I think that's acceptable. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > address comments Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20015#pullrequestreview-2158742384 From liach at openjdk.org Thu Jul 4 12:09:19 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Jul 2024 12:09:19 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v13] In-Reply-To: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com> Message-ID: <8wNdB7ts48FsMTrcXCoSy-t2de4F9aWMp-MedvDQ0Jk=.f8dcc125-fcb5-4e5d-abc6-bddd509c9db3@github.com> On Tue, 2 Jul 2024 14:04:52 GMT, Shaojin Wen wrote: >> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. >> >> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. >> >> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. >> >> Below is a comparison of String.format and concat-based and StringBuilder: >> >> * benchmark java code >> >> public class StringFormat { >> @Benchmark >> public String stringIntFormat() { >> return "%s %d".formatted(s, i); >> } >> >> @Benchmark >> public String stringIntConcat() { >> return s + " " + i; >> } >> >> @Benchmark >> public String stringIntStringBuilder() { >> return new StringBuilder(s).append(" ").append(i).toString(); >> } >> } >> >> >> * benchmark number on macbook m1 pro >> >> Benchmark Mode Cnt Score Error Units >> StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op >> StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op >> StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op >> >> >> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. >> >> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. >> >> d >> x >> X >> s >> >> If necessary, we can add a few more. >> >> >> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op >> -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op >> -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op >> -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op >> -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op >> -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op >> >> +Benchmark ... > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > optimize width padding As complex as this optimization may appear, I think we can probably consider breaking it into more maintainable parts: 1. Reducing appendable allocation if we just format to formatter once 2. Fast path for parsing 1 or 2-arg format strings 3. Fast writing if the format arguments are simple number or strings I think you might look at `Formatter::parse` internal factory: 1. We can probably do a `Formatter.parse` before we allocate formatter + appendable, and just pass the parsed result to the formatter to skip some pre-processing 2. If the parse result is 1 or 2 args, we can try to go through a new fast path if it is helpful 3. If the parse result knows what the resulting string will look like (length, and maybe coder; thus we need to change the result to like a record) we can ask StringBuilder to preallocate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2208803578 From nbenalla at openjdk.org Thu Jul 4 12:32:25 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 4 Jul 2024 12:32:25 GMT Subject: Integrated: 8332072: Convert package.html files in `java.naming` to package-info.java In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 17:26:52 GMT, Nizar Benalla wrote: > Can I please get a review for this small change? The motivation is that javac does not recognize `package.html` files. > > The conversion was simple, I used a script to rename the files, append "*" on the left and remove some HTML tags like `` and ``. I did the conversion in place, renaming them in git but with the big amount of change `git` thinks it's a new file. > > I also added a new `package-info.java` file to `javax.naming.ldap.spi`. I hope that's fine. This pull request has now been integrated. Changeset: 6a472797 Author: Nizar Benalla Committer: Aleksei Efimov URL: https://git.openjdk.org/jdk/commit/6a472797a410a6fa27f50371b255054af0cd3c99 Stats: 1431 lines in 11 files changed: 717 ins; 714 del; 0 mod 8332072: Convert package.html files in `java.naming` to package-info.java 8335213: Code snippet in javax.naming.ldap package summary does not compile Reviewed-by: aefimov ------------- PR: https://git.openjdk.org/jdk/pull/19529 From rgiulietti at openjdk.org Thu Jul 4 12:54:21 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 4 Jul 2024 12:54:21 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v9] In-Reply-To: References: Message-ID: <02Kd203NJHeXxPDJ6VVtKiq50iEa5GFqLKM0NhB_1Qc=.3259d5d3-8ca6-4208-af29-4afc10ff7367@github.com> On Thu, 27 Jun 2024 17:28:36 GMT, fabioromano1 wrote: >> Thanks. That's a very nice performance improvement, on my Windows machine the `testHuge...` test is about 2-3x faster, and the other 2 are slightly faster too. >> >> This needs a proper review for correctness, which might take a while. > > @djelinski I also improved the `BigDecimal.sqrt()` algorithm exploiting `BigInteger.sqrtAndRemainder()`. @fabioromano1 I'll review your contribution starting sometimes next week. Please stabilize your code until then. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2208903977 From duke at openjdk.org Thu Jul 4 13:37:23 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 4 Jul 2024 13:37:23 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v9] In-Reply-To: <02Kd203NJHeXxPDJ6VVtKiq50iEa5GFqLKM0NhB_1Qc=.3259d5d3-8ca6-4208-af29-4afc10ff7367@github.com> References: <02Kd203NJHeXxPDJ6VVtKiq50iEa5GFqLKM0NhB_1Qc=.3259d5d3-8ca6-4208-af29-4afc10ff7367@github.com> Message-ID: On Thu, 4 Jul 2024 12:51:47 GMT, Raffaello Giulietti wrote: >> @djelinski I also improved the `BigDecimal.sqrt()` algorithm exploiting `BigInteger.sqrtAndRemainder()`. > > @fabioromano1 I'll review your contribution starting sometimes next week. > Please stabilize your code until then. @rgiulietti I should have already finalized the last optimizations and adjustments, so I believe that the code will not undergo further changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2209007642 From duke at openjdk.org Thu Jul 4 14:27:21 2024 From: duke at openjdk.org (Vanitha B P) Date: Thu, 4 Jul 2024 14:27:21 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2] In-Reply-To: References: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> Message-ID: <5Hp7_eslxoS6HUlsUGu48zi5tnXsdX0CGMDZIb4Die8=.086ed703-0b98-4a7b-833a-22687e2b49e8@github.com> On Wed, 3 Jul 2024 16:45:51 GMT, Alexey Semenyuk wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> 8325525 Addressed review comments > > test/jdk/tools/jpackage/apps/ThirdPartyAppLauncher.java line 34: > >> 32: ProcessBuilder processBuilder = new ProcessBuilder("regedit"); >> 33: Process process = processBuilder.start(); >> 34: logger.info("RegEdit id=" + process.pid()); > > Logging is excessive and not applicable here as it can be redirected. The test shall print the PID to stdout. Sure, will print the PID using sysout ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1665785034 From duke at openjdk.org Thu Jul 4 14:31:20 2024 From: duke at openjdk.org (Vanitha B P) Date: Thu, 4 Jul 2024 14:31:20 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2] In-Reply-To: References: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> Message-ID: On Wed, 3 Jul 2024 16:47:02 GMT, Alexey Semenyuk wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> 8325525 Addressed review comments > > test/jdk/tools/jpackage/share/JpackageTest.java line 59: > >> 57: @Test >> 58: public static void test() throws Throwable { >> 59: JpackageTest test = new JpackageTest(); > > There is no need to explicitly call the ctor Sure, will remove the call to ctor ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1665789700 From nbenalla at openjdk.org Thu Jul 4 14:38:25 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 4 Jul 2024 14:38:25 GMT Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in java.base [v7] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 11:11:51 GMT, Nizar Benalla wrote: >> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix. >> This is related to #18934 and my work around the `@since` checker feature. >> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker. >> >> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N" >> >> Screenshot 2024-05-06 at 00 06 57 >> >> >> >> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended. >> >> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed. >> >> Screenshot 2024-05-06 at 00 07 16 >> >> Screenshot 2024-05-06 at 00 08 06 >> >> Screenshot 2024-05-06 at 00 09 03 >> >> >> TIA > > Nizar Benalla 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 14 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8330954 > - Add new line when having multi-line doc comment > - Merge remote-tracking branch 'upstream/master' into 8330954 > - Merge remote-tracking branch 'upstream/master' into 8330954 > - (C) > - (C) > - Move security classes changes to pr18373 > - remove couple extra lines > - Pull request is now only about `@since` tags, might add an other commit > - add one more `{inheritDoc}` to `CompletableFuture.state` > - ... and 4 more: https://git.openjdk.org/jdk/compare/f122d936...afca07bf Thank you Naoto for checking, and thanks Chen! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2209141939 From duke at openjdk.org Thu Jul 4 14:38:25 2024 From: duke at openjdk.org (duke) Date: Thu, 4 Jul 2024 14:38:25 GMT Subject: RFR: 8330954: since-checker - Fix remaining @ since tags in java.base [v7] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 11:11:51 GMT, Nizar Benalla wrote: >> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix. >> This is related to #18934 and my work around the `@since` checker feature. >> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker. >> >> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N" >> >> Screenshot 2024-05-06 at 00 06 57 >> >> >> >> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended. >> >> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed. >> >> Screenshot 2024-05-06 at 00 07 16 >> >> Screenshot 2024-05-06 at 00 08 06 >> >> Screenshot 2024-05-06 at 00 09 03 >> >> >> TIA > > Nizar Benalla 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 14 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8330954 > - Add new line when having multi-line doc comment > - Merge remote-tracking branch 'upstream/master' into 8330954 > - Merge remote-tracking branch 'upstream/master' into 8330954 > - (C) > - (C) > - Move security classes changes to pr18373 > - remove couple extra lines > - Pull request is now only about `@since` tags, might add an other commit > - add one more `{inheritDoc}` to `CompletableFuture.state` > - ... and 4 more: https://git.openjdk.org/jdk/compare/f122d936...afca07bf @nizarbenalla Your change (at version afca07bfc06b31c4b689cb9051cc114328b389a1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2209143098 From duke at openjdk.org Thu Jul 4 14:58:21 2024 From: duke at openjdk.org (Vanitha B P) Date: Thu, 4 Jul 2024 14:58:21 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v2] In-Reply-To: References: <-ngAAfAUmLM104B6tFomfV7oaD_tGGQGTMk040MEdg0=.a6c8a4d3-abcb-450e-bf97-34d8649c5054@github.com> Message-ID: On Wed, 3 Jul 2024 16:57:49 GMT, Alexey Semenyuk wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> 8325525 Addressed review comments > > test/jdk/tools/jpackage/share/JpackageTest.java line 79: > >> 77: // parse to get regedit PID >> 78: regeditPid = Long.parseLong(pidStr.split("=", 2)[1]); >> 79: logger.info("Regedit PID is " + regeditPid); > > We use `TKit.log()` for logging in jpackage tests. You can do `TKit.log("Regedit PID is " + regeditPid)` log(String) is not public in TKit; cannot be accessed from outside package ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1665819402 From sgehwolf at openjdk.org Thu Jul 4 15:45:20 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 4 Jul 2024 15:45:20 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 14:43:58 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges. >> >> I'm adding those tests in order to not regress another time. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1. >> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to JDK-8322420) >> - [x] GHA > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Fix comments > - 8333446: Add tests for hierarchical container support Gentle ping. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2209259086 From nbenalla at openjdk.org Thu Jul 4 15:47:27 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 4 Jul 2024 15:47:27 GMT Subject: Integrated: 8330954: since-checker - Fix remaining @ since tags in java.base In-Reply-To: References: Message-ID: On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla wrote: > Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix. > This is related to #18934 and my work around the `@since` checker feature. > Explicit `@since` tags are needed for some overriding methods for the purpose of the checker. > > I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N" > > Screenshot 2024-05-06 at 00 06 57 > > > > and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended. > > I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed. > > Screenshot 2024-05-06 at 00 07 16 > > Screenshot 2024-05-06 at 00 08 06 > > Screenshot 2024-05-06 at 00 09 03 > > > TIA This pull request has now been integrated. Changeset: f4fa35e2 Author: Nizar Benalla Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/f4fa35e28b9881729ac47c8518e758bba676fdec Stats: 71 lines in 12 files changed: 67 ins; 2 del; 2 mod 8330954: since-checker - Fix remaining @ since tags in java.base Reviewed-by: liach, naoto ------------- PR: https://git.openjdk.org/jdk/pull/18954 From nbenalla at openjdk.org Thu Jul 4 18:09:48 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 4 Jul 2024 18:09:48 GMT Subject: RFR: 8335727: since-checker: Add `@since` tags to ClassFile::transformClass and CodeBuilder Message-ID: Please review this simple doc only change. Some methods in ClassFile API were renamed recently as part of [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and need to have `@since 24`, as they are essentially new methods. Thanks! ------------- Commit messages: - add `@since` tags to ClassFile API Changes: https://git.openjdk.org/jdk/pull/20041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335727 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20041/head:pull/20041 PR: https://git.openjdk.org/jdk/pull/20041 From liach at openjdk.org Thu Jul 4 23:46:20 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Jul 2024 23:46:20 GMT Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API [v2] In-Reply-To: References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com> Message-ID: On Thu, 6 Jun 2024 18:48:58 GMT, Chen Liang wrote: >> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well. >> >> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info > - Remove redundant try-catch in getEnclosingMethod/Constructor > - Merge branch 'test/signature-error' into feature/new-generic-info > - Fix everything > - Fixxes > - Stage > - Stage new tests > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info > - ... and 6 more: https://git.openjdk.org/jdk/compare/2a37764e...19ee8797 Keep-alive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-2209644772 From liach at openjdk.org Thu Jul 4 23:50:18 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Jul 2024 23:50:18 GMT Subject: RFR: 8335727: since-checker: Add `@since` tags to ClassFile::transformClass and CodeBuilder In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote: > Please review this simple doc only change. > Some methods in ClassFile API were renamed recently as part of [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and need to have `@since 24`, as they are essentially new methods. > > Thanks! Forgot that renames are new additions too! I am too ignorant. ------------- Marked as reviewed by liach (Committer). PR Review: https://git.openjdk.org/jdk/pull/20041#pullrequestreview-2159569791 From nbenalla at openjdk.org Fri Jul 5 01:00:19 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 5 Jul 2024 01:00:19 GMT Subject: RFR: 8335727: since-checker: Add `@since` tags to ClassFile::transformClass and CodeBuilder In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote: > Please review this simple doc only change. > Some methods in ClassFile API were renamed recently as part of [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and need to have `@since 24`, as they are essentially new methods. > > Thanks! No worries! I noticed these by chance today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20041#issuecomment-2209713867 From duke at openjdk.org Fri Jul 5 03:26:33 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Jul 2024 03:26:33 GMT Subject: Withdrawn: 8324651: Compiler Implementation for Derived Record Creation (Preview) In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 10:24:51 GMT, Jan Lahoda wrote: > This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: > https://bugs.openjdk.org/browse/JDK-8328637 > > The patch is mostly straightforward, with two notable changes: > - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. > - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18509 From duke at openjdk.org Fri Jul 5 12:56:21 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 12:56:21 GMT Subject: Integrated: 8335645: j.u.Formatter#trailingZeros improved with String repeat In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote: > In JDK 21, StringBuilder added a repeat method, which can be used to improve j.u.Formatter#trailingZeros This pull request has now been integrated. Changeset: 194425d7 Author: Shaojin Wen Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/194425d7875ef42fce52516ed59c81ee97720399 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8335645: j.u.Formatter#trailingZeros improved with String repeat Reviewed-by: liach, jlu, naoto ------------- PR: https://git.openjdk.org/jdk/pull/20018 From aph at openjdk.org Fri Jul 5 13:36:42 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 5 Jul 2024 13:36:42 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter Message-ID: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> This patch expands the use of a hash table for secondary superclasses to the interpreter, C1, and runtime. It also adds a C2 implementation of hashed lookup in cases where the superclass isn't known at compile time. HotSpot shared runtime ---------------------- Building hashed secondary tables is now unconditional. It takes very little time, and now that the shared runtime always has the tables, it might as well take advantage of them. The shared code is easier to follow now, I think. There might be a performance issue with x86-64 in that we build HotSpot for a default x86-64 target that does not support popcount. This means that HotSpot C++ runtime on x86 always uses a software emulation for popcount, even though the vast majority of machines made for the past 20 years can do popcount in a single instruction. It wouldn't be terribly hard to do something about that. Having said that, the software popcount is really not bad. x86 --- x86 is rather tricky, because we still support `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as well as 32- and 64-bit ports. There's some further complication in that only `RCX` can be used as a shift count, so there's some register shuffling to do. All of this makes the logic in macroAssembler_x86.cpp rather gnarly, with multiple levels of conditionals at compile time and runtime. AArch64 ------- AArch64 is considerably more straightforward. We always have a popcount instruction and (thankfully) no 32-bit code to worry about. Generally --------- I would dearly love simply to rip out the "old" secondary supers cache support, but I've left it in just in case someone has a performance regression. The versions of `MacroAssembler::lookup_secondary_supers_table` that work with variable superclasses don't take a fixed set of temp registers, and neither do they call out to to a slow path subroutine. Instead, the slow patch is expanded inline. I don't think this is necessarily bad. Apart from the very rare cases where C2 can't determine the superclass to search for at compile time, this code is only used for generating stubs, and it seemed to me ridiculous to have stubs calling other stubs. I've followed the guidance from @iwanowww not to obsess too much about the performance of C1-compiled secondary supers lookups, and to prefer simplicity over absolute performance. Nonetheless, this is a complicated patch that touches many areas. ------------- Commit messages: - Cleanup tests - small - Small - Temp - Merge remote-tracking branch 'refs/remotes/origin/JDK-8331658-work' into JDK-8331658-work - Fix x86-32 - Fix x86 - Temp - Temp - Temp - ... and 16 more: https://git.openjdk.org/jdk/compare/747e1e47...7d7694cc Changes: https://git.openjdk.org/jdk/pull/19989/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331341 Stats: 886 lines in 13 files changed: 755 ins; 69 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From jvernee at openjdk.org Fri Jul 5 13:44:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 13:44:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee 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 29 additional commits since the last revision: - Merge branch 'master' into jnativescan - ofInvokeInstruction - use instance resolveAndBind + use junit in tests - de-dupe on path, not module name - Add support for module directories + class path directories - sort output for easier diffs - Jan comments - add extra test for missing root modules - review comments Alan - update man page header to be consisten with the others - ... and 19 more: https://git.openjdk.org/jdk/compare/a27659e6...1d1ff010 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/5afb3561..1d1ff010 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=10-11 Stats: 36188 lines in 816 files changed: 23655 ins; 8432 del; 4101 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774 From jvernee at openjdk.org Fri Jul 5 13:46:20 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 13:46:20 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 19:11:34 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 228: >> >>> 226: mtype = mt; >>> 227: } catch (TypeNotPresentException ex) { >>> 228: throw (ClassNotFoundException) ex.getCause(); >> >> On a side note, I wonder if it's better to re-wrap the exception here as a `ReflectiveOperationException`, instead of just getting the cause. That will retain the entire stack trace. > > @JornVernee Here are a few traces for comparison: https://gist.github.com/5d441ab2159833e808303d1accb66ee8 > > In all cases, the entire stacktrace is retained; this ClassNotFoundException has the `MethodTypeDescImpl::resolveConstantDesc` in its trace already. > > I believe directly unwrapping the `ClassNotFoundException` is the best: > 1. In future optimization, we can parse the individual classes more directly (such as via `ClassDesc.resolveConstantDesc`) and the new code can just throw the CNFE directly without extra wrapping, as user don't anticipate wrapped causes. > 2. `IllegalAccessException` throwing is done directly. > > Also, would you mind to review the associated CSR as well? Sorry, I've been out sick. Reviewed it now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1666827723 From pminborg at openjdk.org Fri Jul 5 14:01:59 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 5 Jul 2024 14:01:59 GMT Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only property [v4] In-Reply-To: References: Message-ID: > This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called. > > Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge master - Add read-only comment on asSegment too - Rework docs - Make reinterpret retain read-only state ------------- Changes: https://git.openjdk.org/jdk/pull/19629/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19629&range=03 Stats: 38 lines in 4 files changed: 30 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/19629.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19629/head:pull/19629 PR: https://git.openjdk.org/jdk/pull/19629 From jvernee at openjdk.org Fri Jul 5 14:14:12 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 14:14:12 GMT Subject: RFR: 8333884: MemorySegment::reinterpret removes read-only property [v4] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 14:01:59 GMT, Per Minborg wrote: >> This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called. >> >> Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge master > - Add read-only comment on asSegment too > - Rework docs > - Make reinterpret retain read-only state Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19629#pullrequestreview-2160796925 From liach at openjdk.org Fri Jul 5 14:22:57 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Jul 2024 14:22:57 GMT Subject: RFR: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:44:06 GMT, Jorn Vernee wrote: >> @JornVernee Here are a few traces for comparison: https://gist.github.com/5d441ab2159833e808303d1accb66ee8 >> >> In all cases, the entire stacktrace is retained; this ClassNotFoundException has the `MethodTypeDescImpl::resolveConstantDesc` in its trace already. >> >> I believe directly unwrapping the `ClassNotFoundException` is the best: >> 1. In future optimization, we can parse the individual classes more directly (such as via `ClassDesc.resolveConstantDesc`) and the new code can just throw the CNFE directly without extra wrapping, as user don't anticipate wrapped causes. >> 2. `IllegalAccessException` throwing is done directly. >> >> Also, would you mind to review the associated CSR as well? > > Sorry, I've been out sick. Reviewed it now Hope you get better soon! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19991#discussion_r1666867671 From jvernee at openjdk.org Fri Jul 5 14:27:37 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 14:27:37 GMT Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception [v2] In-Reply-To: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com> References: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com> Message-ID: On Thu, 4 Jul 2024 06:22:31 GMT, Hannes Greule wrote: >> Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods. >> >> The exception message is less exact, but I think that's acceptable. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > address comments I think this needs a CSR, to document the change in behavior. (See e.g. https://bugs.openjdk.org/browse/JDK-8335554 which is a very similar case) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20015#issuecomment-2210971780 From jvernee at openjdk.org Fri Jul 5 14:33:38 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 14:33:38 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee 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 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/33bfce23...1d1ff010 I'm running one more tier 1-3 job before integrating. Will need a final sign-off from a reviewer for that as well. (Either way, I'll save the integration until next week) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2210982590 From duke at openjdk.org Fri Jul 5 14:46:44 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:44 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory Message-ID: Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. cc: @AlanBateman ------------- Commit messages: - More tests - Restrict field set to those defined by serialPersistentFields - More tests and fixes - Add tests for static accessors - Missed one - Apply review feedback - Fix security manager permissions for test - Neaten if statement - Unused field - Move bytecode gen back to `jdk.internal.reflect`, use unprivileged lookup for class definition - ... and 18 more: https://git.openjdk.org/jdk/compare/d744059b...e7334655 Changes: https://git.openjdk.org/jdk/pull/19702/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333796 Stats: 1111 lines in 5 files changed: 1106 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19702.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702 PR: https://git.openjdk.org/jdk/pull/19702 From duke at openjdk.org Fri Jul 5 14:46:45 2024 From: duke at openjdk.org (ExE Boss) Date: Fri, 5 Jul 2024 14:46:45 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote: > Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. > > To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. > > It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. > > With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. > cc: @AlanBateman Since?[JDK?8331724], this?can?use the?implementation?classes in?`jdk.internal.constant` to?speed?up default?(de)serialization code?generation startup. [JDK?8331724]: https://bugs.openjdk.org/browse/JDK-8331724 Relevant?issue: - https://github.com/openjdk/jdk/pull/15364 src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 55: > 53: // build an anonymous+hidden nestmate to perform the read operation > 54: List setters = new ArrayList<>(); > 55: byte[] bytes = ClassFile.of().build(CD_Genearted_readObject, classBuilder -> classBuilder.withMethod("readObject", Suggestion: byte[] bytes = ClassFile.of().build(CD_Generated_readObject, classBuilder -> classBuilder.withMethod("readObject", src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 239: > 237: > 238: private static final ClassDesc CD_Generated_writeObject = ClassDesc.of("jdk.internal.reflect", "Generated$$writeObject"); > 239: private static final ClassDesc CD_Genearted_readObject = ClassDesc.of("jdk.internal.reflect", "Generated$$readObject"); It?might be?better to?use `ReferenceClassDescImpl?.ofValidated?(String)`?here, or?at?least `ClassDesc?.ofDescriptor?(String)` to?avoid?binary to?internal name?conversion: Suggestion: private static final ClassDesc CD_ObjectInputStream = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectInputStream;"); private static final ClassDesc CD_ObjectInputStream_GetField = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectInputStream$GetField;"); private static final ClassDesc CD_ObjectOutputStream = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectOutputStream;"); private static final ClassDesc CD_ObjectOutputStream_PutField = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectOutputStream$PutField;"); private static final ClassDesc CD_Generated_writeObject = ReferenceClassDescImpl.ofValidated("Ljdk/internal/reflect/Generated$$writeObject;"); private static final ClassDesc CD_Generated_readObject = ReferenceClassDescImpl.ofValidated("Ljdk/internal/reflect/Generated$$readObject;"); src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 263: > 261: private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_L = MethodTypeDesc.of(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_Object); > 262: private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_S = MethodTypeDesc.of(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_short); > 263: private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_Z = MethodTypeDesc.of(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_boolean); Using?`MethodTypeDescImpl?.ofTrusted(?)` or?at?least `MethodTypeDescImpl?.ofValidated(?)`?here avoids?array?copying: Suggestion: private static final MethodTypeDesc MTD_ObjectInputStream_readFields = MethodTypeDescImpl.ofValidated(CD_ObjectInputStream_GetField); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_B = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_byte, ConstantDescs.CD_String, ConstantDescs.CD_byte); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_C = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_char, ConstantDescs.CD_String, ConstantDescs.CD_char); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_D = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_double, ConstantDescs.CD_String, ConstantDescs.CD_double); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_F = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_float, ConstantDescs.CD_String, ConstantDescs.CD_float); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_I = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_int, ConstantDescs.CD_String, ConstantDescs.CD_int); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_J = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_long, ConstantDescs.CD_String, ConstantDescs.CD_long); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_L = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_Object, ConstantDescs.CD_String, ConstantDescs.CD_Object); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_S = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_short, ConstantDescs.CD_String, ConstantDescs.CD_short); private static final MethodTypeDesc MTD_ObjectInputStream_GetField_get_Z = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_boolean, ConstantDescs.CD_String, ConstantDescs.CD_boolean); private static final MethodTypeDesc MTD_ObjectOutputStream_putFields = MethodTypeDescImpl.ofValidated(CD_ObjectOutputStream_PutField); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_B = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_byte); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_C = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_char); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_D = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_double); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_F = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_float); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_I = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_int); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_J = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_long); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_L = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_Object); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_S = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_short); private static final MethodTypeDesc MTD_ObjectOutputStream_PutField_put_Z = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_void, ConstantDescs.CD_String, ConstantDescs.CD_boolean); ------------- PR Review: https://git.openjdk.org/jdk/pull/19702#pullrequestreview-2149053446 PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2175793616 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1659368798 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1659368645 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1659372351 From liach at openjdk.org Fri Jul 5 14:46:46 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Jul 2024 14:46:46 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: <8PYbkZVdgFhEI3zoHPq5y6MZjNpBjTz42yd1k0QZhrg=.c5352c55-079e-4c0e-a465-494ce95edad3@github.com> On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote: > Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. > > To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. > > It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. > > With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. > cc: @AlanBateman Great work out there! We might need to check if this will be compatible with Valhalla. Since this is an API addition, this will require a CSR; Valhalla folks can check if this API is future-proof in the CSR. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 441: > 439: } > 440: > 441: return SerializationBytecodeGenerator.defaultReadObjectForSerialization(cl); How likely is it for multiple libraries to request readObject for the same class? If it happens that many clients request factories for the same class, we can consider computing and leaving the MHs in a `ClassValue` instead (so the MHs can be GC'd when `cl` is unreachable, but are otherwise cached and shared) src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 464: > 462: } > 463: field.setAccessible(true); > 464: return (ObjectStreamField[]) field.get(null); Should we clone the array to prevent user modification? src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 488: > 486: } > 487: > 488: private static boolean isValidSerializable(Class cl) { Should we filter `Class`, `ObjectStreamClass`, and `String` (https://docs.oracle.com/en/java/javase/22/docs/specs/serialization/serial-arch.html#writing-to-an-object-stream) too? src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 53: > 51: > 52: static MethodHandle defaultReadObjectForSerialization(Class cl) { > 53: // build an anonymous+hidden nestmate to perform the read operation Maybe note that we generate erased types and use MH setters/getters because the generated bytecode is defined under the loader of SerializationBytecodeGenerator, which cannot access `cl`. Otherwise, the first thing coming to my mind is that we can just use direct field access and explicit `cl` type in the bytecode, or we are supporting hidden classes for `cl` so we have to stay erased (which is not the case here) src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 88: > 86: } > 87: cb.ldc(DynamicConstantDesc.ofNamed( > 88: ConstantDescs.BSM_CLASS_DATA_AT, One side remark: I think `classDataAt` is more useful for bootstrap method arguments, like `nullConstant`; in actual bytecode, `classData` + `List.get` invokeinterface should be more constant-pool friendly, as you just need one CP entry for the whole list as opposed to one CP entry for each list item. But either way, this is correct, and we only care about correctness in legacy support code. src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 100: > 98: ClassDesc fieldDesc = fieldType.describeConstable().orElseThrow(InternalError::new); > 99: > 100: switch (fieldDesc.descriptorString()) { If you just switch over primitives + reference, consider something like `switch (TypeKind.from(fieldType)) {` for simplicity. test/jdk/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java line 732: > 730: final String final_str; > 731: > 732: Ser2(final byte final_byte, final short final_short, final char final_char, final int final_int, I wonder if you can add a serializable user-defined class in the test; `String` is a reference but it's a primitive data type in serialization specification. ------------- PR Review: https://git.openjdk.org/jdk/pull/19702#pullrequestreview-2150436289 PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2200111311 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660484934 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660483713 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660490811 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660477343 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660482673 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660477372 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660493587 From duke at openjdk.org Fri Jul 5 14:46:46 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:46 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote: > Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. > > To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. > > It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. > > With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. > cc: @AlanBateman Oops, I forgot that `cc` is a Skara command. Sorry, bot. I've updated the PR with a new access control solution, but it's not ideal since it involves internal reflection. To solve this issue, unless I'm misunderstanding something, I think we would need to have access to `Lookup#IMPL_LOOKUP` from the method generators. The only way I can think to do this (without exposing the lookup from `JavaLangInvokeAccess`, which I assume would not be desirable) would be to move the generators into the `java.lang.invoke` package, adding methods to `JavaLangInvokeAccess` for that purpose. Would this be the recommended approach, or is there some other better approach that I do not see? I added a commit which moves the bytecode gen to the JLI package and accesses it via SharedSecrets, which is reasonably similar to what other methods in ReflectionFactory are already doing. Edit: Per Alan's feedback this was moved back again. See [the resolved discussion](https://github.com/openjdk/jdk/pull/19702#discussion_r1658837413) for details. > I skimmed through the latest update ([d137f43](https://github.com/openjdk/jdk/commit/d137f43b00e935e9fbcaeaa80fdff93a0a2df44b)) and I think you've got this to a good place and a sensible/workable proposal. I've asked from help from others on the security review of this. Great. There are a couple more tests I want to add but once that's done I'll mark it "Ready for review". > Right now, I'm still wonder if defaultReadObjectForSerialization/defaultWriteObjectForSerialization should return the same as readObjectForSerialization/writeObjectForSerialization when the readObject/writeObject methods are defined. This is more of a concern for a class with a readObject of course as that readObject will likely check invariants that would be bypassed if the serialization library always uses the defaultXXX methods. By spec, the `readObject` method must call either `OIS#defaultReadObject` or `OIS#readFields`, but they _are_ allowed to choose which one they call. If they call `defaultReadObject`, then the serialization library would still need `defaultReadObjectForSerialization` in order to implement it. If `defaultReadObjectForSerialization` falls back to calling the user `readObject`, we then would (at best) have a stack overflow situation, because the user's `readObject` would call `defaultReadObject`, which in turn would call back into the user's `readObject`, etc. So, in some cases, the (de)serializer can use only `readObjectForSerialization` (specifically, when there is a user `readObject` method which uses `readFields`); in other cases it can use only `defaultReadObjectForSerialization` (when the user didn't provide a `readObject`); and, in the final case, it would need to use both (when the user `readObject` calls `OIS#defaultReadObject`). The same thing applies on the write side. > I'd probably drop the "Of" suffix from serialPersistentFieldsOf and serialVersionUIDOf but naming isn't important right now. I'll do so. > /csr > > Since this is an API addition, this will require a CSR; Valhalla folks can check if this API is future-proof in the CSR. According to https://wiki.openjdk.org/display/csr/CSR+FAQs, only changes to public and exported APIs in the `jdk.*`, `java.*`, and `javax.*` packages need a CSR. This PR changes public and exported APIs in the `sun.misc` package, and changes public but non-exported APIs in the `jdk.internal.reflect` package, so I don't think it qualifies, does it? The CSR is [JDK-8335438](https://bugs.openjdk.org/browse/JDK-8335438). ------------- PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2165859586 PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2195182295 PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2195575503 PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2200005883 PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2200116881 PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2200604899 From alanb at openjdk.org Fri Jul 5 14:46:47 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: <4z7Uv78Pb5MBXrDlyKpslavdKaycMuEJy6u1oe8nboQ=.9a089a01-b85b-4896-b50b-553d6a433ff1@github.com> On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote: > Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. > > To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. > > It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. > > With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. > cc: @AlanBateman I skimmed through the latest update (d137f43) and I think you've got this to a good place and a sensible/workable proposal. I've asked from help from others on the security review of this. Right now, I'm still wonder if defaultReadObjectForSerialization/defaultWriteObjectForSerialization should return the same as readObjectForSerialization/writeObjectForSerialization when the readObject/writeObject methods are defined. This is more of a concern for a class with a readObject of course as that readObject will likely check invariants that would be bypassed if the serialization library always uses the defaultXXX methods. I'd probably drop the "Of" suffix from serialPersistentFieldsOf and serialVersionUIDOf but naming isn't important right now. src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java line 448: > 446: * @since 24 > 447: */ > 448: public static MethodHandle fieldSetterForSerialization(MethodHandles.Lookup lookup, String name, Class type, Class cl) { Is this left over from an earlier prototype? There shouldn't be any changes to the standard APIs in this proposal. src/java.base/share/classes/java/lang/invoke/SerializationBytecodeGenerator.java line 43: > 41: * The private serialization bytecode generator used by {@code sun.misc.ReflectionFactory}. > 42: */ > 43: final class SerializationBytecodeGenerator { I assume the starting point for the prototype should be a supporting class in jdk.internal.reflect rather than here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2198027291 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1656667254 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1658215233 From liach at openjdk.org Fri Jul 5 14:46:47 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 13:16:39 GMT, David M. Lloyd wrote: > According to https://wiki.openjdk.org/display/csr/CSR+FAQs, only changes to public and exported APIs in the `jdk.*`, `java.*`, and `javax.*` packages need a CSR. This PR changes public and exported APIs in the `sun.misc` package, and changes public but non-exported APIs in the `jdk.internal.reflect` package, so I don't think it qualifies, does it? CSR is required for changes to any public and exported API, including in `sun.misc` package, and including trivial signature changes (such as making a method default in an interface, or marking a utility class final). The presence of a CSR doesn't necessary mean a patch will be harder to integrate; it's often for archival and quality-ensurance purposes. Here's an example CSR for changes to APIs in `sun.misc`: https://bugs.openjdk.org/browse/JDK-8331686 (#19174) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2200140427 From duke at openjdk.org Fri Jul 5 14:46:47 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: <4z7Uv78Pb5MBXrDlyKpslavdKaycMuEJy6u1oe8nboQ=.9a089a01-b85b-4896-b50b-553d6a433ff1@github.com> References: <4z7Uv78Pb5MBXrDlyKpslavdKaycMuEJy6u1oe8nboQ=.9a089a01-b85b-4896-b50b-553d6a433ff1@github.com> Message-ID: On Thu, 27 Jun 2024 08:08:13 GMT, Alan Bateman wrote: >> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. >> >> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. >> >> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. >> >> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. >> cc: @AlanBateman > > src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java line 448: > >> 446: * @since 24 >> 447: */ >> 448: public static MethodHandle fieldSetterForSerialization(MethodHandles.Lookup lookup, String name, Class type, Class cl) { > > Is this left over from an earlier prototype? There shouldn't be any changes to the standard APIs in this proposal. I'll look into some alternatives. > src/java.base/share/classes/java/lang/invoke/SerializationBytecodeGenerator.java line 43: > >> 41: * The private serialization bytecode generator used by {@code sun.misc.ReflectionFactory}. >> 42: */ >> 43: final class SerializationBytecodeGenerator { > > I assume the starting point for the prototype should be a supporting class in jdk.internal.reflect rather than here. Indeed, if you look at the previous revision, that's how I implemented it. However, the generator currently needs access to `Lookup.IMPL_LOOKUP` in order to generate a nestmate class and accessors for private members on the class. If you look at the previous commit ([right here, for example](https://github.com/openjdk/jdk/compare/430b5d3b618154a66f03acf4d7a095c046a89687%5E..4e68264689bbbf8e5cf2876ac8dc80e4e7f44f6c#diff-c11ce0e1cedb25e3733a80cd7cb308506d63805ada55b4265252f653df123d88R584-R597)), you can see that I _was_ using reflection to grab this field, but that seems less than ideal (I couldn't find anywhere else in the JDK which does this). My next thought was to expose that lookup via `JavaLangInvokeAccess`, however looking at the history of this interface gave me an impression that this is explicitly undesirable. So my conclusion was that the safest option is to push the generator to the "other side" of the barrier and access the generators themselves via `JavaLangInvokeAccess`, along the lines of what `MethodHandles.Lookup.serializableConstructor` is doing (though in that case there is no code being generated). Another idea I had this morning was that perhaps I could avoid needing the private lookup at all, by using reflection with `setAccessible(true)` for every serializable field, and unreflecting the result to get getter/setter handles, which should bypass access checks. I'll give that a shot and see if it works, because in that case we don't need any JLI privileged stuff at all. It's a little more clunky than using getfield/putfield but maybe the benefits outweigh the difficulties. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1657096322 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1658720910 From duke at openjdk.org Fri Jul 5 14:46:47 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: <4z7Uv78Pb5MBXrDlyKpslavdKaycMuEJy6u1oe8nboQ=.9a089a01-b85b-4896-b50b-553d6a433ff1@github.com> Message-ID: On Fri, 28 Jun 2024 13:09:19 GMT, David M. Lloyd wrote: >> src/java.base/share/classes/java/lang/invoke/SerializationBytecodeGenerator.java line 43: >> >>> 41: * The private serialization bytecode generator used by {@code sun.misc.ReflectionFactory}. >>> 42: */ >>> 43: final class SerializationBytecodeGenerator { >> >> I assume the starting point for the prototype should be a supporting class in jdk.internal.reflect rather than here. > > Indeed, if you look at the previous revision, that's how I implemented it. However, the generator currently needs access to `Lookup.IMPL_LOOKUP` in order to generate a nestmate class and accessors for private members on the class. If you look at the previous commit ([right here, for example](https://github.com/openjdk/jdk/compare/430b5d3b618154a66f03acf4d7a095c046a89687%5E..4e68264689bbbf8e5cf2876ac8dc80e4e7f44f6c#diff-c11ce0e1cedb25e3733a80cd7cb308506d63805ada55b4265252f653df123d88R584-R597)), you can see that I _was_ using reflection to grab this field, but that seems less than ideal (I couldn't find anywhere else in the JDK which does this). > > My next thought was to expose that lookup via `JavaLangInvokeAccess`, however looking at the history of this interface gave me an impression that this is explicitly undesirable. So my conclusion was that the safest option is to push the generator to the "other side" of the barrier and access the generators themselves via `JavaLangInvokeAccess`, along the lines of what `MethodHandles.Lookup.serializableConstructor` is doing (though in that case there is no code being generated). > > Another idea I had this morning was that perhaps I could avoid needing the private lookup at all, by using reflection with `setAccessible(true)` for every serializable field, and unreflecting the result to get getter/setter handles, which should bypass access checks. I'll give that a shot and see if it works, because in that case we don't need any JLI privileged stuff at all. It's a little more clunky than using getfield/putfield but maybe the benefits outweigh the difficulties. Just adding for posterity that one case I did not consider with using an unprivileged lookup for the generated class is that the class being serialized isn't necessarily public, and this applies to the types of the fields of the class as well. This means adapting method handles to handle `Object`, which might internally involve more `checkcast` than the original solution. I'm still tinkering with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1658811216 From duke at openjdk.org Fri Jul 5 14:46:47 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: <4z7Uv78Pb5MBXrDlyKpslavdKaycMuEJy6u1oe8nboQ=.9a089a01-b85b-4896-b50b-553d6a433ff1@github.com> Message-ID: On Fri, 28 Jun 2024 14:04:13 GMT, David M. Lloyd wrote: >> Indeed, if you look at the previous revision, that's how I implemented it. However, the generator currently needs access to `Lookup.IMPL_LOOKUP` in order to generate a nestmate class and accessors for private members on the class. If you look at the previous commit ([right here, for example](https://github.com/openjdk/jdk/compare/430b5d3b618154a66f03acf4d7a095c046a89687%5E..4e68264689bbbf8e5cf2876ac8dc80e4e7f44f6c#diff-c11ce0e1cedb25e3733a80cd7cb308506d63805ada55b4265252f653df123d88R584-R597)), you can see that I _was_ using reflection to grab this field, but that seems less than ideal (I couldn't find anywhere else in the JDK which does this). >> >> My next thought was to expose that lookup via `JavaLangInvokeAccess`, however looking at the history of this interface gave me an impression that this is explicitly undesirable. So my conclusion was that the safest option is to push the generator to the "other side" of the barrier and access the generators themselves via `JavaLangInvokeAccess`, along the lines of what `MethodHandles.Lookup.serializableConstructor` is doing (though in that case there is no code being generated). >> >> Another idea I had this morning was that perhaps I could avoid needing the private lookup at all, by using reflection with `setAccessible(true)` for every serializable field, and unreflecting the result to get getter/setter handles, which should bypass access checks. I'll give that a shot and see if it works, because in that case we don't need any JLI privileged stuff at all. It's a little more clunky than using getfield/putfield but maybe the benefits outweigh the difficulties. > > Just adding for posterity that one case I did not consider with using an unprivileged lookup for the generated class is that the class being serialized isn't necessarily public, and this applies to the types of the fields of the class as well. This means adapting method handles to handle `Object`, which might internally involve more `checkcast` than the original solution. I'm still tinkering with it. Done; the generator is now able to use a non-privileged lookup to generate the accessor classes, and thus I moved it back to `jdk.internal.reflect`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1658837413 From duke at openjdk.org Fri Jul 5 14:46:47 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: <8PYbkZVdgFhEI3zoHPq5y6MZjNpBjTz42yd1k0QZhrg=.c5352c55-079e-4c0e-a465-494ce95edad3@github.com> References: <8PYbkZVdgFhEI3zoHPq5y6MZjNpBjTz42yd1k0QZhrg=.c5352c55-079e-4c0e-a465-494ce95edad3@github.com> Message-ID: On Mon, 1 Jul 2024 05:35:37 GMT, Chen Liang wrote: >> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. >> >> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. >> >> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. >> >> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. >> cc: @AlanBateman > > src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 441: > >> 439: } >> 440: >> 441: return SerializationBytecodeGenerator.defaultReadObjectForSerialization(cl); > > How likely is it for multiple libraries to request readObject for the same class? > > If it happens that many clients request factories for the same class, we can consider computing and leaving the MHs in a `ClassValue` instead (so the MHs can be GC'd when `cl` is unreachable, but are otherwise cached and shared) My hope is that the method handle would be more easily inlined when each one is a separate constant. I'd feel less confident that this would be the case if I indirected through `List`. I think it would also increase the size of the generated method as well, though I'm not sure if there actually is any practical consequence to this. Also, this was easier. ;-) > src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 464: > >> 462: } >> 463: field.setAccessible(true); >> 464: return (ObjectStreamField[]) field.get(null); > > Should we clone the array to prevent user modification? Sure, that's a good idea. > src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 488: > >> 486: } >> 487: >> 488: private static boolean isValidSerializable(Class cl) { > > Should we filter `Class`, `ObjectStreamClass`, and `String` (https://docs.oracle.com/en/java/javase/22/docs/specs/serialization/serial-arch.html#writing-to-an-object-stream) too? Hmm, good idea. > src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 53: > >> 51: >> 52: static MethodHandle defaultReadObjectForSerialization(Class cl) { >> 53: // build an anonymous+hidden nestmate to perform the read operation > > Maybe note that we generate erased types and use MH setters/getters because the generated bytecode is defined under the loader of SerializationBytecodeGenerator, which cannot access `cl`. Otherwise, the first thing coming to my mind is that we can just use direct field access and explicit `cl` type in the bytecode, or we are supporting hidden classes for `cl` so we have to stay erased (which is not the case here) I added a more detailed explanation. > src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 88: > >> 86: } >> 87: cb.ldc(DynamicConstantDesc.ofNamed( >> 88: ConstantDescs.BSM_CLASS_DATA_AT, > > One side remark: I think `classDataAt` is more useful for bootstrap method arguments, like `nullConstant`; in actual bytecode, `classData` + `List.get` invokeinterface should be more constant-pool friendly, as you just need one CP entry for the whole list as opposed to one CP entry for each list item. > > But either way, this is correct, and we only care about correctness in legacy support code. I accidentally replied in the wrong thread here: https://github.com/openjdk/jdk/pull/19702#discussion_r1661000439 > src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 100: > >> 98: ClassDesc fieldDesc = fieldType.describeConstable().orElseThrow(InternalError::new); >> 99: >> 100: switch (fieldDesc.descriptorString()) { > > If you just switch over primitives + reference, consider something like `switch (TypeKind.from(fieldType)) {` for simplicity. Ah, nice idea. This way we can be sure no case was missed. > test/jdk/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java line 732: > >> 730: final String final_str; >> 731: >> 732: Ser2(final byte final_byte, final short final_short, final char final_char, final int final_int, > > I wonder if you can add a serializable user-defined class in the test; `String` is a reference but it's a primitive data type in serialization specification. Sure. The test subclasses the `Object*Stream` classes so the special type handling never comes into play, but we can be clearer about it by using a different type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661000439 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660971581 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661000877 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661014468 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661020564 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660996224 PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661006149 From duke at openjdk.org Fri Jul 5 14:46:47 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: <8PYbkZVdgFhEI3zoHPq5y6MZjNpBjTz42yd1k0QZhrg=.c5352c55-079e-4c0e-a465-494ce95edad3@github.com> Message-ID: On Mon, 1 Jul 2024 12:46:18 GMT, David M. Lloyd wrote: >> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 441: >> >>> 439: } >>> 440: >>> 441: return SerializationBytecodeGenerator.defaultReadObjectForSerialization(cl); >> >> How likely is it for multiple libraries to request readObject for the same class? >> >> If it happens that many clients request factories for the same class, we can consider computing and leaving the MHs in a `ClassValue` instead (so the MHs can be GC'd when `cl` is unreachable, but are otherwise cached and shared) > > My hope is that the method handle would be more easily inlined when each one is a separate constant. I'd feel less confident that this would be the case if I indirected through `List`. I think it would also increase the size of the generated method as well, though I'm not sure if there actually is any practical consequence to this. > > Also, this was easier. ;-) Oh, this comment landed on the wrong spot for some reason. To respond to the actual post here, I figured that the serialization library is likely to perform this caching anyway, so adding another layer here would just put more burden on the GC for no gain. But I'm not strongly committed to that stance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661016516 From liach at openjdk.org Fri Jul 5 14:46:47 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: <8PYbkZVdgFhEI3zoHPq5y6MZjNpBjTz42yd1k0QZhrg=.c5352c55-079e-4c0e-a465-494ce95edad3@github.com> Message-ID: On Mon, 1 Jul 2024 12:58:16 GMT, David M. Lloyd wrote: >> My hope is that the method handle would be more easily inlined when each one is a separate constant. I'd feel less confident that this would be the case if I indirected through `List`. I think it would also increase the size of the generated method as well, though I'm not sure if there actually is any practical consequence to this. >> >> Also, this was easier. ;-) > > Oh, this comment landed on the wrong spot for some reason. To respond to the actual post here, I figured that the serialization library is likely to perform this caching anyway, so adding another layer here would just put more burden on the GC for no gain. But I'm not strongly committed to that stance. Makes sense. No point of caching this when `Class` isn't even caching `getRecordComponents()` or `getPermittedSubclasses()`. And yes, using classDataAt is easier in bytecode than adding another invokeinterface. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1661033583 From duke at openjdk.org Fri Jul 5 14:46:47 2024 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 5 Jul 2024 14:46:47 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 22:03:36 GMT, ExE Boss wrote: >> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. >> >> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. >> >> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. >> >> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. >> cc: @AlanBateman > > src/java.base/share/classes/jdk/internal/reflect/SerializationBytecodeGenerator.java line 239: > >> 237: >> 238: private static final ClassDesc CD_Generated_writeObject = ClassDesc.of("jdk.internal.reflect", "Generated$$writeObject"); >> 239: private static final ClassDesc CD_Genearted_readObject = ClassDesc.of("jdk.internal.reflect", "Generated$$readObject"); > > It?might be?better to?use `ReferenceClassDescImpl?.ofValidated?(String)`?here, or?at?least `ClassDesc?.ofDescriptor?(String)` to?avoid?binary to?internal name?conversion: > > Suggestion: > > private static final ClassDesc CD_ObjectInputStream = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectInputStream;"); > private static final ClassDesc CD_ObjectInputStream_GetField = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectInputStream$GetField;"); > > private static final ClassDesc CD_ObjectOutputStream = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectOutputStream;"); > private static final ClassDesc CD_ObjectOutputStream_PutField = ReferenceClassDescImpl.ofValidated("Ljava/io/ObjectOutputStream$PutField;"); > > private static final ClassDesc CD_Generated_writeObject = ReferenceClassDescImpl.ofValidated("Ljdk/internal/reflect/Generated$$writeObject;"); > private static final ClassDesc CD_Generated_readObject = ReferenceClassDescImpl.ofValidated("Ljdk/internal/reflect/Generated$$readObject;"); Good idea. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1660974461 From duke at openjdk.org Fri Jul 5 16:30:35 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 16:30:35 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v13] In-Reply-To: <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> <9CkX_juOjiGeyju_DxzM8DcDc2WU3K4F3r7Ov7ahoDs=.4babcc32-7731-452b-9b80-5d37cd36f2d5@github.com> Message-ID: On Tue, 2 Jul 2024 14:04:52 GMT, Shaojin Wen wrote: >> We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. >> >> This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. >> >> The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. >> >> Below is a comparison of String.format and concat-based and StringBuilder: >> >> * benchmark java code >> >> public class StringFormat { >> @Benchmark >> public String stringIntFormat() { >> return "%s %d".formatted(s, i); >> } >> >> @Benchmark >> public String stringIntConcat() { >> return s + " " + i; >> } >> >> @Benchmark >> public String stringIntStringBuilder() { >> return new StringBuilder(s).append(" ").append(i).toString(); >> } >> } >> >> >> * benchmark number on macbook m1 pro >> >> Benchmark Mode Cnt Score Error Units >> StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op >> StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op >> StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op >> >> >> From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. >> >> The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. >> >> d >> x >> X >> s >> >> If necessary, we can add a few more. >> >> >> Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op >> -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op >> -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op >> -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op >> -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op >> -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op >> >> +Benchmark ... > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > optimize width padding https://github.com/openjdk/jdk/pull/20055 I submitted a new PR to modify j.u.Formatter. There are also many changes. I hope to get your patient review. @RogerRiggs @liach @cl4es ------------- PR Comment: https://git.openjdk.org/jdk/pull/19956#issuecomment-2211143875 From jlu at openjdk.org Fri Jul 5 16:57:36 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Jul 2024 16:57:36 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v16] In-Reply-To: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com> References: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com> Message-ID: On Tue, 2 Jul 2024 02:13:50 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Performance regression of DecimalFormat.format Following up on my previous comment regarding the _untrue wording_. I no longer think we can just split the implementation and specification portion of this PR into two issues, since if we backport the implementation only, the specification would now be violated for the back-ported releases. We may have to just include the specification in this issue as well, (which will require a CSR and no longer means we can backport this change). ------------- Changes requested by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2161032118 From duke at openjdk.org Fri Jul 5 18:42:43 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 18:42:43 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format Message-ID: String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. Improved performance includes the following: ## 1. Write directly during the parse process to reduce object allocation. In the current Formatter implementation, some objects do not need to be allocated, such as: class Formatter { public Formatter format(Locale l, String format, Object ... args) { List fsa = parse(format); // ... } static List parse(String s) { ArrayList al = new ArrayList<>(); while (i < max) { int n = s.indexOf('%', i); if (n < 0) { // al.add(new FixedString(s, i, max)); } } } } In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. ## 2. Fast path print Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. ## 3. String.format directly calls j.u.Formatter String.format directly calls j.u.Formatter via SharedSecrets to improve performance ------------- Commit messages: - speed up j.u.Formatter & String.format Changes: https://git.openjdk.org/jdk/pull/20055/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335791 Stats: 710 lines in 6 files changed: 586 ins; 60 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/20055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055 PR: https://git.openjdk.org/jdk/pull/20055 From duke at openjdk.org Fri Jul 5 18:42:44 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 18:42:44 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 15:40:24 GMT, Shaojin Wen wrote: > String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. > > > Improved performance includes the following: > > ## 1. Write directly during the parse process to reduce object allocation. > > In the current Formatter implementation, some objects do not need to be allocated, such as: > > > class Formatter { > public Formatter format(Locale l, String format, Object ... args) { > List fsa = parse(format); > // ... > } > > static List parse(String s) { > ArrayList al = new ArrayList<>(); > > while (i < max) { > int n = s.indexOf('%', i); > if (n < 0) { > // > al.add(new FixedString(s, i, max)); > } > } > } > } > > In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. > > ## 2. Fast path print > Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. > > ## 3. String.format directly calls j.u.Formatter > String.format directly calls j.u.Formatter via SharedSecrets to improve performance The performance improvement in most scenarios is very significant. The performance of complexFormat/decimalFormat scenes has decreased because the inline root has changed. I have a solution and will submit it after this PR is completed. The content is these two commits: [split print decimal](https://github.com/wenshao/jdk/commit/e3a6fe17912b5c17901e1518e74c9ab9a7e0057f) [refactor parser](https://github.com/wenshao/jdk/commit/0cc63265062d1480bc31e9010f91e83bc7d911f3) Performance numbers under MacBook M1 Pro make test TEST="micro:java.lang.StringFormat" # baseline 982e3f0e14dd4e5d0d13c6c0fe49903a555f5f5e -Benchmark Mode Cnt Score Error Units -StringFormat.complexFormat avgt 15 944.745 ? 70.806 ns/op -StringFormat.decimalFormat avgt 15 285.709 ? 14.579 ns/op -StringFormat.intFormat avgt 15 60.176 ? 1.258 ns/op -StringFormat.intFormatUtf16 avgt 15 124.083 ? 3.547 ns/op -StringFormat.intHexFormat avgt 15 251.195 ? 68.026 ns/op -StringFormat.intHexFormatUtf16 avgt 15 126.030 ? 14.631 ns/op -StringFormat.intHexUFormat avgt 15 201.430 ? 7.106 ns/op -StringFormat.intHexUFormatUtf16 avgt 15 137.988 ? 13.681 ns/op -StringFormat.intIntFormat avgt 15 131.670 ? 6.723 ns/op -StringFormat.intIntFormatUtf16 avgt 15 127.279 ? 2.857 ns/op -StringFormat.intOctalFormat avgt 15 248.651 ? 67.083 ns/op -StringFormat.intOctalFormatUtf16 avgt 15 115.897 ? 2.131 ns/op -StringFormat.lineFormatUtf16 avgt 15 143.465 ? 12.187 ns/op -StringFormat.lineFormat avgt 15 59.753 ? 0.598 ns/op -StringFormat.stringFormat avgt 15 62.188 ? 2.317 ns/op -StringFormat.stringFormatUtf16 avgt 15 158.438 ? 8.377 ns/op -StringFormat.stringIntFormat avgt 15 123.869 ? 4.107 ns/op -StringFormat.stringIntFormatUtf16 avgt 15 173.503 ? 19.792 ns/op -StringFormat.stringIntHexFormat avgt 15 156.958 ? 6.641 ns/op -StringFormat.stringIntHexUFormat avgt 15 163.373 ? 9.474 ns/op -StringFormat.stringIntOctalFormat avgt 15 157.360 ? 6.569 ns/op -StringFormat.stringIntOctalFormatUtf16 avgt 15 147.697 ? 6.050 ns/op -StringFormat.stringIntRFormat avgt 15 137.308 ? 7.921 ns/op -StringFormat.stringIntRFormatUtf16 avgt 15 199.334 ? 6.728 ns/op -StringFormat.stringWidthIntFormat avgt 15 148.663 ? 3.549 ns/op -StringFormat.stringWidthIntFormatUtf16 avgt 15 138.486 ? 3.704 ns/op -StringFormat.widthStringFormat avgt 15 94.476 ? 21.884 ns/op -StringFormat.widthStringFormatUtf16 avgt 15 130.753 ? 3.555 ns/op -StringFormat.widthStringIntFormat avgt 15 153.143 ? 9.967 ns/op -StringFormat.widthStringIntFormatUtf16 avgt 15 162.539 ? 6.323 ns/op # current 5d866bf17d96bd0f0e4545d7eee5912eda2e3a94 +Benchmark Mode Cnt Score Error Units +StringFormat.complexFormat avgt 15 1008.713 ? 86.458 ns/op +StringFormat.decimalFormat avgt 15 386.167 ? 76.843 ns/op +StringFormat.intFormat avgt 15 19.628 ? 0.076 ns/op +StringFormat.intFormatUtf16 avgt 15 25.678 ? 0.224 ns/op +StringFormat.intHexFormat avgt 15 106.220 ? 31.809 ns/op +StringFormat.intHexFormatUtf16 avgt 15 104.698 ? 7.862 ns/op +StringFormat.intHexUFormat avgt 15 99.228 ? 5.523 ns/op +StringFormat.intHexUFormatUtf16 avgt 15 73.016 ? 5.311 ns/op +StringFormat.intIntFormat avgt 15 86.851 ? 3.479 ns/op +StringFormat.intIntFormatUtf16 avgt 15 88.352 ? 4.553 ns/op +StringFormat.intOctalFormat avgt 15 176.610 ? 38.408 ns/op +StringFormat.intOctalFormatUtf16 avgt 15 69.189 ? 1.362 ns/op +StringFormat.lineFormat avgt 15 20.554 ? 0.044 ns/op +StringFormat.lineFormatUtf16 avgt 15 45.253 ? 29.207 ns/op +StringFormat.stringFormat avgt 15 19.869 ? 0.073 ns/op +StringFormat.stringFormatUtf16 avgt 15 25.119 ? 0.065 ns/op +StringFormat.stringIntFormat avgt 15 87.287 ? 2.808 ns/op +StringFormat.stringIntFormatUtf16 avgt 15 76.377 ? 5.036 ns/op +StringFormat.stringIntHexFormat avgt 15 109.946 ? 53.831 ns/op +StringFormat.stringIntHexUFormat avgt 15 117.475 ? 55.030 ns/op +StringFormat.stringIntOctalFormat avgt 15 109.248 ? 5.347 ns/op +StringFormat.stringIntOctalFormatUtf16 avgt 15 167.115 ? 25.219 ns/op +StringFormat.stringIntRFormat avgt 15 95.606 ? 8.299 ns/op +StringFormat.stringIntRFormatUtf16 avgt 15 92.061 ? 17.822 ns/op +StringFormat.stringWidthIntFormat avgt 15 91.130 ? 5.954 ns/op +StringFormat.stringWidthIntFormatUtf16 avgt 15 101.798 ? 7.317 ns/op +StringFormat.widthStringFormat avgt 15 20.644 ? 0.344 ns/op +StringFormat.widthStringFormatUtf16 avgt 15 26.111 ? 0.228 ns/op +StringFormat.widthStringIntFormat avgt 15 79.138 ? 24.128 ns/op +StringFormat.widthStringIntFormatUtf16 avgt 15 54.597 ? 1.191 ns/op | | baseline | current | delta | | --- | --- | --- | --- | | StringFormat.complexFormat | 944.745 | 1008.713 | -6.34% | | StringFormat.decimalFormat | 285.709 | 386.167 | -26.01% | | StringFormat.intFormat | 60.176 | 19.628 | 206.58% | | StringFormat.intFormatUtf16 | 124.083 | 25.678 | 383.23% | | StringFormat.intHexFormat | 251.195 | 106.220 | 136.49% | | StringFormat.intHexFormatUtf16 | 126.030 | 104.698 | 20.37% | | StringFormat.intHexUFormat | 201.430 | 99.228 | 103.00% | | StringFormat.intHexUFormatUtf16 | 137.988 | 73.016 | 88.98% | | StringFormat.intIntFormat | 131.670 | 86.851 | 51.60% | | StringFormat.intIntFormatUtf16 | 127.279 | 88.352 | 44.06% | | StringFormat.intOctalFormat | 248.651 | 176.610 | 40.79% | | StringFormat.intOctalFormatUtf16 | 115.897 | 69.189 | 67.51% | | StringFormat.lineFormatUtf16 | 143.465 | 45.253 | 217.03% | | StringFormat.lineFormat | 59.753 | 20.554 | 190.71% | | StringFormat.stringFormat | 62.188 | 19.869 | 212.99% | | StringFormat.stringFormatUtf16 | 158.438 | 25.119 | 530.75% | | StringFormat.stringIntFormat | 123.869 | 87.287 | 41.91% | | StringFormat.stringIntFormatUtf16 | 173.503 | 76.377 | 127.17% | | StringFormat.stringIntHexFormat | 156.958 | 109.946 | 42.76% | | StringFormat.stringIntHexUFormat | 163.373 | 117.475 | 39.07% | | StringFormat.stringIntOctalFormat | 157.360 | 109.248 | 44.04% | | StringFormat.stringIntOctalFormatUtf16 | 147.697 | 167.115 | -11.62% | | StringFormat.stringIntRFormat | 137.308 | 95.606 | 43.62% | | StringFormat.stringIntRFormatUtf16 | 199.334 | 92.061 | 116.52% | | StringFormat.stringWidthIntFormat | 148.663 | 91.130 | 63.13% | | StringFormat.stringWidthIntFormatUtf16 | 138.486 | 101.798 | 36.04% | | StringFormat.widthStringFormat | 94.476 | 20.644 | 357.64% | | StringFormat.widthStringFormatUtf16 | 130.753 | 26.111 | 400.76% | | StringFormat.widthStringIntFormat | 153.143 | 79.138 | 93.51% | | StringFormat.widthStringIntFormatUtf16 | 162.539 | 54.597 | 197.71% | ------------- PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211096061 From liach at openjdk.org Fri Jul 5 19:31:41 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Jul 2024 19:31:41 GMT Subject: RFR: 8261400: Reflection member filtering registration might be flawed Message-ID: Please review this patch that address the reflection member filtering flaws. 1. Remove a pointless bootstrap check to ensure no filter is accidentally bypassed due to class-loading order. 2. Clarify the scenarios for filtering, and the correct filter actions for each scenario. 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways to steal this instance, bypassing the filtered getter. The `jdk.internal.misc.Unsafe`'s filter was already removed in JDK-8161129, so this filter is meaningless. ------------- Commit messages: - Simplify comments - Merge branch 'master' of https://github.com/openjdk/jdk into fix/reflection-filter - Merge branch 'master' of https://github.com/openjdk/jdk into fix/reflection-filter - Minor refinement, future-proof comments - 8261400: Reflection member filtering registration might be flawed Changes: https://git.openjdk.org/jdk/pull/20058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8261400 Stats: 38 lines in 4 files changed: 16 ins; 14 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20058/head:pull/20058 PR: https://git.openjdk.org/jdk/pull/20058 From liach at openjdk.org Fri Jul 5 20:00:36 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Jul 2024 20:00:36 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 15:40:24 GMT, Shaojin Wen wrote: > String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. > > > Improved performance includes the following: > > ## 1. Write directly during the parse process to reduce object allocation. > > In the current Formatter implementation, some objects do not need to be allocated, such as: > > > class Formatter { > public Formatter format(Locale l, String format, Object ... args) { > List fsa = parse(format); > // ... > } > > static List parse(String s) { > ArrayList al = new ArrayList<>(); > > while (i < max) { > int n = s.indexOf('%', i); > if (n < 0) { > // > al.add(new FixedString(s, i, max)); > } > } > } > } > > In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. > > ## 2. Fast path print > Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. > > ## 3. String.format directly calls j.u.Formatter > String.format directly calls j.u.Formatter via SharedSecrets to improve performance src/java.base/share/classes/java/lang/String.java line 4548: > 4546: } > 4547: > 4548: private static class StringFormat { Since we want to avoid new classes on startup, we should change the lazy initialization pattern to: private static @Stable JavaUtilFormatterAccess jufa; private static JavaUtilFormatterAccess formatterAccess() { var access = jufa; if (access = null) { // We can assert not null on the getJUFA result return jufa = SharedSecrets.getJavaUtilFormatterAccess(); } return access; } using benign race. src/java.base/share/classes/java/util/Formatter.java line 3107: > 3105: if (fmt.locale() != l) > 3106: fmt = new Formatter(fmt.out(), l); > 3107: ((Formattable)arg).formatTo(fmt, Flags.NONE, -1, -1); You can use pattern matching for instanceof to avoid a cast here. src/java.base/share/classes/java/util/Formatter.java line 5260: > 5258: } > 5259: > 5260: static final FormatString[] specifiers = new FormatString[128]; Suggestion: static final @Stable FormatString[] specifiers = new FormatString[128]; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667064117 PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667087769 PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667091143 From duke at openjdk.org Fri Jul 5 20:30:50 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 20:30:50 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v2] In-Reply-To: References: Message-ID: > String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. > > > Improved performance includes the following: > > ## 1. Write directly during the parse process to reduce object allocation. > > In the current Formatter implementation, some objects do not need to be allocated, such as: > > > class Formatter { > public Formatter format(Locale l, String format, Object ... args) { > List fsa = parse(format); > // ... > } > > static List parse(String s) { > ArrayList al = new ArrayList<>(); > > while (i < max) { > int n = s.indexOf('%', i); > if (n < 0) { > // > al.add(new FixedString(s, i, max)); > } > } > } > } > > In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. > > ## 2. Fast path print > Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. > > ## 3. String.format directly calls j.u.Formatter > String.format directly calls j.u.Formatter via SharedSecrets to improve performance Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision: - use unknownFormatConversion method construct UnknownFormatConversionException - uppercase static final field name & code format - add stable annotation - replace cast to pattern matching ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20055/files - new: https://git.openjdk.org/jdk/pull/20055/files/982e3f0e..27ff0b5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=00-01 Stats: 26 lines in 1 file changed: 1 ins; 5 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/20055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055 PR: https://git.openjdk.org/jdk/pull/20055 From duke at openjdk.org Fri Jul 5 20:36:33 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 20:36:33 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v2] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 18:56:58 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision: >> >> - use unknownFormatConversion method construct UnknownFormatConversionException >> - uppercase static final field name & code format >> - add stable annotation >> - replace cast to pattern matching > > src/java.base/share/classes/java/lang/String.java line 4548: > >> 4546: } >> 4547: >> 4548: private static class StringFormat { > > Since we want to avoid new classes on startup, we should change the lazy initialization pattern to: > > > private static @Stable JavaUtilFormatterAccess jufa; > private static JavaUtilFormatterAccess formatterAccess() { > var access = jufa; > if (access = null) { > // We can assert not null on the getJUFA result > return jufa = SharedSecrets.getJavaUtilFormatterAccess(); > } > return access; > } > > using benign race. I found out through `-verbose:class` that StringFormat is not in the class loaded by startup ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20055#discussion_r1667120045 From duke at openjdk.org Fri Jul 5 20:43:51 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 20:43:51 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v3] In-Reply-To: References: Message-ID: > String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. > > > Improved performance includes the following: > > ## 1. Write directly during the parse process to reduce object allocation. > > In the current Formatter implementation, some objects do not need to be allocated, such as: > > > class Formatter { > public Formatter format(Locale l, String format, Object ... args) { > List fsa = parse(format); > // ... > } > > static List parse(String s) { > ArrayList al = new ArrayList<>(); > > while (i < max) { > int n = s.indexOf('%', i); > if (n < 0) { > // > al.add(new FixedString(s, i, max)); > } > } > } > } > > In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. > > ## 2. Fast path print > Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. > > ## 3. String.format directly calls j.u.Formatter > String.format directly calls j.u.Formatter via SharedSecrets to improve performance Shaojin Wen 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: - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407 - use unknownFormatConversion method construct UnknownFormatConversionException - uppercase static final field name & code format - add stable annotation - replace cast to pattern matching - speed up j.u.Formatter & String.format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20055/files - new: https://git.openjdk.org/jdk/pull/20055/files/27ff0b5d..b2f517ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=01-02 Stats: 8510 lines in 385 files changed: 5009 ins; 1904 del; 1597 mod Patch: https://git.openjdk.org/jdk/pull/20055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055 PR: https://git.openjdk.org/jdk/pull/20055 From liach at openjdk.org Fri Jul 5 20:48:33 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Jul 2024 20:48:33 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v3] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen wrote: >> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. >> >> >> Improved performance includes the following: >> >> ## 1. Write directly during the parse process to reduce object allocation. >> >> In the current Formatter implementation, some objects do not need to be allocated, such as: >> >> >> class Formatter { >> public Formatter format(Locale l, String format, Object ... args) { >> List fsa = parse(format); >> // ... >> } >> >> static List parse(String s) { >> ArrayList al = new ArrayList<>(); >> >> while (i < max) { >> int n = s.indexOf('%', i); >> if (n < 0) { >> // >> al.add(new FixedString(s, i, max)); >> } >> } >> } >> } >> >> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. >> >> ## 2. Fast path print >> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. >> >> ## 3. String.format directly calls j.u.Formatter >> String.format directly calls j.u.Formatter via SharedSecrets to improve performance > > Shaojin Wen 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: > > - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407 > - use unknownFormatConversion method construct UnknownFormatConversionException > - uppercase static final field name & code format > - add stable annotation > - replace cast to pattern matching > - speed up j.u.Formatter & String.format About `decimalFormat` performance drop: can you add the `@CompilerControl(CompilerControl.Mode.DONT_INLINE)` annotation on the benchmark class (or the methods), and show the performance results before and after? You can run the test selection as `StringFormat.(complex|decimal)Format` to just run the 2 tests with regressions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211394922 From sspitsyn at openjdk.org Fri Jul 5 20:49:33 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 5 Jul 2024 20:49:33 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote: > There are two similarly names tests. > Recently: > JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range > ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. > > Also removing an old comment about a Solaris issue. Okay to me. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20025#pullrequestreview-2161247996 From duke at openjdk.org Fri Jul 5 22:02:38 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 22:02:38 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v3] In-Reply-To: References: Message-ID: <3qXcv6JoJCBL75nvQVcKTzV3X9Uf_VAMVIvOPq3Y324=.47298c9c-ccd8-43f1-86df-76414bd596a0@github.com> On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen wrote: >> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. >> >> >> Improved performance includes the following: >> >> ## 1. Write directly during the parse process to reduce object allocation. >> >> In the current Formatter implementation, some objects do not need to be allocated, such as: >> >> >> class Formatter { >> public Formatter format(Locale l, String format, Object ... args) { >> List fsa = parse(format); >> // ... >> } >> >> static List parse(String s) { >> ArrayList al = new ArrayList<>(); >> >> while (i < max) { >> int n = s.indexOf('%', i); >> if (n < 0) { >> // >> al.add(new FixedString(s, i, max)); >> } >> } >> } >> } >> >> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. >> >> ## 2. Fast path print >> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. >> >> ## 3. String.format directly calls j.u.Formatter >> String.format directly calls j.u.Formatter via SharedSecrets to improve performance > > Shaojin Wen 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: > > - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407 > - use unknownFormatConversion method construct UnknownFormatConversionException > - uppercase static final field name & code format > - add stable annotation > - replace cast to pattern matching > - speed up j.u.Formatter & String.format The performance of the current version of decimalFormat is sometimes fast and sometimes slow. I don't know why. make test TEST="micro:java.lang.StringFormat.decimalFormat" # Benchmark: org.openjdk.bench.java.lang.StringFormat.decimalFormat # Run progress: 0.00% complete, ETA 00:00:30 # Fork: 1 of 3 # Warmup Iteration 1: 438.502 ns/op # Warmup Iteration 2: 473.917 ns/op # Warmup Iteration 3: 468.569 ns/op # Warmup Iteration 4: 411.787 ns/op # Warmup Iteration 5: 417.982 ns/op Iteration 1: 436.206 ns/op Iteration 2: 422.356 ns/op Iteration 3: 462.962 ns/op Iteration 4: 408.021 ns/op Iteration 5: 452.836 ns/op # Run progress: 33.33% complete, ETA 00:00:22 # Fork: 2 of 3 # Warmup Iteration 1: 256.982 ns/op # Warmup Iteration 2: 358.474 ns/op # Warmup Iteration 3: 345.280 ns/op # Warmup Iteration 4: 332.602 ns/op # Warmup Iteration 5: 511.648 ns/op Iteration 1: 478.953 ns/op Iteration 2: 328.587 ns/op Iteration 3: 195.851 ns/op Iteration 4: 223.552 ns/op Iteration 5: 228.569 ns/op # Run progress: 66.67% complete, ETA 00:00:10 # Fork: 3 of 3 # Warmup Iteration 1: 446.023 ns/op # Warmup Iteration 2: 360.855 ns/op # Warmup Iteration 3: 540.793 ns/op # Warmup Iteration 4: 537.336 ns/op # Warmup Iteration 5: 248.511 ns/op Iteration 1: 525.644 ns/op Iteration 2: 463.829 ns/op Iteration 3: 603.220 ns/op Iteration 4: 248.151 ns/op Iteration 5: 579.492 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211455189 From duke at openjdk.org Fri Jul 5 23:11:41 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 5 Jul 2024 23:11:41 GMT Subject: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum Message-ID: The current HexFormat defines an Enum to represent LowerCase and UpperCase class HexFormat { private enum Case { LOWERCASE, UPPERCASE } } This will cause the JVM to load one more class when it starts, which can be seen as follows public class Startup { public static void main(String[] args) {} } java -verbose:class Startup [0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit. ------------- Commit messages: - enum replaced by boolean, Reduce the number of classes loaded by startup Changes: https://git.openjdk.org/jdk/pull/20060/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20060&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335802 Stats: 24 lines in 1 file changed: 0 ins; 6 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/20060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20060/head:pull/20060 PR: https://git.openjdk.org/jdk/pull/20060 From duke at openjdk.org Sat Jul 6 00:15:04 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 6 Jul 2024 00:15:04 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v4] In-Reply-To: References: Message-ID: > String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. > > > Improved performance includes the following: > > ## 1. Write directly during the parse process to reduce object allocation. > > In the current Formatter implementation, some objects do not need to be allocated, such as: > > > class Formatter { > public Formatter format(Locale l, String format, Object ... args) { > List fsa = parse(format); > // ... > } > > static List parse(String s) { > ArrayList al = new ArrayList<>(); > > while (i < max) { > int n = s.indexOf('%', i); > if (n < 0) { > // > al.add(new FixedString(s, i, max)); > } > } > } > } > > In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. > > ## 2. Fast path print > Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. > > ## 3. String.format directly calls j.u.Formatter > String.format directly calls j.u.Formatter via SharedSecrets to improve performance Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Implementing JavaUtilFormatterAccess using anonymous class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20055/files - new: https://git.openjdk.org/jdk/pull/20055/files/b2f517ba..129d7eba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=02-03 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055 PR: https://git.openjdk.org/jdk/pull/20055 From duke at openjdk.org Sat Jul 6 00:54:35 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 6 Jul 2024 00:54:35 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v4] In-Reply-To: References: Message-ID: <4yj2y5WSZQOgMeBWIKAwfALpmHeE_AldK0HUGw86_Yg=.0500f80e-5bba-4c82-8904-6111f8fe88c9@github.com> On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen wrote: >> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. >> >> >> Improved performance includes the following: >> >> ## 1. Write directly during the parse process to reduce object allocation. >> >> In the current Formatter implementation, some objects do not need to be allocated, such as: >> >> >> class Formatter { >> public Formatter format(Locale l, String format, Object ... args) { >> List fsa = parse(format); >> // ... >> } >> >> static List parse(String s) { >> ArrayList al = new ArrayList<>(); >> >> while (i < max) { >> int n = s.indexOf('%', i); >> if (n < 0) { >> // >> al.add(new FixedString(s, i, max)); >> } >> } >> } >> } >> >> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. >> >> ## 2. Fast path print >> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. >> >> ## 3. String.format directly calls j.u.Formatter >> String.format directly calls j.u.Formatter via SharedSecrets to improve performance > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Implementing JavaUtilFormatterAccess using anonymous class The performance degradation of decimalFormat only occurred on the MacBook M1, and it did not occur when I tested it on the cloud host. ## [Aliyun ecs.c8a](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8a) * CPU AMD EPYCTM Genoa * Platform x64 # baseline b83766e59063a41ea8801ac9e7c15dce67727c62 -Benchmark Mode Cnt Score Error Units -StringFormat.complexFormat avgt 15 590.667 ? 17.059 ns/op -StringFormat.decimalFormat avgt 15 293.412 ? 2.359 ns/op -StringFormat.intFormat avgt 15 66.778 ? 0.865 ns/op -StringFormat.intFormatUtf16 avgt 15 69.233 ? 0.090 ns/op -StringFormat.intHexFormat avgt 15 116.871 ? 0.783 ns/op -StringFormat.intHexFormatUtf16 avgt 15 130.486 ? 0.749 ns/op -StringFormat.intHexUFormat avgt 15 122.547 ? 0.952 ns/op -StringFormat.intHexUFormatUtf16 avgt 15 133.570 ? 2.035 ns/op -StringFormat.intIntFormat avgt 15 118.463 ? 2.773 ns/op -StringFormat.intIntFormatUtf16 avgt 15 120.305 ? 0.973 ns/op -StringFormat.intOctalFormat avgt 15 117.049 ? 1.190 ns/op -StringFormat.intOctalFormatUtf16 avgt 15 131.041 ? 2.719 ns/op -StringFormat.lineFormat avgt 15 46.440 ? 0.355 ns/op -StringFormat.lineFormatUtf16 avgt 15 51.169 ? 0.308 ns/op -StringFormat.stringFormat avgt 15 50.507 ? 1.189 ns/op -StringFormat.stringFormatUtf16 avgt 15 54.684 ? 0.136 ns/op -StringFormat.stringIntFormat avgt 15 107.311 ? 0.719 ns/op -StringFormat.stringIntFormatUtf16 avgt 15 115.677 ? 2.801 ns/op -StringFormat.stringIntHexFormat avgt 15 103.388 ? 0.585 ns/op -StringFormat.stringIntHexUFormat avgt 15 103.773 ? 0.215 ns/op -StringFormat.stringIntOctalFormat avgt 15 103.900 ? 0.931 ns/op -StringFormat.stringIntOctalFormatUtf16 avgt 15 116.362 ? 1.118 ns/op -StringFormat.stringIntRFormat avgt 15 127.924 ? 0.122 ns/op -StringFormat.stringIntRFormatUtf16 avgt 15 142.177 ? 3.507 ns/op -StringFormat.stringWidthIntFormat avgt 15 142.864 ? 2.229 ns/op -StringFormat.stringWidthIntFormatUtf16 avgt 15 141.588 ? 0.745 ns/op -StringFormat.widthStringFormat avgt 15 62.167 ? 0.439 ns/op -StringFormat.widthStringFormatUtf16 avgt 15 67.403 ? 0.804 ns/op -StringFormat.widthStringIntFormat avgt 15 136.524 ? 0.521 ns/op -StringFormat.widthStringIntFormatUtf16 avgt 15 138.060 ? 2.828 ns/op # current b2f517ba459c55b2d69fe5a43723d15370cdab4b +Benchmark Mode Cnt Score Error Units +StringFormat.complexFormat avgt 15 412.950 ? 26.777 ns/op +StringFormat.decimalFormat avgt 15 260.532 ? 2.942 ns/op +StringFormat.intFormat avgt 15 24.184 ? 1.125 ns/op +StringFormat.intFormatUtf16 avgt 15 27.183 ? 0.151 ns/op +StringFormat.intHexFormat avgt 15 55.386 ? 0.344 ns/op +StringFormat.intHexFormatUtf16 avgt 15 70.344 ? 1.067 ns/op +StringFormat.intHexUFormat avgt 15 61.599 ? 2.133 ns/op +StringFormat.intHexUFormatUtf16 avgt 15 80.965 ? 6.596 ns/op +StringFormat.intIntFormat avgt 15 53.510 ? 0.804 ns/op +StringFormat.intIntFormatUtf16 avgt 15 53.795 ? 0.289 ns/op +StringFormat.intOctalFormat avgt 15 65.075 ? 0.526 ns/op +StringFormat.intOctalFormatUtf16 avgt 15 79.609 ? 2.225 ns/op +StringFormat.lineFormat avgt 15 24.306 ? 0.061 ns/op +StringFormat.lineFormatUtf16 avgt 15 28.136 ? 0.133 ns/op +StringFormat.stringFormat avgt 15 24.137 ? 0.159 ns/op +StringFormat.stringFormatUtf16 avgt 15 28.368 ? 0.065 ns/op +StringFormat.stringIntFormat avgt 15 50.953 ? 0.121 ns/op +StringFormat.stringIntFormatUtf16 avgt 15 62.363 ? 0.501 ns/op +StringFormat.stringIntHexFormat avgt 15 59.528 ? 0.199 ns/op +StringFormat.stringIntHexUFormat avgt 15 58.935 ? 0.515 ns/op +StringFormat.stringIntOctalFormat avgt 15 68.614 ? 0.140 ns/op +StringFormat.stringIntOctalFormatUtf16 avgt 15 80.326 ? 1.014 ns/op +StringFormat.stringIntRFormat avgt 15 60.547 ? 0.743 ns/op +StringFormat.stringIntRFormatUtf16 avgt 15 76.189 ? 3.493 ns/op +StringFormat.stringWidthIntFormat avgt 15 57.070 ? 0.616 ns/op +StringFormat.stringWidthIntFormatUtf16 avgt 15 68.253 ? 0.288 ns/op +StringFormat.widthStringFormat avgt 15 24.473 ? 0.251 ns/op +StringFormat.widthStringFormatUtf16 avgt 15 29.436 ? 0.050 ns/op +StringFormat.widthStringIntFormat avgt 15 57.610 ? 0.535 ns/op +StringFormat.widthStringIntFormatUtf16 avgt 15 65.597 ? 1.587 ns/op | | baseline | current | delta | | --- | --- | --- | --- | | StringFormat.complexFormat | 590.667 | 412.950 | 43.04% | | StringFormat.decimalFormat | 293.412 | 260.532 | 12.62% | | StringFormat.intFormat | 66.778 | 24.184 | 176.12% | | StringFormat.intFormatUtf16 | 69.233 | 27.183 | 154.69% | | StringFormat.intHexFormat | 116.871 | 55.386 | 111.01% | | StringFormat.intHexFormatUtf16 | 130.486 | 70.344 | 85.50% | | StringFormat.intHexUFormat | 122.547 | 61.599 | 98.94% | | StringFormat.intHexUFormatUtf16 | 133.570 | 80.965 | 64.97% | | StringFormat.intIntFormat | 118.463 | 53.510 | 121.38% | | StringFormat.intIntFormatUtf16 | 120.305 | 53.795 | 123.64% | | StringFormat.intOctalFormat | 117.049 | 65.075 | 79.87% | | StringFormat.intOctalFormatUtf16 | 131.041 | 79.609 | 64.61% | | StringFormat.lineFormat | 46.440 | 24.306 | 91.06% | | StringFormat.lineFormatUtf16 | 51.169 | 28.136 | 81.86% | | StringFormat.stringFormat | 50.507 | 24.137 | 109.25% | | StringFormat.stringFormatUtf16 | 54.684 | 28.368 | 92.77% | | StringFormat.stringIntFormat | 107.311 | 50.953 | 110.61% | | StringFormat.stringIntFormatUtf16 | 115.677 | 62.363 | 85.49% | | StringFormat.stringIntHexFormat | 103.388 | 59.528 | 73.68% | | StringFormat.stringIntHexUFormat | 103.773 | 58.935 | 76.08% | | StringFormat.stringIntOctalFormat | 103.900 | 68.614 | 51.43% | | StringFormat.stringIntOctalFormatUtf16 | 116.362 | 80.326 | 44.86% | | StringFormat.stringIntRFormat | 127.924 | 60.547 | 111.28% | | StringFormat.stringIntRFormatUtf16 | 142.177 | 76.189 | 86.61% | | StringFormat.stringWidthIntFormat | 142.864 | 57.070 | 150.33% | | StringFormat.stringWidthIntFormatUtf16 | 141.588 | 68.253 | 107.45% | | StringFormat.widthStringFormat | 62.167 | 24.473 | 154.02% | | StringFormat.widthStringFormatUtf16 | 67.403 | 29.436 | 128.98% | | StringFormat.widthStringIntFormat | 136.524 | 57.610 | 136.98% | | StringFormat.widthStringIntFormatUtf16 | 138.060 | 65.597 | 110.47% | ## [aliyun ecs.c8i](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) * CPU Intel? Xeon? Emerald * Platform x64 # baseline b83766e59063a41ea8801ac9e7c15dce67727c62 -Benchmark Mode Cnt Score Error Units -StringFormat.complexFormat avgt 15 529.057 ? 4.446 ns/op -StringFormat.decimalFormat avgt 15 322.432 ? 1.405 ns/op -StringFormat.intFormat avgt 15 65.234 ? 0.220 ns/op -StringFormat.intFormatUtf16 avgt 15 70.822 ? 0.907 ns/op -StringFormat.intHexFormat avgt 15 108.173 ? 0.526 ns/op -StringFormat.intHexFormatUtf16 avgt 15 123.867 ? 0.686 ns/op -StringFormat.intHexUFormat avgt 15 112.425 ? 0.841 ns/op -StringFormat.intHexUFormatUtf16 avgt 15 128.555 ? 1.833 ns/op -StringFormat.intIntFormat avgt 15 117.720 ? 1.043 ns/op -StringFormat.intIntFormatUtf16 avgt 15 119.817 ? 1.976 ns/op -StringFormat.intOctalFormat avgt 15 108.340 ? 0.417 ns/op -StringFormat.intOctalFormatUtf16 avgt 15 121.281 ? 2.423 ns/op -StringFormat.lineFormat avgt 15 46.437 ? 0.146 ns/op -StringFormat.lineFormatUtf16 avgt 15 52.059 ? 0.268 ns/op -StringFormat.stringFormat avgt 15 48.699 ? 0.266 ns/op -StringFormat.stringFormatUtf16 avgt 15 55.069 ? 0.295 ns/op -StringFormat.stringIntFormat avgt 15 97.408 ? 0.855 ns/op -StringFormat.stringIntFormatUtf16 avgt 15 113.801 ? 1.206 ns/op -StringFormat.stringIntHexFormat avgt 15 95.091 ? 0.540 ns/op -StringFormat.stringIntHexUFormat avgt 15 94.368 ? 0.389 ns/op -StringFormat.stringIntOctalFormat avgt 15 94.731 ? 0.592 ns/op -StringFormat.stringIntOctalFormatUtf16 avgt 15 107.460 ? 0.100 ns/op -StringFormat.stringIntRFormat avgt 15 114.745 ? 0.211 ns/op -StringFormat.stringIntRFormatUtf16 avgt 15 132.979 ? 3.001 ns/op -StringFormat.stringWidthIntFormat avgt 15 129.590 ? 0.719 ns/op -StringFormat.stringWidthIntFormatUtf16 avgt 15 134.643 ? 2.166 ns/op -StringFormat.widthStringFormat avgt 15 60.557 ? 0.716 ns/op -StringFormat.widthStringFormatUtf16 avgt 15 67.925 ? 0.798 ns/op -StringFormat.widthStringIntFormat avgt 15 125.359 ? 1.424 ns/op -StringFormat.widthStringIntFormatUtf16 avgt 15 131.336 ? 1.519 ns/op # current b2f517ba459c55b2d69fe5a43723d15370cdab4b +Benchmark Mode Cnt Score Error Units +StringFormat.complexFormat avgt 15 386.754 ? 7.144 ns/op +StringFormat.decimalFormat avgt 15 289.619 ? 2.738 ns/op +StringFormat.intFormat avgt 15 25.465 ? 2.249 ns/op +StringFormat.intFormatUtf16 avgt 15 31.938 ? 1.428 ns/op +StringFormat.intHexFormat avgt 15 51.730 ? 1.685 ns/op +StringFormat.intHexFormatUtf16 avgt 15 71.242 ? 1.330 ns/op +StringFormat.intHexUFormat avgt 15 57.009 ? 0.636 ns/op +StringFormat.intHexUFormatUtf16 avgt 15 75.337 ? 0.378 ns/op +StringFormat.intIntFormat avgt 15 52.773 ? 0.163 ns/op +StringFormat.intIntFormatUtf16 avgt 15 52.769 ? 0.131 ns/op +StringFormat.intOctalFormat avgt 15 58.615 ? 0.456 ns/op +StringFormat.intOctalFormatUtf16 avgt 15 75.639 ? 0.689 ns/op +StringFormat.lineFormat avgt 15 23.287 ? 0.093 ns/op +StringFormat.lineFormatUtf16 avgt 15 30.649 ? 0.150 ns/op +StringFormat.stringFormat avgt 15 22.710 ? 0.055 ns/op +StringFormat.stringFormatUtf16 avgt 15 30.146 ? 0.114 ns/op +StringFormat.stringIntFormat avgt 15 50.326 ? 0.122 ns/op +StringFormat.stringIntFormatUtf16 avgt 15 62.278 ? 1.169 ns/op +StringFormat.stringIntHexFormat avgt 15 56.447 ? 0.280 ns/op +StringFormat.stringIntHexUFormat avgt 15 56.390 ? 0.641 ns/op +StringFormat.stringIntOctalFormat avgt 15 67.885 ? 0.603 ns/op +StringFormat.stringIntOctalFormatUtf16 avgt 15 78.597 ? 1.861 ns/op +StringFormat.stringIntRFormat avgt 15 56.320 ? 0.581 ns/op +StringFormat.stringIntRFormatUtf16 avgt 15 75.227 ? 2.130 ns/op +StringFormat.stringWidthIntFormat avgt 15 54.156 ? 0.110 ns/op +StringFormat.stringWidthIntFormatUtf16 avgt 15 68.158 ? 2.946 ns/op +StringFormat.widthStringFormat avgt 15 23.148 ? 0.150 ns/op +StringFormat.widthStringFormatUtf16 avgt 15 31.589 ? 0.283 ns/op +StringFormat.widthStringIntFormat avgt 15 57.852 ? 0.495 ns/op +StringFormat.widthStringIntFormatUtf16 avgt 15 69.162 ? 2.344 ns/op | | baseline | current | delta | | --- | --- | --- | --- | | StringFormat.complexFormat | 529.057 | 386.754 | 36.79% | | StringFormat.decimalFormat | 322.432 | 289.619 | 11.33% | | StringFormat.intFormat | 65.234 | 25.465 | 156.17% | | StringFormat.intFormatUtf16 | 70.822 | 31.938 | 121.75% | | StringFormat.intHexFormat | 108.173 | 51.730 | 109.11% | | StringFormat.intHexFormatUtf16 | 123.867 | 71.242 | 73.87% | | StringFormat.intHexUFormat | 112.425 | 57.009 | 97.21% | | StringFormat.intHexUFormatUtf16 | 128.555 | 75.337 | 70.64% | | StringFormat.intIntFormat | 117.720 | 52.773 | 123.07% | | StringFormat.intIntFormatUtf16 | 119.817 | 52.769 | 127.06% | | StringFormat.intOctalFormat | 108.340 | 58.615 | 84.83% | | StringFormat.intOctalFormatUtf16 | 121.281 | 75.639 | 60.34% | | StringFormat.lineFormat | 46.437 | 23.287 | 99.41% | | StringFormat.lineFormatUtf16 | 52.059 | 30.649 | 69.86% | | StringFormat.stringFormat | 48.699 | 22.710 | 114.44% | | StringFormat.stringFormatUtf16 | 55.069 | 30.146 | 82.67% | | StringFormat.stringIntFormat | 97.408 | 50.326 | 93.55% | | StringFormat.stringIntFormatUtf16 | 113.801 | 62.278 | 82.73% | | StringFormat.stringIntHexFormat | 95.091 | 56.447 | 68.46% | | StringFormat.stringIntHexUFormat | 94.368 | 56.390 | 67.35% | | StringFormat.stringIntOctalFormat | 94.731 | 67.885 | 39.55% | | StringFormat.stringIntOctalFormatUtf16 | 107.460 | 78.597 | 36.72% | | StringFormat.stringIntRFormat | 114.745 | 56.320 | 103.74% | | StringFormat.stringIntRFormatUtf16 | 132.979 | 75.227 | 76.77% | | StringFormat.stringWidthIntFormat | 129.590 | 54.156 | 139.29% | | StringFormat.stringWidthIntFormatUtf16 | 134.643 | 68.158 | 97.55% | | StringFormat.widthStringFormat | 60.557 | 23.148 | 161.61% | | StringFormat.widthStringFormatUtf16 | 67.925 | 31.589 | 115.03% | | StringFormat.widthStringIntFormat | 125.359 | 57.852 | 116.69% | | StringFormat.widthStringIntFormatUtf16 | 131.336 | 69.162 | 89.90% | ## [aliyun ecs.c8y](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8y) * CPU Yitian710 aarch64 * Platform aarch64 # baseline b83766e59063a41ea8801ac9e7c15dce67727c62 -Benchmark Mode Cnt Score Error Units -StringFormat.complexFormat avgt 15 773.031 ? 3.099 ns/op -StringFormat.decimalFormat avgt 15 398.171 ? 4.713 ns/op -StringFormat.intFormat avgt 15 103.018 ? 2.348 ns/op -StringFormat.intFormatUtf16 avgt 15 119.492 ? 2.190 ns/op -StringFormat.intHexFormat avgt 15 177.283 ? 3.302 ns/op -StringFormat.intHexFormatUtf16 avgt 15 195.128 ? 9.053 ns/op -StringFormat.intHexUFormat avgt 15 194.399 ? 7.280 ns/op -StringFormat.intHexUFormatUtf16 avgt 15 200.689 ? 4.014 ns/op -StringFormat.intIntFormat avgt 15 180.146 ? 1.970 ns/op -StringFormat.intIntFormatUtf16 avgt 15 195.222 ? 13.176 ns/op -StringFormat.intOctalFormat avgt 15 174.285 ? 8.477 ns/op -StringFormat.intOctalFormatUtf16 avgt 15 186.157 ? 3.778 ns/op -StringFormat.lineFormat avgt 15 82.938 ? 0.863 ns/op -StringFormat.lineFormatUtf16 avgt 15 94.125 ? 0.790 ns/op -StringFormat.stringFormat avgt 15 81.651 ? 4.897 ns/op -StringFormat.stringFormatUtf16 avgt 15 98.348 ? 0.773 ns/op -StringFormat.stringIntFormat avgt 15 167.333 ? 1.800 ns/op -StringFormat.stringIntFormatUtf16 avgt 15 190.981 ? 4.937 ns/op -StringFormat.stringIntHexFormat avgt 15 157.498 ? 3.696 ns/op -StringFormat.stringIntHexUFormat avgt 15 160.588 ? 3.764 ns/op -StringFormat.stringIntOctalFormat avgt 15 160.813 ? 2.398 ns/op -StringFormat.stringIntOctalFormatUtf16 avgt 15 176.153 ? 7.430 ns/op -StringFormat.stringIntRFormat avgt 15 187.924 ? 0.902 ns/op -StringFormat.stringIntRFormatUtf16 avgt 15 202.559 ? 2.601 ns/op -StringFormat.stringWidthIntFormat avgt 15 194.698 ? 4.673 ns/op -StringFormat.stringWidthIntFormatUtf16 avgt 15 233.417 ? 5.496 ns/op -StringFormat.widthStringFormat avgt 15 100.334 ? 0.915 ns/op -StringFormat.widthStringFormatUtf16 avgt 15 113.190 ? 13.681 ns/op -StringFormat.widthStringIntFormat avgt 15 211.096 ? 1.347 ns/op -StringFormat.widthStringIntFormatUtf16 avgt 15 227.000 ? 10.045 ns/op # current b2f517ba459c55b2d69fe5a43723d15370cdab4b +Benchmark Mode Cnt Score Error Units +StringFormat.complexFormat avgt 15 581.514 ? 13.122 ns/op +StringFormat.decimalFormat avgt 15 348.420 ? 1.901 ns/op +StringFormat.intFormat avgt 15 29.603 ? 0.325 ns/op +StringFormat.intFormatUtf16 avgt 15 35.211 ? 0.459 ns/op +StringFormat.intHexFormat avgt 15 68.486 ? 0.894 ns/op +StringFormat.intHexFormatUtf16 avgt 15 94.581 ? 8.873 ns/op +StringFormat.intHexUFormat avgt 15 77.773 ? 1.939 ns/op +StringFormat.intHexUFormatUtf16 avgt 15 95.887 ? 1.966 ns/op +StringFormat.intIntFormat avgt 15 70.615 ? 1.438 ns/op +StringFormat.intIntFormatUtf16 avgt 15 66.945 ? 2.027 ns/op +StringFormat.intOctalFormat avgt 15 80.453 ? 1.638 ns/op +StringFormat.intOctalFormatUtf16 avgt 15 102.267 ? 3.882 ns/op +StringFormat.lineFormat avgt 15 29.769 ? 0.634 ns/op +StringFormat.lineFormatUtf16 avgt 15 35.713 ? 1.031 ns/op +StringFormat.stringFormat avgt 15 28.574 ? 0.458 ns/op +StringFormat.stringFormatUtf16 avgt 15 35.554 ? 0.496 ns/op +StringFormat.stringIntFormat avgt 15 62.198 ? 3.217 ns/op +StringFormat.stringIntFormatUtf16 avgt 15 89.910 ? 3.620 ns/op +StringFormat.stringIntHexFormat avgt 15 67.230 ? 1.309 ns/op +StringFormat.stringIntHexUFormat avgt 15 66.143 ? 1.140 ns/op +StringFormat.stringIntOctalFormat avgt 15 78.613 ? 1.046 ns/op +StringFormat.stringIntOctalFormatUtf16 avgt 15 104.297 ? 4.769 ns/op +StringFormat.stringIntRFormat avgt 15 67.872 ? 1.229 ns/op +StringFormat.stringIntRFormatUtf16 avgt 15 93.982 ? 1.778 ns/op +StringFormat.stringWidthIntFormat avgt 15 70.326 ? 3.684 ns/op +StringFormat.stringWidthIntFormatUtf16 avgt 15 88.422 ? 5.396 ns/op +StringFormat.widthStringFormat avgt 15 28.349 ? 0.462 ns/op +StringFormat.widthStringFormatUtf16 avgt 15 35.467 ? 0.370 ns/op +StringFormat.widthStringIntFormat avgt 15 68.397 ? 3.443 ns/op +StringFormat.widthStringIntFormatUtf16 avgt 15 86.467 ? 3.557 ns/op | | baseline | current | delta | | --- | --- | --- | --- | | StringFormat.complexFormat | 773.031 | 581.514 | 32.93% | | StringFormat.decimalFormat | 398.171 | 348.420 | 14.28% | | StringFormat.intFormat | 103.018 | 29.603 | 248.00% | | StringFormat.intFormatUtf16 | 119.492 | 35.211 | 239.36% | | StringFormat.intHexFormat | 177.283 | 68.486 | 158.86% | | StringFormat.intHexFormatUtf16 | 195.128 | 94.581 | 106.31% | | StringFormat.intHexUFormat | 194.399 | 77.773 | 149.96% | | StringFormat.intHexUFormatUtf16 | 200.689 | 95.887 | 109.30% | | StringFormat.intIntFormat | 180.146 | 70.615 | 155.11% | | StringFormat.intIntFormatUtf16 | 195.222 | 66.945 | 191.62% | | StringFormat.intOctalFormat | 174.285 | 80.453 | 116.63% | | StringFormat.intOctalFormatUtf16 | 186.157 | 102.267 | 82.03% | | StringFormat.lineFormat | 82.938 | 29.769 | 178.61% | | StringFormat.lineFormatUtf16 | 94.125 | 35.713 | 163.56% | | StringFormat.stringFormat | 81.651 | 28.574 | 185.75% | | StringFormat.stringFormatUtf16 | 98.348 | 35.554 | 176.62% | | StringFormat.stringIntFormat | 167.333 | 62.198 | 169.03% | | StringFormat.stringIntFormatUtf16 | 190.981 | 89.910 | 112.41% | | StringFormat.stringIntHexFormat | 157.498 | 67.230 | 134.27% | | StringFormat.stringIntHexUFormat | 160.588 | 66.143 | 142.79% | | StringFormat.stringIntOctalFormat | 160.813 | 78.613 | 104.56% | | StringFormat.stringIntOctalFormatUtf16 | 176.153 | 104.297 | 68.90% | | StringFormat.stringIntRFormat | 187.924 | 67.872 | 176.88% | | StringFormat.stringIntRFormatUtf16 | 202.559 | 93.982 | 115.53% | | StringFormat.stringWidthIntFormat | 194.698 | 70.326 | 176.85% | | StringFormat.stringWidthIntFormatUtf16 | 233.417 | 88.422 | 163.98% | | StringFormat.widthStringFormat | 100.334 | 28.349 | 253.92% | | StringFormat.widthStringFormatUtf16 | 113.190 | 35.467 | 219.14% | | StringFormat.widthStringIntFormat | 211.096 | 68.397 | 208.63% | | StringFormat.widthStringIntFormatUtf16 | 227.000 | 86.467 | 162.53% | ------------- PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211548388 From pminborg at openjdk.org Sat Jul 6 15:08:41 2024 From: pminborg at openjdk.org (Per Minborg) Date: Sat, 6 Jul 2024 15:08:41 GMT Subject: Integrated: 8333884: MemorySegment::reinterpret removes read-only property In-Reply-To: References: Message-ID: <9sjJ1_JmxIbu6KnCi7GFXrfBP3tWKM1rcABdvpfMgnE=.1cbfb033-6dce-4d60-8d0d-eb688ceb32ce@github.com> On Mon, 10 Jun 2024 13:18:43 GMT, Per Minborg wrote: > This PR proposes to retain the read-only state when any of the `MemorySegment::reinterpret` methods is called. > > Previously, the read-only state was lost and the returned `MemorySegment` was always writable regardless of the original segment's read-only state. This pull request has now been integrated. Changeset: 6f7f0f1d Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef Stats: 38 lines in 4 files changed: 30 ins; 1 del; 7 mod 8333884: MemorySegment::reinterpret removes read-only property Reviewed-by: jvernee, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/19629 From darcy at openjdk.org Sun Jul 7 20:24:40 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sun, 7 Jul 2024 20:24:40 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} Message-ID: Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. ------------- Commit messages: - JDK-8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} Changes: https://git.openjdk.org/jdk/pull/20063/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20063&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335637 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20063/head:pull/20063 PR: https://git.openjdk.org/jdk/pull/20063 From duke at openjdk.org Mon Jul 8 02:32:17 2024 From: duke at openjdk.org (lingjun-cg) Date: Mon, 8 Jul 2024 02:32:17 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v17] In-Reply-To: References: Message-ID: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: 8333396: Performance regression of DecimalFormat.format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19513/files - new: https://git.openjdk.org/jdk/pull/19513/files/7122c2c8..d675bcbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=15-16 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513 From liach at openjdk.org Mon Jul 8 03:08:44 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Jul 2024 03:08:44 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v17] In-Reply-To: References: Message-ID: <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com> On Mon, 8 Jul 2024 02:32:17 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Performance regression of DecimalFormat.format Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`? In the ClassFile API, there are similar "behave as if" notes such as https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438, yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2212893099 From duke at openjdk.org Mon Jul 8 03:51:36 2024 From: duke at openjdk.org (lingjun-cg) Date: Mon, 8 Jul 2024 03:51:36 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v16] In-Reply-To: References: <9axU7oSSiv3hbiHb71VynRC-RSn6iKmW8EWhGFpyvlA=.57cf9880-ac37-4591-80bd-0439b1144351@github.com> Message-ID: On Fri, 5 Jul 2024 16:54:41 GMT, Justin Lu wrote: > Following up on my previous comment regarding the _untrue wording_. > > I no longer think we can just split the implementation and specification portion of this PR into two issues, since if we backport the implementation only, the specification would now be violated for the back-ported releases. We may have to just include the specification in this issue as well, (which will require a CSR and no longer means we can backport this change). A CSR request created: https://bugs.openjdk.org/browse/JDK-8335834 ------------- PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2212946822 From alanb at openjdk.org Mon Jul 8 08:07:46 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Jul 2024 08:07:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee 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 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/a6e3a992...1d1ff010 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2162567660 From aboldtch at openjdk.org Mon Jul 8 08:25:02 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 08:25:02 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping Message-ID: When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. # Cleanups Cleaned up displaced header usage for: * BasicLock * Contains some Zero changes * Renames one exported JVMCI field * ObjectMonitor * Updates comments and tests consistencies # Refactoring `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ # LightweightSynchronizer Working on adapting and incorporating the following section as a comment in the source code ## Fast Locking CAS on locking bits in markWord. 0b00 (Fast Locked) <--> 0b01 (Unlocked) When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inflated locking is performed. ### Fast Lock Spinning (UseObjectMonitorTable) When a thread fails fast locking when a monitor is not yet inflated, it will spin on the markWord using a exponential backoff scheme. The thread will attempt the fast lock CAS and then SpinWait() for some time, doubling with every failed attempt, up to a maximum number of attempts. There is a diagnostic VM option LightweightFastLockingSpins which can be used to tune this value. The behavior of SpinWait() can be hardware dependent. A future improvement may be to adapt this spinning limit to observed behavior. Which would automatically adapt to the different hardware behavior of SpinWait(). ## Inflated Locking Inflated locking means that a ObjectMonitor is associated with the object and is used for locking instead of the locking bits in the markWord. ## Inflated Locking without table (!UseObjectMonitorTable) An inflating thread will create a ObjectMonitor and CAS the ObjectMonitor* into the markWord along with the 0b10 (Inflated) lock bits. If the transition of the lock bits is from 0b00 (Fast Locked) the ObjectMonitor must be published with an anonymous owner (setting _owner to ANONYMOUS_OWNER). If the transition of the lock bits is from 0b00 (Unlocked) the ObjectMonitor is published with no owner. When encountering an ObjectMonitor with an anonymous owner the thread checks its lock stack to see if it is the owner, in which case it removes the object from its lock stack and sets itself as the owner of the ObjectMonitor along with fixing the recursion level to correspond to the number of removed lock stack entires. ## Inflated Locking with table (UseObjectMonitorTable) Because publishing the ObjectMonitor* and signaling that a object's monitor is inflated is not atomic, more care must be taken (in the presence of deflation) so that all threads agree on which ObjectMonitor* to use. When encountering an ObjectMonitor with an anonymous owner the thread checks its lock stack to see if it is the owner, in which case it removes the object from its lock stack and sets itself as the owner of the ObjectMonitor along with fixing the recursion level to correspond to the number of removed lock stack entires. All complications arise from deflation, or the process of disassociating an ObjectMonitor from its Java Object. So first the mechanism used for deflation is explained. Followed by retrieval and creation of ObjectMonitors. ### Deflation An ObjectMonitor can only be deflated if it has no owner, its queues are empty and no thread is in a scope where it has incremented and checked the contentions reference counter. The interactions between deflation and wait is handled by having the owner and wait queue entry overlap to blocks out deflation; the wait queue entry is protected by a waiters reference counter which is only modified by the waiters while holding the monitor, incremented before exiting the monitor and decremented after reentering the monitor. For enter and exit where the deflator may observe empty queues and no owner a two step mechanism is used to synchronize deflation with concurrently locking threads; deflation is synchronized using the contentions reference counter. In the text below we refer to "holding the contentions reference counter". This means that a thread has incremented the contentions reference counter and verified that it is not negative. ```c++ if (Atomic::fetch_and_add(&monitor->_contentions, 1) >= 0) { // holding the contentions reference counter } Atomic::decrement(&monitor->_contentions); ``` #### Deflation protocol The first step for the deflator is to try and CAS the owner from no owner to a special marker (DEFLATER_MARKER). If this is successful it blocks any entering thread from successfully installing themselves as the owner and causes compiled code to take a slow path and call into the runtime. The second step for the deflator is to check waiters reference counter and if it is 0 try CAS the contentions reference counter from 0 to a large negative value (INT_MIN). If this succeeds the monitor is deflated. The deflator does not have to check the entry queues because every thread on the entry queues must have either hold the contentions reference counter, or incremented the waiters reference counter, in the case they were moved from the wait queue to the entry queues by a notify. The deflator check the waiters reference counter, with the memory ordering of Waiter: { increment waiters reference counter; release owner }, Deflator: { acquire owner; check waiters reference counter }. All threads on the entry queues or wait queue invariantly holds the contentions reference counter or the waiters reference counter. #### Deflation cleanup If deflation succeeds, locking bits are then transitioned back to 0b01 (Unlocked). With UseObjectMonitorTable it is required that this is done by the deflator, or it could lead to ABA problems in the locking bits. Without the table the whole ObjectMonitor* is part of the markWord transition, with its pointer being phased out of the system with a handshake, making every value distinguishable and avoiding ABA issues. For UseObjectMonitorTable the deflated monitor is also removed from the table. This is done after transitioning the markWord to allow concurrently entering threads to fast lock on the object while the monitor is being removed from the hash table. If deflation fails after the marker (DEFLATER_MARKER) has been CASed into the owner field the owner must be restored. From the deflation threads point of view it is as simple as CASing from the marker to no owner. However to not have all threads depend on the deflation thread making progress here we allow any thread to CAS from the marker if that thread has both incremented and checked the contentions counter. This thread has now effectively canceled the deflation, but it is important that the deflator observes this fact, we do this by forgetting to decrement the contentions counter. The effect is that the contentions CAS will fail, which will force the deflator to try and restore the owner, but this will also fail because it got canceled. So the deflator decrements the contentions counter instead on behalf of the canceling thread to balance the reference counting. (Currently this is implemented by doing a +1 +1 -1 reference count on the locking thread, but a simple only +1 would s uffice). ### Retrieve ObjectMonitor #### HashTable Maintains a mapping between Java Objects and ObjectMonitors. Lookups are done via the objects identity_hash. If the hash table contains an ObjectMonitor for a specific object then that ObjectMonitor is used for locking unless it is being deflated. Only deflation removes (not dead) entries inside the HashTable. #### ThreadLocal Cache (UseObjectMonitorTable) The most recently locked ObjectMonitors by a thread are cached in that thread's local storage. These are used to elide hash table lookups. These caches uses raw oops to make cache lookups trivial. However this requires special handling of the cache at safepoints. The caches are cleared when a safepoint is triggered (instead of letting the gc visit them), this to avoid keeping cache entries as gc roots. These cache entires may become deflated, but locking on such a monitor still participates in the normal deflation protocol. Because these entries are cleared during a safepoint, the handshake performed by monitor deflation to phase out ObjectMonitor* from the system will also phase these out. #### StackLocal Cache Each monitorenter has a corresponding BasicLock entry on the stack. Each successful inflated monitorenter saves the ObjectMonitor* inside this BasicLock entry and retrieves it when performing the corresponding monitorexit. This means it is important that the BasicLock entry is always initialized to a known state (nullptr is used). The RAII object class CacheSetter is used to ensure that the BasicLock gets initialized before leaving the runtime code, and that both caches gets updated correctly. (Only once, with the same locked ObjectMonitor). The cache entries are set when a monitor is entered and never used again after a that monitored has been exited. So there are no interactions with deflation here. Similarly these caches does not track the associated oop, but rely on the fact that the same BasicLock data created for a monitorenter is used when executing the corresponding monitorexit. ### Creating ObjectMonitor If retrieval of the ObjectMonitor fails, because there is no ObjectMonitor, either because this is the first time inflating or the ObjectMonitor has been deflated a new ObjectMonitor must be created and associated with the object. The inflating thread will then attempt to insert a newly created ObjectMonitor in the hash table. The important invariant is that any ObjectMonitor inserted must have an anonymous owner (setting _owner to ANONYMOUS_OWNER). This solves the issue of not being able to atomically inserting the ObjectMonitor in the hash table, and transitioning the markWord to 0b10 (Inflated). We instead have all inflating threads insert an identical anonymously owned ObjectMonitor in the table and then decide ownership based on how the markWord is transitioned to 0b10 (Inflated). Note: Only one ObjectMonitor can be inserted. This also has the effect of blocking deflation on a newly inserted ObjectMonitor, until the contentions reference counter can be incremented. The contentions reference counter is held while transitioning the markWord to block out deflation. * If a thread observes 0b10 (Inflated) * If the current thread is the thread that fast locked, take ownership. Update ObjectMonitor _recursions based on fast locked recursions. Call ObjectMonitor::enter(current); * Otherwise Some other thread is the owner, and will claim ownership. Call ObjectMonitor::enter(current); * If a thread succeeds with the CAS to 0b10 (Inflated) * From 0b00 (Fast Locked) * If the current thread is the thread that fast locked, take ownership. Update ObjectMonitor _recursions based on fast locked recursions. Call ObjectMonitor::enter(current); * Otherwise Some other thread is the owner, and will claim ownership. Call ObjectMonitor::enter(current); * From 0b01 (Unlocked) * Claim ownership, no ObjectMonitor::enter is required. * If a thread fails the CAS reload markWord and retry ### Un-contended Inflated Locking CAS on _owner field in ObjectMonitor. JavaThread* (Locked By Thread) <--> nullptr (Unlocked) ### Contended Inflated Locking Blocks out deflation. Spin CAS on _owner field in ObjectMonitor. JavaThread* (Locked By Thread) <--> nullptr (Unlocked) Details in ObjectMonitor.hpp ### HashTable Resizing and Cleanup Resizing is currently handled with the similar logic to what the string and symbol table uses. And is delegated to the ServiceThread. The goal is to eventually this to deflation thread, to allow for better interactions with the deflation cycles, making it possible to also shrink the table. But this will be done incrementally as a separate enhancement. The ServiceThread is currently used to deal with the fact that we currently allow the deflation thread to be turned off via JVM options. Cleanup is mostly handled by the the deflator which actively removes deflated monitors, which includes monitors for dead objects. However we allow any thread to remove dead objects' ObjectMonitor* associations. But actual memory reclamation of the ObjectMonitor is always handled by the deflator. The table is currently initialized before `init_globals`, as such the max size of the table which is based on `MaxHeapSize` may be incorrect because it is not yet finalized. ------------- Commit messages: - 8315884: New Object to ObjectMonitor mapping Changes: https://git.openjdk.org/jdk/pull/20067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315884 Stats: 3613 lines in 70 files changed: 2700 ins; 313 del; 600 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From asotona at openjdk.org Mon Jul 8 08:31:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 8 Jul 2024 08:31:32 GMT Subject: RFR: 8335727: since-checker: Add `@since` tags to ClassFile::transformClass and CodeBuilder In-Reply-To: References: Message-ID: <6DBJ67vmSeGj5RkbrVuX4icbFkYPBl0Mh2B21rLjXGc=.e1f7466e-cffe-4ab4-b16a-cee4b6b48770@github.com> On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote: > Please review this simple doc only change. > Some methods in ClassFile API were renamed recently as part of [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and need to have `@since 24`, as they are essentially new methods. > > Thanks! Just FYI: move from preview to final will bump all `@since` tags and remove obsolete method-level `@since` tags (as they become equal to the class-level tag). see: #19826 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20041#issuecomment-2213355929 From prappo at openjdk.org Mon Jul 8 09:33:32 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 09:33:32 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote: > Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. Looks good. ------------- Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2162781503 From jpai at openjdk.org Mon Jul 8 09:36:34 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 8 Jul 2024 09:36:34 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote: > Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. src/java.base/share/classes/java/lang/Object.java line 101: > 99: * implementation should not use excessive memory or time for its > 100: * computations and should return a result for cyclic data > 101: * structures. Hello Joe, adding this text to set the expectations looks reasonable. However, I think the text "should return a result for cyclic data structures." feels a bit odd. If I understand correctly what it's trying to state is that for a class of the form: class Foo { Bar bar; Foo self; public void setSelf() { this.self = this; } } then: Foo foo = new Foo(); foo.toString(); // or foo.hashCode() should be able to return the output from hashCode() and toString() even when an instance of `Foo` has a field which holds the same `Foo` instance. i.e. `toString()` and `hashCode()` should be able to handle re-entrancy and shouldn't consume excessive memory or time. If that understanding is correct, then maybe we could improve that text to state it differently instead of cyclic data structures? I checked the JDK repo to see if this term has previously been used but it hasn't. Maybe we should just state that the hashCode() toString() methods should be able to deal with re-entrancy? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1668312734 From duke at openjdk.org Mon Jul 8 09:42:31 2024 From: duke at openjdk.org (Thomas Wuerthinger) Date: Mon, 8 Jul 2024 09:42:31 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 08:18:42 GMT, Axel Boldt-Christmas wrote: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Is this change expected to require JVMCI and/or Graal JIT changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213534062 From prappo at openjdk.org Mon Jul 8 09:58:36 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 09:58:36 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 09:33:54 GMT, Jaikiran Pai wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > src/java.base/share/classes/java/lang/Object.java line 101: > >> 99: * implementation should not use excessive memory or time for its >> 100: * computations and should return a result for cyclic data >> 101: * structures. > > Hello Joe, adding this text to set the expectations looks reasonable. However, I think the text "should return a result for cyclic data structures." feels a bit odd. If I understand correctly what it's trying to state is that for a class of the form: > > > class Foo { > Bar bar; > Foo self; > > public void setSelf() { > this.self = this; > } > } > > then: > > > Foo foo = new Foo(); > foo.toString(); // or foo.hashCode() > > should be able to return the output from hashCode() and toString() even when an instance of `Foo` has a field which holds the same `Foo` instance. i.e. `toString()` and `hashCode()` should be able to handle re-entrancy and shouldn't consume excessive memory or time. > > If that understanding is correct, then maybe we could improve that text to state it differently instead of cyclic data structures? I checked the JDK repo to see if this term has previously been used but it hasn't. Maybe we should just state that the hashCode() toString() methods should be able to deal with re-entrancy? My understanding is the same. Personally, the wording reads unambiguously. The words "circular" and "circularity" can be seen throughout codebase, in similar contexts. FWIW, a simpler example can be constructed like this: var list = new ArrayList<>(); list.add(list); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1668342145 From aboldtch at openjdk.org Mon Jul 8 10:14:32 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 10:14:32 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 09:39:32 GMT, Thomas Wuerthinger wrote: > Is this change expected to require JVMCI and/or Graal JIT changes? Support for `UseObjectMonitorTable` would require changes to Graal JIT. (`UseObjectMonitorTable` is off by default). Minimal support would be to call into the VM for inflated monitors. (Similarly to what this patch does for C2 for none x86 / aarch64 platforms). For starting the VM normally without `UseObjectMonitorTable` no semantic change is required. All locking modes and VM invariants w.r.t. locking are the same. As mentioned this patch contains a refactoring which renames one exported `JVMCI` symbol which I suspect should only be used by Graal JIT for `LM_LEGACY`. As such the Graal JIT needs to be updated to use this new symbol name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213602121 From jlahoda at openjdk.org Mon Jul 8 10:16:09 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 8 Jul 2024 10:16:09 GMT Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v5] In-Reply-To: References: Message-ID: > For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input. > > There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like: > > > enum E {A, B, C} > E e = ...; > switch (e) { > case null -> {} > case A a -> {} > case C c -> {} > case B b -> {} > } > > > We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums. > > The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly). > > This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`). > > When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index. > > I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used. > > I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like: > > Benchmark Mode Cnt Score Error Units > SwitchEnum.enumSwitchTraditional avgt 15 11.719 ? 0.333 ns/op > SwitchEnum.enumSwitchWithBootstrap avgt 15 24.668 ? 1.037 ... Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback - using instanceof rather than isAssignableFrom ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19906/files - new: https://git.openjdk.org/jdk/pull/19906/files/512a802a..d09fa40e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19906&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19906/head:pull/19906 PR: https://git.openjdk.org/jdk/pull/19906 From nbenalla at openjdk.org Mon Jul 8 10:18:32 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 8 Jul 2024 10:18:32 GMT Subject: RFR: 8335727: since-checker: Add `@since` tags to ClassFile::transformClass and CodeBuilder In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote: > Please review this simple doc only change. > Some methods in ClassFile API were renamed recently as part of [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and need to have `@since 24`, as they are essentially new methods. > > Thanks! Thank you, I created this PR because the test in #18934 failed when I was running it. If ClassFile goes final before the checker is integrated then this should be fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20041#issuecomment-2213612055 From nbenalla at openjdk.org Mon Jul 8 10:48:37 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 8 Jul 2024 10:48:37 GMT Subject: RFR: 8335727: since-checker: Add `@since` tags to ClassFile::transformClass and CodeBuilder In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote: > Please review this simple doc only change. > Some methods in ClassFile API were renamed recently as part of [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and need to have `@since 24`, as they are essentially new methods. > > Thanks! I will close this for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20041#issuecomment-2213666198 From nbenalla at openjdk.org Mon Jul 8 10:48:38 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 8 Jul 2024 10:48:38 GMT Subject: Withdrawn: 8335727: since-checker: Add `@since` tags to ClassFile::transformClass and CodeBuilder In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote: > Please review this simple doc only change. > Some methods in ClassFile API were renamed recently as part of [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and need to have `@since 24`, as they are essentially new methods. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20041 From asotona at openjdk.org Mon Jul 8 10:54:36 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 8 Jul 2024 10:54:36 GMT Subject: [jdk23] RFR: 8335475: ClassBuilder incorrectly calculates max_locals in some cases In-Reply-To: <2Gb-4i4BJzRxL2YimwmG1ITHcC5TSvpk1NHUr0Une3Q=.100470b5-f8f4-4d04-92a6-a33dbacaf47b@github.com> References: <2Gb-4i4BJzRxL2YimwmG1ITHcC5TSvpk1NHUr0Une3Q=.100470b5-f8f4-4d04-92a6-a33dbacaf47b@github.com> Message-ID: <5iN5O548vYOKUfmLVGBikTeo_VaNBtBhPK-Pb5I-Zok=.30ce38a3-aa3a-4005-9154-e73e4642b747@github.com> On Wed, 3 Jul 2024 02:38:58 GMT, Chen Liang wrote: > Please review this clean backport of #19981 onto JDK 23, fixing `StackMapGenerator` generating static methods with no declared local variable a max local of 1. Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19993#pullrequestreview-2162951672 From duke at openjdk.org Mon Jul 8 11:01:32 2024 From: duke at openjdk.org (Thomas Wuerthinger) Date: Mon, 8 Jul 2024 11:01:32 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: References: Message-ID: <4BqqOjbfNOV6NjtPe-hIf-98N8kT6ce_FBCuQ-vqBBY=.6e02875c-908f-43f0-8d66-ba4f5b01d488@github.com> On Mon, 8 Jul 2024 08:18:42 GMT, Axel Boldt-Christmas wrote: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... OK. Will there be a CSR or JEP for this? When do you approximately expect this to land in main line? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213689308 From liach at openjdk.org Mon Jul 8 11:04:40 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Jul 2024 11:04:40 GMT Subject: [jdk23] Integrated: 8335475: ClassBuilder incorrectly calculates max_locals in some cases In-Reply-To: <2Gb-4i4BJzRxL2YimwmG1ITHcC5TSvpk1NHUr0Une3Q=.100470b5-f8f4-4d04-92a6-a33dbacaf47b@github.com> References: <2Gb-4i4BJzRxL2YimwmG1ITHcC5TSvpk1NHUr0Une3Q=.100470b5-f8f4-4d04-92a6-a33dbacaf47b@github.com> Message-ID: On Wed, 3 Jul 2024 02:38:58 GMT, Chen Liang wrote: > Please review this clean backport of #19981 onto JDK 23, fixing `StackMapGenerator` generating static methods with no declared local variable a max local of 1. This pull request has now been integrated. Changeset: 2f60d368 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/2f60d3684843e42c2c4c3bf628ac6d62dcdfcadb Stats: 32 lines in 2 files changed: 28 ins; 0 del; 4 mod 8335475: ClassBuilder incorrectly calculates max_locals in some cases Reviewed-by: asotona Backport-of: 1ef34c183315b70ddc27c177a2867e30132609f5 ------------- PR: https://git.openjdk.org/jdk/pull/19993 From aboldtch at openjdk.org Mon Jul 8 11:55:33 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 11:55:33 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: <4BqqOjbfNOV6NjtPe-hIf-98N8kT6ce_FBCuQ-vqBBY=.6e02875c-908f-43f0-8d66-ba4f5b01d488@github.com> References: <4BqqOjbfNOV6NjtPe-hIf-98N8kT6ce_FBCuQ-vqBBY=.6e02875c-908f-43f0-8d66-ba4f5b01d488@github.com> Message-ID: On Mon, 8 Jul 2024 10:58:29 GMT, Thomas Wuerthinger wrote: > OK. Will there be a CSR or JEP for this? There is no plan for this, nor should it be required. It?s an internal implementation. > When do you approximately expect this to land in main line? ASAP. Compatibility for the field name is being worked on in Graal JIT. The plan is not to integrate this prior to this work being completed. We should probably add a more graceful transition. Such that `UseObjectMonitorTable` is turned off ergonomically even if the user specified it when running with JVMCI enabled. The main goal here is to get something in main line which does not affect the default behaviour of the VM. But allows for supporting future features such as Lilliput, along with enabling incremental improvement to `UseObjectMonitorTable` via support for more platforms and compiler backends, performance improvements, etc to be done towards the JDK project. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213806034 From aboldtch at openjdk.org Mon Jul 8 12:13:07 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 12:13:07 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v2] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: More graceful JVMCI VM option interaction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/4d835b94..28143503 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From duke at openjdk.org Mon Jul 8 12:18:34 2024 From: duke at openjdk.org (Thomas Wuerthinger) Date: Mon, 8 Jul 2024 12:18:34 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v2] In-Reply-To: References: Message-ID: <15fwghNOC4j6Hctnqn7sVKsRFbHGs7mwcgpadcok1qo=.63b2a07a-2fe0-4557-843d-f6b131e37a09@github.com> On Mon, 8 Jul 2024 12:13:07 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > More graceful JVMCI VM option interaction OK, thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213887069 From jvernee at openjdk.org Mon Jul 8 12:42:44 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 12:42:44 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: <-_t41gD7U_3zgK5CVSa_KPhOzxYbP2xqgfIYR63JnIQ=.62100b2e-85da-49f5-9e7a-0fe8f1525d79@github.com> On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee 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 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/e850014f...1d1ff010 I've lowered the number of reviewers to 1 again, required for the final sign-off. The number of reviewers was set to 2 by Magnus [here](https://github.com/openjdk/jdk/pull/19774#pullrequestreview-2128470410), because he only reviewed the build changes, but those didn't change since his last review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2213965740 From jvernee at openjdk.org Mon Jul 8 12:42:45 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 12:42:45 GMT Subject: Integrated: 8317611: Add a tool like jdeprscan to find usage of restricted methods In-Reply-To: References: Message-ID: On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 This pull request has now been integrated. Changeset: cec222e4 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/cec222e46065fc15db3f2eb241d3607d605ab580 Stats: 2250 lines in 37 files changed: 2235 ins; 0 del; 15 mod 8317611: Add a tool like jdeprscan to find usage of restricted methods Reviewed-by: alanb, ihse, mcimadamore, jlahoda, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/19774 From jvernee at openjdk.org Mon Jul 8 13:13:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 13:13:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10] In-Reply-To: References: Message-ID: On Sat, 29 Jun 2024 06:26:57 GMT, Alan Bateman wrote: > I assume you'll create follow-up issues in JBS for the Class-Path attribute, improvement the usage/help output to replace the "Path"/"String" types. I've filed: https://bugs.openjdk.org/browse/JDK-8335877 and https://bugs.openjdk.org/browse/JDK-8335878 ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2214037164 From asotona at openjdk.org Mon Jul 8 13:13:49 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 8 Jul 2024 13:13:49 GMT Subject: RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Message-ID: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> Class-File API constant pool implementation requires non-zero entry hash code. Unfortunately current implementation computes zero hash code for specific CP entries. This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation and assures all pool entries have non-zero hash. A regression test of the actual zero-hash `IntegerEntry` has been added. All pre-computed hash codes in `BoundAttribute::standardAttribute` are updated. The patch has no performance effect measurable by any of the actual Class-File API benchmarks. Please review. Thanks, Adam ------------- Commit messages: - 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Changes: https://git.openjdk.org/jdk/pull/20074/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20074&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335820 Stats: 56 lines in 4 files changed: 7 ins; 7 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/20074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20074/head:pull/20074 PR: https://git.openjdk.org/jdk/pull/20074 From liach at openjdk.org Mon Jul 8 14:01:32 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Jul 2024 14:01:32 GMT Subject: RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero In-Reply-To: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> References: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> Message-ID: <12kX5b1DpyNgkIu8kCYXSJeUU_6cJgdU1BKWHAcOXaM=.63d3511a-6748-46a5-8720-7ffcd257a46b@github.com> On Mon, 8 Jul 2024 13:09:50 GMT, Adam Sotona wrote: > Class-File API constant pool implementation requires non-zero entry hash code. > Unfortunately current implementation computes zero hash code for specific CP entries. > > This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation and assures all pool entries have non-zero hash. A regression test of the actual zero-hash `IntegerEntry` has been added. > > All pre-computed hash codes in `BoundAttribute::standardAttribute` are updated. > > The patch has no performance effect measurable by any of the actual Class-File API benchmarks. > > Please review. > > Thanks, > Adam src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java line 79: > 77: static int computeHashCode(MethodHandleEntryImpl handle, > 78: List arguments) { > 79: return 31 * handle.hashCode() + arguments.hashCode(); Should we update the algorithm here, as this algorithm processes hash codes of the 2nd last item of arguments and the handle the same, both just multiplied by 31? Also need a copyright year update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20074#discussion_r1668690446 From asotona at openjdk.org Mon Jul 8 14:14:02 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 8 Jul 2024 14:14:02 GMT Subject: RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero [v2] In-Reply-To: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> References: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> Message-ID: > Class-File API constant pool implementation requires non-zero entry hash code. > Unfortunately current implementation computes zero hash code for specific CP entries. > > This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation and assures all pool entries have non-zero hash. A regression test of the actual zero-hash `IntegerEntry` has been added. > > All pre-computed hash codes in `BoundAttribute::standardAttribute` are updated. > > The patch has no performance effect measurable by any of the actual Class-File API benchmarks. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed BootstrapMethodEntryImpl::computeHashCode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20074/files - new: https://git.openjdk.org/jdk/pull/20074/files/9d4a1a2a..d38b2ffb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20074&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20074&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20074/head:pull/20074 PR: https://git.openjdk.org/jdk/pull/20074 From asotona at openjdk.org Mon Jul 8 14:14:02 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 8 Jul 2024 14:14:02 GMT Subject: RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero [v2] In-Reply-To: <12kX5b1DpyNgkIu8kCYXSJeUU_6cJgdU1BKWHAcOXaM=.63d3511a-6748-46a5-8720-7ffcd257a46b@github.com> References: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> <12kX5b1DpyNgkIu8kCYXSJeUU_6cJgdU1BKWHAcOXaM=.63d3511a-6748-46a5-8720-7ffcd257a46b@github.com> Message-ID: On Mon, 8 Jul 2024 13:57:20 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed BootstrapMethodEntryImpl::computeHashCode > > src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java line 79: > >> 77: static int computeHashCode(MethodHandleEntryImpl handle, >> 78: List arguments) { >> 79: return 31 * handle.hashCode() + arguments.hashCode(); > > Should we update the algorithm here, as this algorithm processes hash codes of the 2nd last item of arguments and the handle the same, both just multiplied by 31? > > Also need a copyright year update. Right, BSMEntries are also stored in EntryMap. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20074#discussion_r1668711691 From sgehwolf at openjdk.org Mon Jul 8 14:23:43 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Jul 2024 14:23:43 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Message-ID: Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. ------------- Commit messages: - 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Changes: https://git.openjdk.org/jdk/pull/20076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20076&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335882 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20076/head:pull/20076 PR: https://git.openjdk.org/jdk/pull/20076 From sgehwolf at openjdk.org Mon Jul 8 14:26:32 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Jul 2024 14:26:32 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. @MBaesken Since you've noticed the failing test in your CI could you please verify the issue is gone with this? I don't have an Alpine Linux setup to easily test this exclusion. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214223234 From stuefe at openjdk.org Mon Jul 8 14:32:41 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 8 Jul 2024 14:32:41 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: <3sI4EIbYUqfFhVL1b0SdHJ04q3_lYo7eVijw9R3CqrQ=.7938875e-ef0c-4de4-ac93-54c223da2552@github.com> On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. Seems fine. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20076#pullrequestreview-2163517084 From mbaesken at openjdk.org Mon Jul 8 14:32:42 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 Jul 2024 14:32:42 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:24:12 GMT, Severin Gehwolf wrote: > @MBaesken Since you've noticed the failing test in your CI could you please verify the issue is gone with this? I don't have an Alpine Linux setup to easily test this exclusion. Thanks! Hi Severin, sure ! I put it into our build/test setup . ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214228730 From yzheng at openjdk.org Mon Jul 8 14:55:36 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Mon, 8 Jul 2024 14:55:36 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 12:13:07 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > More graceful JVMCI VM option interaction Could you please revert 2814350 and export the following symbols to JVMCI? diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp index faf2cb24616..7be31aa0f5f 100644 --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp @@ -241,6 +241,7 @@ nonstatic_field(JavaThread, _stack_overflow_state._reserved_stack_activation, address) \ nonstatic_field(JavaThread, _held_monitor_count, intx) \ nonstatic_field(JavaThread, _lock_stack, LockStack) \ + nonstatic_field(JavaThread, _om_cache, OMCache) \ JVMTI_ONLY(nonstatic_field(JavaThread, _is_in_VTMS_transition, bool)) \ JVMTI_ONLY(nonstatic_field(JavaThread, _is_in_tmp_VTMS_transition, bool)) \ JVMTI_ONLY(nonstatic_field(JavaThread, _is_disable_suspend, bool)) \ @@ -531,6 +532,8 @@ \ declare_constant_with_value("CardTable::dirty_card", CardTable::dirty_card_val()) \ declare_constant_with_value("LockStack::_end_offset", LockStack::end_offset()) \ + declare_constant_with_value("OMCache::oop_to_oop_difference", OMCache::oop_to_oop_difference()) \ + declare_constant_with_value("OMCache::oop_to_monitor_difference", OMCache::oop_to_monitor_difference()) \ \ declare_constant(CodeInstaller::VERIFIED_ENTRY) \ declare_constant(CodeInstaller::UNVERIFIED_ENTRY) \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2214322632 From sgehwolf at openjdk.org Mon Jul 8 15:05:33 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Jul 2024 15:05:33 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: <64d4ndFMHM7jY5tvHNMHJgJebojmfmKKa6YlW6MEPew=.2ff2ab15-3647-4708-b1d1-8c7267684956@github.com> On Mon, 8 Jul 2024 14:26:29 GMT, Matthias Baesken wrote: > Hi Severin, sure ! I put it into our build/test setup . Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214368557 From aboldtch at openjdk.org Mon Jul 8 16:21:16 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 16:21:16 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: References: Message-ID: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - Add JVMCI symbol exports - Revert "More graceful JVMCI VM option interaction" This reverts commit 2814350370cf142e130fe1d38610c646039f976d. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/28143503..173b75b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=01-02 Stats: 8 lines in 2 files changed: 3 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From naoto at openjdk.org Mon Jul 8 16:33:36 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Jul 2024 16:33:36 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v17] In-Reply-To: <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com> References: <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com> Message-ID: On Mon, 8 Jul 2024 03:06:17 GMT, Chen Liang wrote: > Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`? > > In the ClassFile API, there are similar "behave as if" notes such as > > https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438 > > , yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same. AFAIK, there will be no behavioral difference, but I think CSR has to be accompanied with this issue to remove that wording, because it is not correct anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2214627225 From darcy at openjdk.org Mon Jul 8 16:46:00 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Jul 2024 16:46:00 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: References: Message-ID: > Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update wording. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20063/files - new: https://git.openjdk.org/jdk/pull/20063/files/3db25519..1182f5d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20063&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20063&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20063/head:pull/20063 PR: https://git.openjdk.org/jdk/pull/20063 From darcy at openjdk.org Mon Jul 8 16:46:00 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Jul 2024 16:46:00 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: References: Message-ID: <6aUZ182n1WDDLJ5Z4gQJWaIcSE9XobwbwEX_OoPIpdY=.dd22d5de-37be-49b3-b54a-fc5883b18153@github.com> On Mon, 8 Jul 2024 09:55:27 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/lang/Object.java line 101: >> >>> 99: * implementation should not use excessive memory or time for its >>> 100: * computations and should return a result for cyclic data >>> 101: * structures. >> >> Hello Joe, adding this text to set the expectations looks reasonable. However, I think the text "should return a result for cyclic data structures." feels a bit odd. If I understand correctly what it's trying to state is that for a class of the form: >> >> >> class Foo { >> Bar bar; >> Foo self; >> >> public void setSelf() { >> this.self = this; >> } >> } >> >> then: >> >> >> Foo foo = new Foo(); >> foo.toString(); // or foo.hashCode() >> >> should be able to return the output from hashCode() and toString() even when an instance of `Foo` has a field which holds the same `Foo` instance. i.e. `toString()` and `hashCode()` should be able to handle re-entrancy and shouldn't consume excessive memory or time. >> >> If that understanding is correct, then maybe we could improve that text to state it differently instead of cyclic data structures? I checked the JDK repo to see if this term has previously been used but it hasn't. Maybe we should just state that the hashCode() toString() methods should be able to deal with re-entrancy? > > My understanding is the same. Personally, the wording reads unambiguously. The words "circular" and "circularity" can be seen throughout codebase, in similar contexts. > > FWIW, a simpler example can be constructed like this: > > var list = new ArrayList<>(); > list.add(list); Changed to "cyclic/circular". The "A" in "DAG" stands for "acyclic", but circular may be more commonly used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1668962044 From rgiulietti at openjdk.org Mon Jul 8 17:06:33 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 8 Jul 2024 17:06:33 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: <6aUZ182n1WDDLJ5Z4gQJWaIcSE9XobwbwEX_OoPIpdY=.dd22d5de-37be-49b3-b54a-fc5883b18153@github.com> References: <6aUZ182n1WDDLJ5Z4gQJWaIcSE9XobwbwEX_OoPIpdY=.dd22d5de-37be-49b3-b54a-fc5883b18153@github.com> Message-ID: On Mon, 8 Jul 2024 16:42:55 GMT, Joe Darcy wrote: >> My understanding is the same. Personally, the wording reads unambiguously. The words "circular" and "circularity" can be seen throughout codebase, in similar contexts. >> >> FWIW, a simpler example can be constructed like this: >> >> var list = new ArrayList<>(); >> list.add(list); > > Changed to "cyclic/circular". > > The "A" in "DAG" stands for "acyclic", but circular may be more commonly used. While I understand and agree with the intent, we have several exceptions in the OpenJDK itself. Circular structures that throw `StackOverflowError` on `hashCode()` and huge numbers that take 20-30 min to compute `toString()` are some examples. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1668991446 From cushon at openjdk.org Mon Jul 8 17:22:40 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 8 Jul 2024 17:22:40 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v7] In-Reply-To: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@github.com> References: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@github.com> Message-ID: On Tue, 4 Jun 2024 17:43:24 GMT, Liam Miller-Cushon wrote: >> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. > > Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8328995 > - Move test to test/jdk/tools/launcher > - Add some more comments > - Maximum Zip64 extra field length is 32 > - Make cendsk an unsigned short > - Fix disk number size > - Improvements > > * don't rely on variable length arrays > * only run the test of 64 bit machines, since it requires >4GB of heap > - 8328995: launcher can't open jar files where the offset of the manifest is >4GB bridgekeeper please keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2214757709 From cushon at openjdk.org Mon Jul 8 17:23:34 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 8 Jul 2024 17:23:34 GMT Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version In-Reply-To: References: Message-ID: On Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon wrote: > This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`. > > The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks. bridgekeeper please keep this open for now ------------- PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2214759381 From jlu at openjdk.org Mon Jul 8 17:34:38 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 8 Jul 2024 17:34:38 GMT Subject: RFR: 8333396: Performance regression of DecimalFormat.format [v17] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 02:32:17 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Performance regression of DecimalFormat.format I believe the `static MessageFormat.format(...` also has similar incorrect "this is equivalent ..." wording, if you could please include that as well. I think we should also rename the issue (and CSR) as well since the scope has changed. Something along the lines of "Use StringBuilder internally for java.text.Format.* formatting". ------------- Changes requested by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2163963773 From liach at openjdk.org Mon Jul 8 17:44:43 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Jul 2024 17:44:43 GMT Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v11] In-Reply-To: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com> References: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com> Message-ID: On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg wrote: >> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`. >> >> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map. >> >> We need to benchmark this solution to better understand its implications. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into vb-map2 > - Fix formatting > - Remove caching in TreeMap > - Remove caching from CHM and CSLM > - Move back clone to original position > - Reintroduce AbstractMap::clone > - Add 'fresh' to implSpec > - Remove AbstractMap::clone > - Merge master > - Merge branch 'master' into vb-map2 > - ... and 4 more: https://git.openjdk.org/jdk/compare/9cce9fe0...b1bfcd17 src/java.base/share/classes/java/util/AbstractMap.java line 322: > 320: public boolean isEmpty() { return AbstractMap.this.isEmpty(); } > 321: public void clear() { AbstractMap.this.clear(); } > 322: public boolean contains(Object k) { return AbstractMap.this.containsKey(k); } Suggestion: public boolean contains(Object k) { return containsKey(k); } Maybe we should have consistency of style. If we qualify here, we should also qualify `AbstractMap.this.new KeyIterator()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1633556698 From alanb at openjdk.org Mon Jul 8 18:07:34 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Jul 2024 18:07:34 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: References: Message-ID: <0vyJdgj-T70dmXLhdOrDV64t_-Eok7KMESnoOa6hRG4=.5b90b799-6bdc-4479-a38d-80795ff9853a@github.com> On Mon, 8 Jul 2024 16:46:00 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Update wording. Specifying that toString returns a non-null result is good. Specifying that the methods don't throw any exceptions, or an implSpec that the methods shouldn't throw is okay. I'm less sure about the proposed wording for resource usage. For hashCode then maybe it should say that the hashCode method may be called very frequently and should be as fast and use as few resources as possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20063#issuecomment-2214849998 From cjplummer at openjdk.org Mon Jul 8 18:16:33 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 8 Jul 2024 18:16:33 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: Message-ID: <8fzuIYuEccEuEH1Qm4yeX4-qKLkN770Pp3HhSvyFxhA=.b2fb581b-9a31-476c-82b1-d62bb776ddf6@github.com> On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote: > There are two similarly names tests. > Recently: > JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range > ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. > > Also removing an old comment about a Solaris issue. test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java line 239: > 237: " > ThreadUserTime = " + utime2); > 238: } > 239: */ Shouldn't this be uncommented and this bit of testing restored? It seems the only reason it was commented out is because of Solaris, which we don't need to worry about anymore. Probably best to leave this to a separate PR if you are going to restore it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20025#discussion_r1669075901 From darcy at openjdk.org Mon Jul 8 19:03:32 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Jul 2024 19:03:32 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: References: <6aUZ182n1WDDLJ5Z4gQJWaIcSE9XobwbwEX_OoPIpdY=.dd22d5de-37be-49b3-b54a-fc5883b18153@github.com> Message-ID: On Mon, 8 Jul 2024 17:04:07 GMT, Raffaello Giulietti wrote: > While I understand and agree with the intent, we have several exceptions in the OpenJDK itself. > > Circular structures that throw `StackOverflowError` on `hashCode()` and huge numbers that take 20-30 min to compute `toString()` are some examples. I wouldn't be surprised if there are some cases like that in the JDK. However, if those types are generally usable outside of the JDK, I would advocate for the implementations being updated to behave better. I added the cyclic/circular guidance in part based on work I did add suppressed exceptions to Throwable in JDK 7. One tricky part of the implementation was making sure the stack trace output did cycle detection since there were various ways exceptions could end up referring to each other. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1669136127 From prappo at openjdk.org Mon Jul 8 19:15:35 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 19:15:35 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: References: <6aUZ182n1WDDLJ5Z4gQJWaIcSE9XobwbwEX_OoPIpdY=.dd22d5de-37be-49b3-b54a-fc5883b18153@github.com> Message-ID: On Mon, 8 Jul 2024 19:01:04 GMT, Joe Darcy wrote: > One tricky part of the implementation was making sure the stack trace output did cycle detection since there were various ways exceptions could end up referring to each other. Yes, the tricky part was to "Guard against malicious overrides of Throwable.equals". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1669152196 From darcy at openjdk.org Mon Jul 8 19:15:36 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Jul 2024 19:15:36 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: References: <6aUZ182n1WDDLJ5Z4gQJWaIcSE9XobwbwEX_OoPIpdY=.dd22d5de-37be-49b3-b54a-fc5883b18153@github.com> Message-ID: <6NnZvhj3BT3-Bl2lHpMnoV-C_6rYIC6IHHd7PqszpZw=.66a93867-9959-4756-a8a0-ef8cf0f74bdc@github.com> On Mon, 8 Jul 2024 19:11:43 GMT, Pavel Rappo wrote: >>> While I understand and agree with the intent, we have several exceptions in the OpenJDK itself. >>> >>> Circular structures that throw `StackOverflowError` on `hashCode()` and huge numbers that take 20-30 min to compute `toString()` are some examples. >> >> I wouldn't be surprised if there are some cases like that in the JDK. However, if those types are generally usable outside of the JDK, I would advocate for the implementations being updated to behave better. >> >> I added the cyclic/circular guidance in part based on work I did add suppressed exceptions to Throwable in JDK 7. One tricky part of the implementation was making sure the stack trace output did cycle detection since there were various ways exceptions could end up referring to each other. > >> One tricky part of the implementation was making sure the stack trace output did cycle detection since there were various ways exceptions could end up referring to each other. > > Yes, the tricky part was to "Guard against malicious overrides of Throwable.equals". > My understanding is the same. Personally, the wording reads unambiguously. The words "circular" and "circularity" can be seen throughout codebase, in similar contexts. > > FWIW, a simpler example can be constructed like this: > > ``` > var list = new ArrayList<>(); > list.add(list); > ``` PS There are cases where cyclic structures are not supported, such as in java.util.Set: " A special case of this prohibition is that it is not permissible for a set to contain itself as an element." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1669153919 From prappo at openjdk.org Mon Jul 8 19:21:32 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 8 Jul 2024 19:21:32 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: <6NnZvhj3BT3-Bl2lHpMnoV-C_6rYIC6IHHd7PqszpZw=.66a93867-9959-4756-a8a0-ef8cf0f74bdc@github.com> References: <6aUZ182n1WDDLJ5Z4gQJWaIcSE9XobwbwEX_OoPIpdY=.dd22d5de-37be-49b3-b54a-fc5883b18153@github.com> <6NnZvhj3BT3-Bl2lHpMnoV-C_6rYIC6IHHd7PqszpZw=.66a93867-9959-4756-a8a0-ef8cf0f74bdc@github.com> Message-ID: On Mon, 8 Jul 2024 19:12:37 GMT, Joe Darcy wrote: > PS There are cases where cyclic structures are not supported, such as in java.util.Set: There are algorithms that also don't support that: /** * Returns a hash code based on the "deep contents" of the specified * array. If the array contains other arrays as elements, the * hash code is based on their contents and so on, ad infinitum. * It is therefore unacceptable to invoke this method on an array that * contains itself as an element, either directly or indirectly through * one or more levels of arrays. The behavior of such an invocation is * undefined. ... */ public static int deepHashCode(Object[] a) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20063#discussion_r1669161910 From darcy at openjdk.org Mon Jul 8 20:32:52 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Jul 2024 20:32:52 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v3] In-Reply-To: References: Message-ID: > Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20063/files - new: https://git.openjdk.org/jdk/pull/20063/files/1182f5d7..66679fb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20063&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20063&range=01-02 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20063/head:pull/20063 PR: https://git.openjdk.org/jdk/pull/20063 From darcy at openjdk.org Mon Jul 8 20:40:34 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Jul 2024 20:40:34 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v2] In-Reply-To: <0vyJdgj-T70dmXLhdOrDV64t_-Eok7KMESnoOa6hRG4=.5b90b799-6bdc-4479-a38d-80795ff9853a@github.com> References: <0vyJdgj-T70dmXLhdOrDV64t_-Eok7KMESnoOa6hRG4=.5b90b799-6bdc-4479-a38d-80795ff9853a@github.com> Message-ID: <-UDUfc-92nRc1oHSPyIMFaizZ-uyhnkG9A8j7hxbUeE=.6bbbe5e0-7a83-47ea-ae0a-9e172aef801d@github.com> On Mon, 8 Jul 2024 18:04:49 GMT, Alan Bateman wrote: > Specifying that toString returns a non-null result is good. Specifying that the methods don't throw any exceptions, or an implSpec that the methods shouldn't throw is okay. > > I'm less sure about the proposed wording for resource usage. For hashCode then maybe it should say that the hashCode method may be called very frequently and should be as fast and use as few resources as possible. Some additional background that I didn't try to put into the guidance, there are certainly contexts where calling the `toString()` or `hashCode()` methods on possibly-not-trusted objects is ill-advised. When you need a string or hash code for an object in those situations, `System.identityHashCode` and `Objects.toIdentityString` can be used. However, I think in many other contexts, and even the default context, you want to be able to call `toString` and `hashCode` on the objects you're using and have them give sensible results. The intention of this change is to make that expectation of usability explicit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20063#issuecomment-2215233823 From liach at openjdk.org Mon Jul 8 20:42:36 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Jul 2024 20:42:36 GMT Subject: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException [v3] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 17:42:23 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Liam Miller-Cushon 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: > > - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent > - Check m.entrySet().hashCode() in MOAT > - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent > - Use AbstractImmutableSet > - Throw UOE for all Map.of().entrySet() mutator methods > - 8328821: Make the ImmutableCollections clear() call consistent > > Without overriding clear(), a call to it in an empty map would > just return, as iterator.hasNext() would be false. However if > calling Map.of().clear() throws an exception. To make the > behavior of Map.of().entrySet().clear() consistent, we need to > have an implementation of clear() for the entry set that throws > as well. test/jdk/java/util/Map/MapFactories.java line 505: > 503: > 504: @Test(expectedExceptions=UnsupportedOperationException.class) > 505: public void immutableEntrySetAddAllDisallowed() { Looking back at MOAT, do you think we should add these into MOAT? https://github.com/openjdk/jdk/blob/598af2e51464be089b64da4024e62865c2c6ec72/test/jdk/java/util/Collection/MOAT.java#L594-L619 We just need to add calls to `testMapMutatorsAlwaysThrow` and `testEmptyMapMutatorsAlwaysThrow` to check `test(Empty)CollMutatorsAlwaysThrow(map.entrySet());`, `test(Empty)CollMutatorsAlwaysThrow(map.keySet());`, and `test(Empty)CollMutatorsAlwaysThrow(map.values());` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1669279616 From duke at openjdk.org Mon Jul 8 21:30:38 2024 From: duke at openjdk.org (duke) Date: Mon, 8 Jul 2024 21:30:38 GMT Subject: Withdrawn: 8322332: Add API to access ZipEntry.extraAttributes In-Reply-To: References: Message-ID: On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan wrote: > Add API to access ZipEntry.extraAttributes This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19204 From rriggs at openjdk.org Tue Jul 9 01:43:36 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 9 Jul 2024 01:43:36 GMT Subject: RFR: 8335637: Add explicit well-behaved expectations to Object.{toString, hashCode} [v3] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 20:32:52 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Looks good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2164737366 From duke at openjdk.org Tue Jul 9 02:06:34 2024 From: duke at openjdk.org (lingjun-cg) Date: Tue, 9 Jul 2024 02:06:34 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v18] In-Reply-To: References: Message-ID: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: 8333396: Use StringBuilder internally for java.text.Format.* formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19513/files - new: https://git.openjdk.org/jdk/pull/19513/files/d675bcbf..5fda8747 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=16-17 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513 From duke at openjdk.org Tue Jul 9 02:37:42 2024 From: duke at openjdk.org (lingjun-cg) Date: Tue, 9 Jul 2024 02:37:42 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v17] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 17:31:53 GMT, Justin Lu wrote: > I believe the `static MessageFormat.format(...` also has similar incorrect "this is equivalent ..." wording, if you could please include that as well. I think we should also rename the issue (and CSR) as well since the scope has changed. Something along the lines of "Use StringBuilder internally for java.text.Format.* formatting". Thanks for checking carefully. Updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2216286724 From dnsimon at openjdk.org Tue Jul 9 07:52:58 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 9 Jul 2024 07:52:58 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation Message-ID: This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. ------------- Commit messages: - improved exception translation between HotSpot and libgraal heaps Changes: https://git.openjdk.org/jdk/pull/20083/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20083&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335553 Stats: 84 lines in 5 files changed: 50 ins; 22 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20083/head:pull/20083 PR: https://git.openjdk.org/jdk/pull/20083 From dnsimon at openjdk.org Tue Jul 9 07:52:58 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 9 Jul 2024 07:52:58 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 19:01:05 GMT, Doug Simon wrote: > This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: > 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). > 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. > 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. > > An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. > > To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. src/hotspot/share/utilities/exceptions.cpp line 114: > 112: #endif // ASSERT > 113: > 114: if (h_exception.is_null() && !thread->can_call_java()) { There is no reason to replace an existing exception object with a dummy exception object in the case where the current thread cannot call into Java. Since the exception object already exists, no Java call is necessary. This change is necessary to allow the libgraal exception translation mechanism to know that an OOME is being translated. src/hotspot/share/utilities/exceptions.cpp line 208: > 206: Handle h_loader, Handle h_protection_domain) { > 207: // Check for special boot-strapping/compiler-thread handling > 208: if (special_exception(thread, file, line, h_cause)) return; This fixes a long standing bug where `special_exception` is being queried with the *cause* of the exception being thrown instead of the *name* of the exception being thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1669153819 PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1669148553 From mbaesken at openjdk.org Tue Jul 9 09:19:32 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 9 Jul 2024 09:19:32 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. Marked as reviewed by mbaesken (Reviewer). The issue is gone in our tests, with your patch added. ------------- PR Review: https://git.openjdk.org/jdk/pull/20076#pullrequestreview-2165630718 PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2217120494 From sgehwolf at openjdk.org Tue Jul 9 10:24:39 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 9 Jul 2024 10:24:39 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. Thanks for the reviews! The docs build failure in GHA is infra related: Run # If runner architecture is x64 set JAVA_HOME_17_X64 otherwise set to JAVA_HOME_17_arm64 [build.sh][INFO] CYGWIN_OR_MSYS=0 [build.sh][INFO] JAVA_HOME: /usr/lib/jvm/temurin-17-jdk-amd64 [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk/jdk/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip Error: sh][ERROR] wget exited with exit code 4 Error: Process completed with exit code 1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2217257118 From sgehwolf at openjdk.org Tue Jul 9 10:24:40 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 9 Jul 2024 10:24:40 GMT Subject: Integrated: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: <804gKEmpNT4ym9osB0uQmqan-qUveSmOVRX_OXBODNU=.4ed36f94-0673-4667-9745-1b023f7b0469@github.com> On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. This pull request has now been integrated. Changeset: f3ff4f74 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/f3ff4f7427c3c3f5cb2a115a61462bb9d28de1cd Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Reviewed-by: stuefe, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/20076 From duke at openjdk.org Tue Jul 9 10:49:06 2024 From: duke at openjdk.org (Vanitha B P) Date: Tue, 9 Jul 2024 10:49:06 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v3] In-Reply-To: References: Message-ID: > Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. > > The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Addressed the review comments based on the inputs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19536/files - new: https://git.openjdk.org/jdk/pull/19536/files/4d22961a..b3275577 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=01-02 Stats: 270 lines in 4 files changed: 129 ins; 141 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19536/head:pull/19536 PR: https://git.openjdk.org/jdk/pull/19536 From galder at openjdk.org Tue Jul 9 12:12:53 2024 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Tue, 9 Jul 2024 12:12:53 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) Message-ID: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@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 2413 2412 1 0 << jtreg:test/langtools:tier1 4556 4556 0 0 jtreg:test/jaxp:tier1 0 0 0 0 jtreg:test/lib-test:tier1 33 33 0 0 ============================== The failure I got is [CODETOOLS-7903745](https://bugs.openjdk.org/browse/CODETOOLS-7903745) so unrelated to these changes. ------------- Commit messages: - 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) Changes: https://git.openjdk.org/jdk/pull/20098/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307513 Stats: 32 lines in 5 files changed: 32 ins; 0 del; 0 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 liach at openjdk.org Tue Jul 9 12:16:32 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 12:16:32 GMT Subject: RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero [v2] In-Reply-To: References: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> Message-ID: <5SEPhbmwErcx4wvD0ClrErgjD0vuUnUAi2C3_jsRoVo=.84966dab-f722-447e-98b6-229b925ffacd@github.com> On Mon, 8 Jul 2024 14:14:02 GMT, Adam Sotona wrote: >> Class-File API constant pool implementation requires non-zero entry hash code. >> Unfortunately current implementation computes zero hash code for specific CP entries. >> >> This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation and assures all pool entries have non-zero hash. A regression test of the actual zero-hash `IntegerEntry` has been added. >> >> All pre-computed hash codes in `BoundAttribute::standardAttribute` are updated. >> >> The patch has no performance effect measurable by any of the actual Class-File API benchmarks. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed BootstrapMethodEntryImpl::computeHashCode Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20074#pullrequestreview-2166140052 From dnsimon at openjdk.org Tue Jul 9 13:46:46 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 9 Jul 2024 13:46:46 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: > This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: > 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). > 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. > 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. > > An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. > > To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: fixed TestTranslatedException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20083/files - new: https://git.openjdk.org/jdk/pull/20083/files/ff544be3..aa32491c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20083&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20083&range=00-01 Stats: 19 lines in 2 files changed: 12 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20083/head:pull/20083 PR: https://git.openjdk.org/jdk/pull/20083 From asemenyuk at openjdk.org Tue Jul 9 14:28:35 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 9 Jul 2024 14:28:35 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v3] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 10:49:06 GMT, Vanitha B P wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Addressed the review comments based on the inputs test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java line 39: > 37: System.out.println("Calc id=" + process.pid()); > 38: System.exit(0); > 39: } The better alternative would be: ```String calcPath = Path.of(System.getenv("SystemRoot"), "system32", "calc.exe").toString();``` This way NPE will be thrown if `SystemRoot` env variable is not set instead of silent exit, and `FS` field is not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1670627437 From yzheng at openjdk.org Tue Jul 9 14:40:33 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Tue, 9 Jul 2024 14:40:33 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote: >> This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: >> 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). >> 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. >> 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. >> >> An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. >> >> To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fixed TestTranslatedException src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 782: > 780: while (true) { > 781: // Trigger an OutOfMemoryError > 782: objArrayOop next = oopFactory::new_objectArray(0x7FFFFFFF, CHECK_NULL); Shall we check for pending exception and break here? test/jdk/jdk/internal/vm/TestTranslatedException.java line 167: > 165: private static void assertThrowableEquals(Throwable originalIn, Throwable decodedIn) { > 166: Throwable original = originalIn; > 167: Throwable decoded = decodedIn; What is the purpose of this renaming? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1670646934 PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1670607742 From dnsimon at openjdk.org Tue Jul 9 14:45:33 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 9 Jul 2024 14:45:33 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 14:37:47 GMT, Yudi Zheng wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed TestTranslatedException > > src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 782: > >> 780: while (true) { >> 781: // Trigger an OutOfMemoryError >> 782: objArrayOop next = oopFactory::new_objectArray(0x7FFFFFFF, CHECK_NULL); > > Shall we check for pending exception and break here? The `CHECK_NULL` macro effectively does that. > test/jdk/jdk/internal/vm/TestTranslatedException.java line 167: > >> 165: private static void assertThrowableEquals(Throwable originalIn, Throwable decodedIn) { >> 166: Throwable original = originalIn; >> 167: Throwable decoded = decodedIn; > > What is the purpose of this renaming? So that the printing down the bottom of this message shows the complete throwable, not just the cause on which the comparison failed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1670656254 PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1670654917 From yzheng at openjdk.org Tue Jul 9 15:01:33 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Tue, 9 Jul 2024 15:01:33 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote: >> This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: >> 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). >> 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. >> 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. >> >> An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. >> >> To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fixed TestTranslatedException LGTM ------------- Marked as reviewed by yzheng (Committer). PR Review: https://git.openjdk.org/jdk/pull/20083#pullrequestreview-2166581323 From yzheng at openjdk.org Tue Jul 9 15:01:34 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Tue, 9 Jul 2024 15:01:34 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 14:42:42 GMT, Doug Simon wrote: >> test/jdk/jdk/internal/vm/TestTranslatedException.java line 167: >> >>> 165: private static void assertThrowableEquals(Throwable originalIn, Throwable decodedIn) { >>> 166: Throwable original = originalIn; >>> 167: Throwable decoded = decodedIn; >> >> What is the purpose of this renaming? > > So that the printing down the bottom of this message shows the complete throwable, not just the cause on which the comparison failed. Thanks! I missed the reassign in the folded unchanged code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1670683400 From duke at openjdk.org Tue Jul 9 15:09:36 2024 From: duke at openjdk.org (Vanitha B P) Date: Tue, 9 Jul 2024 15:09:36 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v3] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 14:26:11 GMT, Alexey Semenyuk wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed the review comments based on the inputs > > test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java line 39: > >> 37: System.out.println("Calc id=" + process.pid()); >> 38: System.exit(0); >> 39: } > > The better alternative would be: > ```String calcPath = Path.of(System.getenv("SystemRoot"), "system32", "calc.exe").toString();``` > > This way NPE will be thrown if `SystemRoot` env variable is not set instead of silent exit, and `FS` field is not needed. Agree, i will make the changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19536#discussion_r1670697556 From martin.desruisseaux at geomatys.com Tue Jul 9 15:49:47 2024 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Tue, 9 Jul 2024 17:49:47 +0200 Subject: Read-only view of ByteArrayInputStream content Message-ID: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> Hello JDK-22 has modified ByteArrayInputStream.transferTo(OutputStream) implementation for performing a defensive copy of the byte array when the destination is not trusted (JDK-8321053). However, I was using the previous implementation as a trick for reading the array without copy. The reason is because we have millions of ByteArrayInputStream instances when reading BLOBs from a database (e.g., geometries from a spatial database), and some popular JDBC drivers implement ResultSet.getBinaryStream(int) by reading all data in a byte[] array and wrapping the array in a ByteArrayInputStream. As a cleaner replacement for my old trick, would it be possible to add something like the following method in ByteArrayInputStream? /** * Returns the remaining content of this input stream as a read-only buffer. * The sequence of remaining bytes in the buffer is the same as the sequence * of bytes that would be returned by {@link #readAllBytes()}. * * @return the remaining content of this input stream, as a read-only buffer */ public synchronized ByteBuffer asByteBuffer() { return ByteBuffer.wrap(buf, pos, count - pos).slice().asReadOnlyBuffer(); } The call to slice() is for blocking callers from accessing the bytes before the current stream position. I assumed that it could be a security issue. If this proposal is acceptable, I can create a pull request. ??? Thanks, ??? ??? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From cstein at openjdk.org Tue Jul 9 15:53:04 2024 From: cstein at openjdk.org (Christian Stein) Date: Tue, 9 Jul 2024 15:53:04 GMT Subject: RFR: 8336012: Fix usages of jtreg-reserved properties Message-ID: Please review this trivial test-only change to resolve a name clash with a jtreg-reserved property by removing the third option to control a test verbosity level via the `test.verbose` system property. The fix assumes that the system property was only used in a manual scenario, like `make test TEST=...` and a `-Dtest.verbose=99` equivalent. For such scenarios, the other two names (for example `-DPrivateInvokeTest.verbose=99`) are still supported. ------------- Commit messages: - JDK-8336012: Fix usages of jtreg-reserved properties Changes: https://git.openjdk.org/jdk/pull/20099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336012 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20099/head:pull/20099 PR: https://git.openjdk.org/jdk/pull/20099 From duke at openjdk.org Tue Jul 9 16:12:58 2024 From: duke at openjdk.org (Vanitha B P) Date: Tue, 9 Jul 2024 16:12:58 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4] In-Reply-To: References: Message-ID: > Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. > > The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Addressed the review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19536/files - new: https://git.openjdk.org/jdk/pull/19536/files/b3275577..964742d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=02-03 Stats: 8 lines in 1 file changed: 1 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19536/head:pull/19536 PR: https://git.openjdk.org/jdk/pull/19536 From archie.cobbs at gmail.com Tue Jul 9 16:17:35 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 9 Jul 2024 11:17:35 -0500 Subject: Read-only view of ByteArrayInputStream content In-Reply-To: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> References: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> Message-ID: On Tue, Jul 9, 2024 at 10:51?AM Martin Desruisseaux < martin.desruisseaux at geomatys.com> wrote: > JDK-22 has modified ByteArrayInputStream.transferTo(OutputStream) > implementation for performing a defensive copy of the byte array when the > destination is not trusted (JDK-8321053). However, I was using the previous > implementation as a trick for reading the array without copy. The reason is > because we have millions of ByteArrayInputStream instances when reading > BLOBs from a database (e.g., geometries from a spatial database), and some > popular JDBC drivers implement ResultSet.getBinaryStream(int) by reading > all data in a byte[] array and wrapping the array in a > ByteArrayInputStream. As a cleaner replacement for my old trick, would it > be possible to add something like the following method in > ByteArrayInputStream? > > /** > * Returns the remaining content of this input stream as a read-only buffer. > * The sequence of remaining bytes in the buffer is the same as the sequence > * of bytes that would be returned by {@link #readAllBytes()}. > * > * @return the remaining content of this input stream, as a read-only buffer > */ > public synchronized ByteBuffer asByteBuffer() { > return ByteBuffer.wrap(buf, pos, count - pos).slice().asReadOnlyBuffer(); > } > > The call to slice() is for blocking callers from accessing the bytes > before the current stream position. I assumed that it could be a security > issue. If this proposal is acceptable, I can create a pull request. > A few random thoughts... First, let's consider what you are optimizing for. The difference in the old vs. new behavior is the use of a 128k temporary transfer buffer. So if I understand this correctly the performance problem you are addressing (in terms of blown cache) is not proportional to the size of the original BLOB, but to at most 128K (in both the old and new cases, you have to scan the entire BLOB, so that's a wash). Does that 128K create a noticeable difference? Anyway, IMHO more interoperability between the different Java "ways of doing things" is good. E.g., converting between Instant and Date, etc. This falls into that category. In fact, in the past I've wished for the reverse - i.e., ByteBuffer.asOutputStream() - and ended up creating a simple wrapper class that does that. So perhaps these two additions could go together - just a thought. Minor nit - the Javadoc would need to clarify that operations on the returned ByteBuffer have no effect on the original OutputStream. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Tue Jul 9 17:19:15 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 17:19:15 GMT Subject: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException [v3] In-Reply-To: References: Message-ID: <8BoG3V4MVDOIIH12n-avrEeWDvZmMYG4r0mgvTGhb0I=.81c701d8-4364-4cfd-971d-62e70d13c36a@github.com> On Mon, 8 Jul 2024 20:39:38 GMT, Chen Liang wrote: >> Liam Miller-Cushon 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: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent >> - Check m.entrySet().hashCode() in MOAT >> - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent >> - Use AbstractImmutableSet >> - Throw UOE for all Map.of().entrySet() mutator methods >> - 8328821: Make the ImmutableCollections clear() call consistent >> >> Without overriding clear(), a call to it in an empty map would >> just return, as iterator.hasNext() would be false. However if >> calling Map.of().clear() throws an exception. To make the >> behavior of Map.of().entrySet().clear() consistent, we need to >> have an implementation of clear() for the entry set that throws >> as well. > > test/jdk/java/util/Map/MapFactories.java line 505: > >> 503: >> 504: @Test(expectedExceptions=UnsupportedOperationException.class) >> 505: public void immutableEntrySetAddAllDisallowed() { > > Looking back at MOAT, do you think we should add these into MOAT? > https://github.com/openjdk/jdk/blob/598af2e51464be089b64da4024e62865c2c6ec72/test/jdk/java/util/Collection/MOAT.java#L594-L619 > > We just need to add calls to `testMapMutatorsAlwaysThrow` and `testEmptyMapMutatorsAlwaysThrow` to check > `test(Empty)CollMutatorsAlwaysThrow(map.entrySet());`, `test(Empty)CollMutatorsAlwaysThrow(map.keySet());`, and `test(Empty)CollMutatorsAlwaysThrow(map.values());` `testCollMutatorsAlwaysThrow` expects a `Collection` (not e.g. a `Collection>`). MOAT could be refactored to handle that case. Do you think that's worth it, or have thoughts about what the cleanest way to do that would be? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1670899976 From rgiulietti at openjdk.org Tue Jul 9 17:30:30 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 9 Jul 2024 17:30:30 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: References: Message-ID: <7MQ-lp8uMVbHj0UV_fsIrH0EuCUShQ7SvqXINbQASlo=.a112cc74-686b-43de-b89c-65141a078992@github.com> On Tue, 2 Jul 2024 01:44:43 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Ensure normalized value in MutableBigInteger initialization with ints Let's agree that the reference for this PR is the [algorithm](https://inria.hal.science/inria-00072113/document) described by Bertot, Magaud and Zimmermann. >From a first reading, the algorithm implemented here appears different in many aspects from the one in the paper, making a direct comparison between the twos rather hard. For example, the paper normalizes the input to an even number of words ("limbs"). AFAIU, this doesn't seem to happen here. There might be good reasons to depart from what is described in the paper, but there's no discussion. To ease the reviewing process, and for the benefit of future maintainers, every departure from the paper should be discussed and mathematically justified to some extent in comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2218267026 From martin.desruisseaux at geomatys.com Tue Jul 9 17:31:09 2024 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Tue, 9 Jul 2024 19:31:09 +0200 Subject: Read-only view of ByteArrayInputStream content In-Reply-To: References: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> Message-ID: <5d86f03f-8646-4650-8111-00da5aca8fb8@geomatys.com> Hello Archie, thanks for the reply. Le 2024-07-09 ? 18 h 17, Archie Cobbs a ?crit?: > The difference in the old vs. new behavior is the use of a 128k > temporary transfer buffer. So if I understand this correctly the > performance problem you are addressing (in terms of blown cache) is > not proportional to the size of the original BLOB, but to at most 128K No, in the previous JDK implementation, no 128 kb transfer buffer was used. The implementation before commit 5cacf21 (September 2023) was as below: public synchronized long transferTo(OutputStream out) throws IOException { int len = count - pos; out.write(buf, pos, len); pos = count; return len; } In above code, buf is a protected field of ByteArrayInputStream with a value specified by user at construction time, so the array can have any size. I was using a custom OutputStream implementation for getting the value of that field, avoiding any form of copy. But this trick does not work anymore since a transfer buffer has been introduced in commit b0d1450 (December 2023). A read-only ByteBuffer would make possible to continue to avoid a copy. ??? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Tue Jul 9 17:46:20 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 17:46:20 GMT Subject: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException [v3] In-Reply-To: <8BoG3V4MVDOIIH12n-avrEeWDvZmMYG4r0mgvTGhb0I=.81c701d8-4364-4cfd-971d-62e70d13c36a@github.com> References: <8BoG3V4MVDOIIH12n-avrEeWDvZmMYG4r0mgvTGhb0I=.81c701d8-4364-4cfd-971d-62e70d13c36a@github.com> Message-ID: On Tue, 9 Jul 2024 17:11:22 GMT, Liam Miller-Cushon wrote: >> test/jdk/java/util/Map/MapFactories.java line 505: >> >>> 503: >>> 504: @Test(expectedExceptions=UnsupportedOperationException.class) >>> 505: public void immutableEntrySetAddAllDisallowed() { >> >> Looking back at MOAT, do you think we should add these into MOAT? >> https://github.com/openjdk/jdk/blob/598af2e51464be089b64da4024e62865c2c6ec72/test/jdk/java/util/Collection/MOAT.java#L594-L619 >> >> We just need to add calls to `testMapMutatorsAlwaysThrow` and `testEmptyMapMutatorsAlwaysThrow` to check >> `test(Empty)CollMutatorsAlwaysThrow(map.entrySet());`, `test(Empty)CollMutatorsAlwaysThrow(map.keySet());`, and `test(Empty)CollMutatorsAlwaysThrow(map.values());` > > `testCollMutatorsAlwaysThrow` expects a `Collection` (not e.g. a `Collection>`). MOAT could be refactored to handle that case. Do you think that's worth it, or have thoughts about what the cleanest way to do that would be? There is `testImmutableCollection`/`testImmutableSet` that takes an arbitrary nonexistent item for insertion/removal: https://github.com/openjdk/jdk/blob/598af2e51464be089b64da4024e62865c2c6ec72/test/jdk/java/util/Collection/MOAT.java#L665 I think a refactor of a generic `testCollMutatorsAlwaysThrow(Collection c, T t)` and delegating the original Integer version to call `testCollMutatorsAlwaysThrow(c, ABSENT_VALUE)` would not be invasive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1670934363 From duke at openjdk.org Tue Jul 9 18:01:23 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 9 Jul 2024 18:01:23 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: <7MQ-lp8uMVbHj0UV_fsIrH0EuCUShQ7SvqXINbQASlo=.a112cc74-686b-43de-b89c-65141a078992@github.com> References: <7MQ-lp8uMVbHj0UV_fsIrH0EuCUShQ7SvqXINbQASlo=.a112cc74-686b-43de-b89c-65141a078992@github.com> Message-ID: On Tue, 9 Jul 2024 17:17:48 GMT, Raffaello Giulietti wrote: > Let's agree that the reference for this PR is the [algorithm](https://inria.hal.science/inria-00072113/document) described by Bertot, Magaud and Zimmermann. > > From a first reading, the algorithm implemented here appears different in many aspects from the one in the paper, making a direct comparison between the twos rather hard. For example, the paper normalizes the input to an even number of words ("limbs"). AFAIU, this doesn't seem to happen here. There might be good reasons to depart from what is described in the paper, but there's no discussion. > > To ease the reviewing process, and for the benefit of future maintainers, every departure from the paper should be discussed and mathematically justified to some extent in comments. @rgiulietti The input is normalized in the method called `sqrtRemZimmermann`, and is normalized to a number of words which is a multiple of 4, and of course a multiple of 4 is even. For speed, the normalization is performed only "logically", which means that the contents of the input are not changed, but only its logical length, which is stored in the variable `len`. The reason why the length is normalized to a mutiple of 4 is that, in this way, the input can be always split in blocks of words without twiddling with bits. I am completely available for further clarifications regarding the algorithm code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2218328258 From rgiulietti at openjdk.org Tue Jul 9 18:07:17 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 9 Jul 2024 18:07:17 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 01:44:43 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Ensure normalized value in MutableBigInteger initialization with ints These helpful considerations, and others that are not obvious when comparing with the paper, should really be part of comments in the code. As mentioned, this helps with reviewing and for maintenance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2218338467 From duke at openjdk.org Tue Jul 9 18:12:25 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 9 Jul 2024 18:12:25 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 18:04:43 GMT, Raffaello Giulietti wrote: > These helpful considerations, and others that are not obvious when comparing with the paper, should really be part of comments in the code. As mentioned, this helps with reviewing and for maintenance. @rgiulietti I will add the above informations as comments in the code. If there are other parts that need to be clarified, please let me know. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2218346785 From archie.cobbs at gmail.com Tue Jul 9 18:14:07 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 9 Jul 2024 13:14:07 -0500 Subject: Read-only view of ByteArrayInputStream content In-Reply-To: <5d86f03f-8646-4650-8111-00da5aca8fb8@geomatys.com> References: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> <5d86f03f-8646-4650-8111-00da5aca8fb8@geomatys.com> Message-ID: Hi Martin, On Tue, Jul 9, 2024 at 12:31?PM Martin Desruisseaux < martin.desruisseaux at geomatys.com> wrote: > I was using a custom OutputStream implementation for getting the value of > that field, avoiding any form of copy. > Gotcha - so in other words, you want a way to effectively "unwrap" the original byte[] array so you can access the whole thing at one time (random access), as opposed to just accessing it in online fashion as a stream of bytes. It seems that the root of this dilemma is really the java.sql API. For example, you would think there should be a method java.sql.Blob.asByteBuffer() (and Clob.asCharBuffer()). Maybe adding such methods would be a more precise way to fix this. In looking at this, I noticed that Blob.getBytes() does not specify whether, when the entire array is asked for, a copy must (or must not) be returned. So you can't rely on that method for any particular behavior either. Basically, the BLOB API seems clearly designed to allow the implementation to stream the data on demand if it wants to (which is good), but as a side effect it doesn't provide a way for the caller to guarantee avoidance of copying the entire array (if the implementation happens to not stream the data on demand). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgiulietti at openjdk.org Tue Jul 9 18:16:18 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 9 Jul 2024 18:16:18 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 01:44:43 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Ensure normalized value in MutableBigInteger initialization with ints Everything not obvious that departs from the paper by Bertot, Magaud and Zimmermann should be commented. Unfortunately, I can't say precisely what and to which extent until I see a first version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2218355974 From duke at openjdk.org Tue Jul 9 18:27:24 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 9 Jul 2024 18:27:24 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 18:14:03 GMT, Raffaello Giulietti wrote: > Everything not obvious that departs from the paper by Bertot, Magaud and Zimmermann should be commented. Unfortunately, I can't say precisely what and to which extent until I see a first version. @rgiulietti Well. Regarding the method `sqrtRemZimmermann()`, the base case is different fundamentally because in the paper there's no base case at all and the implementation is left to the reader. For the recursive step, apart from the considerations above, the rest of the implementation is based on the pseudocode in the papers, and every difference is based on considerations that are present in the two papers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2218373924 From liach at openjdk.org Tue Jul 9 18:34:35 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 18:34:35 GMT Subject: RFR: 8335935: Chained builders not sending transformed models to next transforms Message-ID: Please review the fix for a major transformation bug within the ClassFile API, where certain kinds of buffered elements produced by one transform is not sent to the next, and the "chained" (`andThen` transformation chains) builders returning the wrong builder for call chains. This is intended to be backported to JDK 23, as this has significant impact on user experience with ClassFile API transformations. The backport won't be clean as we already renamed `ClassFile.transform` to `transformClass`, which will be reverted in the backport. ------------- Commit messages: - JDK-8335935: Chained builders not sending transformed models to next transforms Changes: https://git.openjdk.org/jdk/pull/20100/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335935 Stats: 293 lines in 10 files changed: 169 ins; 97 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/20100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20100/head:pull/20100 PR: https://git.openjdk.org/jdk/pull/20100 From jlu at openjdk.org Tue Jul 9 18:41:24 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 9 Jul 2024 18:41:24 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v18] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 02:06:34 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Use StringBuilder internally for java.text.Format.* formatting Thanks for the changes. Let's work to get the CSR in good shape now. (I have left comments directly on the CSR). ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2167093930 From martin.desruisseaux at geomatys.com Tue Jul 9 18:42:35 2024 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Tue, 9 Jul 2024 20:42:35 +0200 Subject: Read-only view of ByteArrayInputStream content In-Reply-To: References: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> <5d86f03f-8646-4650-8111-00da5aca8fb8@geomatys.com> Message-ID: <493e1579-6373-4047-9a2a-4427f10f9856@geomatys.com> Le 2024-07-09 ? 20 h 14, Archie Cobbs a ?crit?: > Gotcha - so in other words, you want a way to effectively "unwrap" the > original byte[] array so you can access the whole thing at one time > (random access), as opposed to just accessing it in online fashion as > a stream of bytes. > Indeed, I wanted to "unwrap" the original byte[] array. But the goal was not that much for random access (I could get the same with readAllBytes()), but rather to avoid unnecessary array copies. > Basically, the BLOB API seems clearly designed to allow the > implementation to stream the data on demand if it wants to (which is > good), but as a side effect it doesn't provide a way for the caller to > guarantee avoidance of copying the entire array (if the implementation > happens to not stream the data on demand). > Right. The wish to "unwrap" the ByteArrayInputStream original array come from the empirical observation that many of the JDBC drivers that we are using do not stream. Therefore, our code was like: while (resultSet.next()) { // Potentially millions of rows try (InputStream in = resultSet.getBinaryStream(blobColumn)) { if (in instanceof ByteArrayInputStream) { unwrap the original array without copy } else { slower path with streaming } } } For the "unwrap the array" part, a read-only ByteBuffer would be fine. Hence the proposal for adding a ByteArrayInputStream.asByteBuffer() method. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlu at openjdk.org Tue Jul 9 18:49:44 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 9 Jul 2024 18:49:44 GMT Subject: RFR: 8335668: NumberFormat integer only parsing should throw exception for edge case Message-ID: Please review this PR which corrects a case in NumberFormat integer only parsing. [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, var fmt = NumberFormat.getIntegerInstance(); fmt.parse(".5", new ParsePosition(0)); // should return null, not 0 The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex. In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity. ------------- Commit messages: - clean up + add more general test cases - init Changes: https://git.openjdk.org/jdk/pull/20101/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335668 Stats: 65 lines in 3 files changed: 54 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20101/head:pull/20101 PR: https://git.openjdk.org/jdk/pull/20101 From liach at openjdk.org Tue Jul 9 18:51:25 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 18:51:25 GMT Subject: RFR: 8335642: Hide Transform implementation for Class-File API Message-ID: Removes ClassFile API transformation implementation details accidentally leaked to public API. Users don't have access to classes necessary to correctly implement these transform resolutions. In addition, removed improper `canWriteDirect` and made `ClassFileBuilder::transform` chain returns. Replaces #19928. ------------- Commit messages: - 8335642: Hide Transform implementation for Class-File API Changes: https://git.openjdk.org/jdk/pull/20102/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20102&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335642 Stats: 169 lines in 10 files changed: 28 ins; 100 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/20102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20102/head:pull/20102 PR: https://git.openjdk.org/jdk/pull/20102 From lowasser at google.com Tue Jul 9 18:50:53 2024 From: lowasser at google.com (Louis Wasserman) Date: Tue, 9 Jul 2024 11:50:53 -0700 Subject: More useful structured concurrency stack traces Message-ID: My understanding of the structured concurrency APIs now in preview is that when a subtask is forked, exceptions thrown in that stack trace will have stack traces going up to the beginning of that subtask, not e.g. up the structured concurrency task tree. (My tests suggest this is the case for simple virtual threads without structured concurrency.) Most concurrency frameworks on the JVM that I?ve encountered share the property that stack traces for exceptions don?t trace through the entire causal chain ? and, not unrelatedly, that developers struggle to debug concurrent applications, especially with stack traces from production and not full debuggers attached. In some cases, like chained CompletableFutures, this seems necessary to ensure that executing what amounts to a loop does not result in stack traces that grow linearly with the number of chained futures. But when structured concurrency is involved, it seems more plausible to me that the most useful possible stack traces would go up the tree of tasks ? that is, whenever a task was forked, the stack trace would look roughly as if it were a normal/sequential/direct invocation of the task. This could conceivably cause stack overflows where they didn?t happen before, but only for code that violates the expectations we have around normal sequential code: you can?t recurse unboundedly; use iteration instead. I?m curious if there are ways we could make the upcoming structured concurrency APIs give those stack traces all the way up the tree, or provide hooks to enable you to do that yourself. Last year?s JVMLS talk on Continuations Under the Covers demonstrated how stacks were redesigned in ways that frequently and efficiently snapshot the stack itself ? not just the trace, but the thing that includes all the variables in use. There?s a linked list of StackChunks, and all but maybe the top of the stack has those elements frozen, etc, and the top of the stack gets frozen when the thread is yielded. Without certainty about how stack traces are managed in the JVM today, I would imagine you could possibly do something similar ? you?d add a way to cheaply snapshot a reference to the current stack trace that can be traversed later. If you?re willing to hold on to all the references currently on the stack ? which might be acceptable for the structured concurrency case in particular, where you might be able to assume you?ll return to the parent task and its stack at some point ? you might be able to do this by simply wrapping the existing StackChunks. Then, each `fork` or `StructuredTaskScope` creation might snapshot the current call stack, and you?d stitch together the stack traces later?somewhere. That part is a little more open ended: would you add a new variant of `fillInStackTrace`? Would it only apply to exceptions that bubbled up to the task scope? Or would we be adding new semantics to what happens when you throw an exception or walk the stack in general? The most plausible vision I have at this point is an API that spawns a virtual thread which receives a stack trace of some sort ? or perhaps snapshots the current stack trace ? and prepends that trace to all stack traces within the virtual thread?s execution. I suppose this is doable today if you?re willing to pay the performance cost of explicitly getting the current stack trace every time you fork a task or start a scope. That is kind of antithetical to the point of virtual threads ? making forking tasks very efficient ? but it?s something you might be willing to turn on during testing. Right now, my inspiration for this question is attempting to improve the stack trace situation with Kotlin coroutines, where Google production apps have complained about the difficulty of debugging with the current stack traces. But this is something I'd expect to apply equally well to all JVM languages: the ability to snapshot and string together stack trace causal chains like this in production could significantly improve the experience of debugging concurrent code. -- Louis Wasserman -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila at openjdk.org Tue Jul 9 18:56:16 2024 From: attila at openjdk.org (Attila Szegedi) Date: Tue, 9 Jul 2024 18:56:16 GMT Subject: RFR: 8325679: Optimize ArrayList subList sort [v4] In-Reply-To: References: Message-ID: On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi wrote: >> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. >> >> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on. > > Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision: > > Remove test Keep it open, please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-2218421921 From liach at openjdk.org Tue Jul 9 19:00:45 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 19:00:45 GMT Subject: RFR: 8335642: Hide Transform implementation for Class-File API [v2] In-Reply-To: References: Message-ID: > Removes ClassFile API transformation implementation details accidentally leaked to public API. Users don't have access to classes necessary to correctly implement these transform resolutions. In addition, removed improper `canWriteDirect` and made `ClassFileBuilder::transform` chain returns. > > Replaces #19928. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: return tag required ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20102/files - new: https://git.openjdk.org/jdk/pull/20102/files/9b40fb76..a36dea5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20102&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20102&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20102/head:pull/20102 PR: https://git.openjdk.org/jdk/pull/20102 From Alan.Bateman at oracle.com Tue Jul 9 19:10:36 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 9 Jul 2024 20:10:36 +0100 Subject: More useful structured concurrency stack traces In-Reply-To: References: Message-ID: Probably best to bring this to loom-dev as there have been some exploration into but where we decided not to expose any APIs at this time. -Alan On 09/07/2024 19:50, Louis Wasserman wrote: > My understanding of the structured concurrency APIs now in preview is > that when a subtask is forked, exceptions thrown in that stack trace > will have stack traces going up to the beginning of that subtask, not > e.g. up the structured concurrency task tree. ?(My tests suggest this > is the case for simple virtual threads without structured > concurrency.) ?Most concurrency frameworks on the JVM that I?ve > encountered share the property that stack traces for exceptions don?t > trace through the entire causal chain ? and, not unrelatedly, that > developers struggle to debug concurrent applications, especially with > stack traces from production and not full debuggers attached. > > In some cases, like chained CompletableFutures, this seems necessary > to ensure that executing what amounts to a loop does not result in > stack traces that grow linearly with the number of chained futures.? > But when structured concurrency is involved, it seems more plausible > to me that the most useful possible stack traces would go up the tree > of tasks ? that is, whenever a task was forked, the stack trace would > look roughly as if it were a normal/sequential/direct invocation of > the task.? This could conceivably cause stack overflows where they > didn?t happen before, but only for code that violates the expectations > we have around normal sequential code: you can?t recurse unboundedly; > use iteration instead. > > I?m curious if there are ways we could make the upcoming structured > concurrency APIs give those stack traces all the way up the tree, or > provide hooks to enable you to do that yourself.? Last year?s JVMLS > talk on Continuations Under the Covers demonstrated how stacks were > redesigned in ways that frequently and efficiently snapshot the stack > itself ? not just the trace, but the thing that includes all the > variables in use.? There?s a linked list of StackChunks, and all but > maybe the top of the stack has those elements frozen, etc, and the top > of the stack gets frozen when the thread is yielded.? Without > certainty about how stack traces are managed in the JVM today, I would > imagine you could possibly do something similar ? you?d add a way to > cheaply snapshot a reference to the current stack trace that can be > traversed later.? If you?re willing to hold on to all the references > currently on the stack ? which might be acceptable for the structured > concurrency case in particular, where you might be able to assume > you?ll return to the parent task and its stack at some point ? you > might be able to do this by simply wrapping the existing StackChunks.? > Then, each `fork` or `StructuredTaskScope` creation might snapshot the > current call stack, and you?d stitch together the stack traces > later?somewhere.? That part is a little more open ended: would you add > a new variant of `fillInStackTrace`?? Would it only apply to > exceptions that bubbled up to the task scope?? Or would we be adding > new semantics to what happens when you throw an exception or walk the > stack in general?? The most plausible vision I have at this point is > an API that spawns a virtual thread which receives a stack trace of > some sort ? or perhaps snapshots the current stack trace ? and > prepends that trace to all stack traces within the virtual thread?s > execution. > > I suppose this is doable today if you?re willing to pay the > performance cost of explicitly getting the current stack trace every > time you fork a task or start a scope.? That is kind of antithetical > to the point of virtual threads ? making forking tasks very efficient > ? but it?s something you might be willing to turn on during testing. > > Right now, my inspiration for this question is attempting to improve > the stack trace situation with Kotlin coroutines, where Google > production apps have complained about the difficulty of debugging with > the current stack traces.? But this is something I'd expect to apply > equally well to all JVM languages: the ability to snapshot and string > together stack trace causal chains like this in production could > significantly improve the experience of debugging concurrent code. > > -- > Louis Wasserman -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Tue Jul 9 19:23:54 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 19:23:54 GMT Subject: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException [v4] In-Reply-To: References: Message-ID: > This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. Liam Miller-Cushon 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: - Also throw UOE for mutators on keySet() and values() and add more test coverage to MOAT. - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent - Check m.entrySet().hashCode() in MOAT - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent - Use AbstractImmutableSet - Throw UOE for all Map.of().entrySet() mutator methods - 8328821: Make the ImmutableCollections clear() call consistent Without overriding clear(), a call to it in an empty map would just return, as iterator.hasNext() would be false. However if calling Map.of().clear() throws an exception. To make the behavior of Map.of().entrySet().clear() consistent, we need to have an implementation of clear() for the entry set that throws as well. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18522/files - new: https://git.openjdk.org/jdk/pull/18522/files/598af2e5..4c9a511f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=02-03 Stats: 30615 lines in 772 files changed: 17927 ins; 10197 del; 2491 mod Patch: https://git.openjdk.org/jdk/pull/18522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522 PR: https://git.openjdk.org/jdk/pull/18522 From cushon at openjdk.org Tue Jul 9 19:23:54 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 19:23:54 GMT Subject: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException [v3] In-Reply-To: References: <8BoG3V4MVDOIIH12n-avrEeWDvZmMYG4r0mgvTGhb0I=.81c701d8-4364-4cfd-971d-62e70d13c36a@github.com> Message-ID: <9ySjSWFn7g2f4oGoWZjmkjF9Srt86cqsihlndadScCY=.1873ca41-4e99-4ec0-a76f-dce858e712c7@github.com> On Tue, 9 Jul 2024 17:43:32 GMT, Chen Liang wrote: >> `testCollMutatorsAlwaysThrow` expects a `Collection` (not e.g. a `Collection>`). MOAT could be refactored to handle that case. Do you think that's worth it, or have thoughts about what the cleanest way to do that would be? > > There is `testImmutableCollection`/`testImmutableSet` that takes an arbitrary nonexistent item for insertion/removal: https://github.com/openjdk/jdk/blob/598af2e51464be089b64da4024e62865c2c6ec72/test/jdk/java/util/Collection/MOAT.java#L665 > I think a refactor of a generic `testCollMutatorsAlwaysThrow(Collection c, T t)` and delegating the original Integer version to call `testCollMutatorsAlwaysThrow(c, ABSENT_VALUE)` would not be invasive. Thanks! Done. That pointed out that the mutators on `keySet()` and `values()` were not throwing UOE, so I have tentatively updated the PR to also fix that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1671039819 From liach at openjdk.org Tue Jul 9 19:26:19 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 19:26:19 GMT Subject: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException [v3] In-Reply-To: <9ySjSWFn7g2f4oGoWZjmkjF9Srt86cqsihlndadScCY=.1873ca41-4e99-4ec0-a76f-dce858e712c7@github.com> References: <8BoG3V4MVDOIIH12n-avrEeWDvZmMYG4r0mgvTGhb0I=.81c701d8-4364-4cfd-971d-62e70d13c36a@github.com> <9ySjSWFn7g2f4oGoWZjmkjF9Srt86cqsihlndadScCY=.1873ca41-4e99-4ec0-a76f-dce858e712c7@github.com> Message-ID: On Tue, 9 Jul 2024 19:19:41 GMT, Liam Miller-Cushon wrote: >> There is `testImmutableCollection`/`testImmutableSet` that takes an arbitrary nonexistent item for insertion/removal: https://github.com/openjdk/jdk/blob/598af2e51464be089b64da4024e62865c2c6ec72/test/jdk/java/util/Collection/MOAT.java#L665 >> I think a refactor of a generic `testCollMutatorsAlwaysThrow(Collection c, T t)` and delegating the original Integer version to call `testCollMutatorsAlwaysThrow(c, ABSENT_VALUE)` would not be invasive. > > Thanks! Done. > > That pointed out that the mutators on `keySet()` and `values()` were not throwing UOE, so I have tentatively updated the PR to also fix that. Thank you for this more comprehensive update! Definitely an improvement to bring the UOE behavior to all 3 of these view collections. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1671043314 From naoto at openjdk.org Tue Jul 9 19:46:18 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Jul 2024 19:46:18 GMT Subject: RFR: 8335668: NumberFormat integer only parsing should throw exception for edge case In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 18:42:25 GMT, Justin Lu wrote: > Please review this PR which corrects a case in NumberFormat integer only parsing. > > [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, > > > var fmt = NumberFormat.getIntegerInstance(); > fmt.parse(".5", new ParsePosition(0)); // should return null, not 0 > > > The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex. > > In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity. The fix looks good. A couple of comments on tests. test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 146: > 144: @EnabledIfSystemProperty(named = "user.language", matches = "en") > 145: public void compactIntegerParseOnlyFractionOnlyTest() { > 146: var fmt = NumberFormat.getIntegerInstance(); Should it get a compact number instance, instead of integer? test/jdk/java/text/Format/NumberFormat/StrictParseTest.java line 221: > 219: @EnabledIfSystemProperty(named = "user.language", matches = "en") > 220: public void compactIntegerParseOnlyFractionOnlyTest() { > 221: var fmt = NumberFormat.getIntegerInstance(); same here ------------- PR Review: https://git.openjdk.org/jdk/pull/20101#pullrequestreview-2167273474 PR Review Comment: https://git.openjdk.org/jdk/pull/20101#discussion_r1671085244 PR Review Comment: https://git.openjdk.org/jdk/pull/20101#discussion_r1671086182 From aturbanov at openjdk.org Tue Jul 9 20:00:22 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 9 Jul 2024 20:00:22 GMT Subject: RFR: 8335182: Consolidate and streamline String concat code shapes [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 12:39:32 GMT, Claes Redestad wrote: >> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape >> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. >> >> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements): >> >> >> Name Cnt Base Error Test Error Unit Change >> StringConcat.concat13String 50 66.380 ? 0.189 53.017 ? 0.241 ns/op 1.25x (p = 0.000*) >> StringConcat.concat4String 50 13.620 ? 0.053 12.382 ? 0.089 ns/op 1.10x (p = 0.000*) >> StringConcat.concat6String 50 17.168 ? 0.070 16.046 ? 0.064 ns/op 1.07x (p = 0.000*) >> StringConcat.concatConst2String 50 9.820 ? 0.081 8.158 ? 0.041 ns/op 1.20x (p = 0.000*) >> StringConcat.concatConst4String 50 14.938 ? 0.124 12.800 ? 0.049 ns/op 1.17x (p = 0.000*) >> StringConcat.concatConst6Object 50 56.115 ? 0.288 54.046 ? 0.214 ns/op 1.04x (p = 0.000*) >> StringConcat.concatConst6String 50 19.032 ? 0.073 16.213 ? 0.093 ns/op 1.17x (p = 0.000*) >> StringConcat.concatConstBoolByte 50 8.486 ? 0.066 8.556 ? 0.050 ns/op 0.99x (p = 0.004*) >> StringConcat.concatConstInt 50 8.942 ? 0.052 7.677 ? 0.029 ns/op 1.16x (p = 0.000*) >> StringConcat.concatConstIntConstInt 50 12.883 ? 0.070 12.431 ? 0.070 ns/op 1.04x (p = 0.000*) >> StringConcat.concatConstString 50 7.523 ? 0.050 7.486 ? 0.044 ns/op 1.00x (p = 0.058 ) >> StringConcat.concatConstStringConstInt 50 11.961 ? 0.032 11.699 ? 0.049 ns/op 1.02x (p = 0.000*) >> StringConcat.concatEmptyConstInt 50 7.778 ? 0.038 7.723 ? 0.037 ns/op 1.01x (p = 0.000*) >> StringConcat.concatEmptyConstString 50 3.506 ? 0.026 3.505 ? 0.015 ns/op 1.00x (p = 0.930 ) >> StringConcat.concatEmptyLeft 50 3.573 ? 0.075 3.518 ? 0.057 ns/op 1.02x (p = 0.044 ) >> StringConcat.concatEmptyRight 50 3.713 ? 0.049 3.622 ? 0.053 ns/op 1.02x (p = 0.000*) >> StringConcat.concatMethodConstString 50 7.418 ? 0.030 7.478 ? 0.066 ns/op 0.99x (p... > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 182: > 180: concat = "" + "S" + "S" + c + d + z + l + d + z + f + b + d + z + S + f; > 181: concat = "" + b + d + z + d + i + z + d + b + d + "S" + c + f + d; > 182: concat = "" + d + s + f + c + i + "S" + b + b + S + i + s + d + "S" + f; Suggestion: concat = "" + d + s + f + c + i + "S" + b + b + S + i + s + d + "S" + f; test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 191: > 189: concat = "" + z + S + S + "S" + S + S + z + b + S + z + b + f + s + l; > 190: concat = "" + s + z + d + "S" + z + l + f + z + s + z + d + l + s + l; > 191: concat = "" + l + d + i + s + i + c + i + f + b + f + s + b + s + s; Suggestion: concat = "" + l + d + i + s + i + c + i + f + b + f + s + b + s + s; test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 193: > 191: concat = "" + l + d + i + s + i + c + i + f + b + f + s + b + s + s; > 192: concat = "" + z + "S" + S + "S" + "S" + i + "S" + s + d + z + l; > 193: concat = "" + i + S + S + "S" + f + "S" + "S" + z + S + z + b + z + c + b; Suggestion: concat = "" + i + S + S + "S" + f + "S" + "S" + z + S + z + b + z + c + b; test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 223: > 221: concat = "" + "S" + f + S + i + i + i + "S" + i + i + l + c + l + S + S + z + b + i + c + f + S; > 222: concat = "" + c + z + S + S + b + i + c; > 223: concat = "" + S + s + S + c; Suggestion: concat = "" + S + s + S + c; test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 310: > 308: concat = "" + "S" + "S" + c + d + z + l + d + z + f + b + d + z + S + f; > 309: concat = "" + b + d + z + d + i + z + d + b + d + "S" + c + f + d; > 310: concat = "" + d + s + f + c + i + "S" + b + b + S + i + s + d + "S" + f; Suggestion: concat = "" + d + s + f + c + i + "S" + b + b + S + i + s + d + "S" + f; test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 319: > 317: concat = "" + z + S + S + "S" + S + S + z + b + S + z + b + f + s + l; > 318: concat = "" + s + z + d + "S" + z + l + f + z + s + z + d + l + s + l; > 319: concat = "" + l + d + i + s + i + c + i + f + b + f + s + b + s + s; Suggestion: concat = "" + l + d + i + s + i + c + i + f + b + f + s + b + s + s; test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 321: > 319: concat = "" + l + d + i + s + i + c + i + f + b + f + s + b + s + s; > 320: concat = "" + z + "S" + S + "S" + "S" + i + "S" + s + d + z + l; > 321: concat = "" + i + S + S + "S" + f + "S" + "S" + z + S + z + b + z + c + b; Suggestion: concat = "" + i + S + S + "S" + f + "S" + "S" + z + S + z + b + z + c + b; test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java line 351: > 349: concat = "" + "S" + f + S + i + i + i + "S" + i + i + l + c + l + S + S + z + b + i + c + f + S; > 350: concat = "" + c + z + S + S + b + i + c; > 351: concat = "" + S + s + S + c; Suggestion: concat = "" + S + s + S + c; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671144502 PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671145212 PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671145894 PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671146624 PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671147198 PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671147720 PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671148208 PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1671148704 From duke at openjdk.org Tue Jul 9 20:03:21 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 9 Jul 2024 20:03:21 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v22] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 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 53 additional commits since the last revision: - Merge branch 'openjdk:master' into patchSqrt - Ensure normalized value in MutableBigInteger initialization with ints - Merge branch 'openjdk:master' into patchSqrt - Added documentation - An optimization - Reverted changes in BigDecimal - Merge branch 'openjdk:master' into patchSqrt - Added "throw" to throw the ArithmeticException created - Correct BigDecimal.sqrt() - Simplified computing square root of BigDecimal using BigInteger.sqrt() - ... and 43 more: https://git.openjdk.org/jdk/compare/aa8fe60e...9aa7fdca ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/b28f034b..9aa7fdca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=20-21 Stats: 11590 lines in 439 files changed: 7143 ins; 2562 del; 1885 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Tue Jul 9 20:06:40 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 9 Jul 2024 20:06:40 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/9aa7fdca..95be919e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=21-22 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From jlu at openjdk.org Tue Jul 9 20:29:48 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 9 Jul 2024 20:29:48 GMT Subject: RFR: 8335668: NumberFormat integer only parsing should throw exception for edge case [v2] In-Reply-To: References: Message-ID: > Please review this PR which corrects a case in NumberFormat integer only parsing. > > [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, > > > var fmt = NumberFormat.getIntegerInstance(); > fmt.parse(".5", new ParsePosition(0)); // should return null, not 0 > > > The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex. > > In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20101/files - new: https://git.openjdk.org/jdk/pull/20101/files/522b8381..a11d3468 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20101&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20101&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20101/head:pull/20101 PR: https://git.openjdk.org/jdk/pull/20101 From jlu at openjdk.org Tue Jul 9 20:29:48 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 9 Jul 2024 20:29:48 GMT Subject: RFR: 8335668: NumberFormat integer only parsing should throw exception for edge case [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 19:41:29 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect review > > test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 146: > >> 144: @EnabledIfSystemProperty(named = "user.language", matches = "en") >> 145: public void compactIntegerParseOnlyFractionOnlyTest() { >> 146: var fmt = NumberFormat.getIntegerInstance(); > > Should it get a compact number instance, instead of integer? Thanks for catching, I would hope the compact test actually tests a compact format; fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20101#discussion_r1671197396 From redestad at openjdk.org Tue Jul 9 21:16:33 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 9 Jul 2024 21:16:33 GMT Subject: RFR: 8335182: Consolidate and streamline String concat code shapes [v3] In-Reply-To: References: Message-ID: > This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape > (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. > > Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements): > > > Name Cnt Base Error Test Error Unit Change > StringConcat.concat13String 50 66.380 ? 0.189 53.017 ? 0.241 ns/op 1.25x (p = 0.000*) > StringConcat.concat4String 50 13.620 ? 0.053 12.382 ? 0.089 ns/op 1.10x (p = 0.000*) > StringConcat.concat6String 50 17.168 ? 0.070 16.046 ? 0.064 ns/op 1.07x (p = 0.000*) > StringConcat.concatConst2String 50 9.820 ? 0.081 8.158 ? 0.041 ns/op 1.20x (p = 0.000*) > StringConcat.concatConst4String 50 14.938 ? 0.124 12.800 ? 0.049 ns/op 1.17x (p = 0.000*) > StringConcat.concatConst6Object 50 56.115 ? 0.288 54.046 ? 0.214 ns/op 1.04x (p = 0.000*) > StringConcat.concatConst6String 50 19.032 ? 0.073 16.213 ? 0.093 ns/op 1.17x (p = 0.000*) > StringConcat.concatConstBoolByte 50 8.486 ? 0.066 8.556 ? 0.050 ns/op 0.99x (p = 0.004*) > StringConcat.concatConstInt 50 8.942 ? 0.052 7.677 ? 0.029 ns/op 1.16x (p = 0.000*) > StringConcat.concatConstIntConstInt 50 12.883 ? 0.070 12.431 ? 0.070 ns/op 1.04x (p = 0.000*) > StringConcat.concatConstString 50 7.523 ? 0.050 7.486 ? 0.044 ns/op 1.00x (p = 0.058 ) > StringConcat.concatConstStringConstInt 50 11.961 ? 0.032 11.699 ? 0.049 ns/op 1.02x (p = 0.000*) > StringConcat.concatEmptyConstInt 50 7.778 ? 0.038 7.723 ? 0.037 ns/op 1.01x (p = 0.000*) > StringConcat.concatEmptyConstString 50 3.506 ? 0.026 3.505 ? 0.015 ns/op 1.00x (p = 0.930 ) > StringConcat.concatEmptyLeft 50 3.573 ? 0.075 3.518 ? 0.057 ns/op 1.02x (p = 0.044 ) > StringConcat.concatEmptyRight 50 3.713 ? 0.049 3.622 ? 0.053 ns/op 1.02x (p = 0.000*) > StringConcat.concatMethodConstString 50 7.418 ? 0.030 7.478 ? 0.066 ns/op 0.99x (p = 0.005*) > StringConcat.concatMix4String ... Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Excess blankspace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19927/files - new: https://git.openjdk.org/jdk/pull/19927/files/7c50d7dd..58fe4b12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19927&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19927&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19927/head:pull/19927 PR: https://git.openjdk.org/jdk/pull/19927 From coleenp at openjdk.org Tue Jul 9 21:20:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 9 Jul 2024 21:20:21 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> Message-ID: <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> On Mon, 8 Jul 2024 16:21:16 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Add JVMCI symbol exports > - Revert "More graceful JVMCI VM option interaction" > > This reverts commit 2814350370cf142e130fe1d38610c646039f976d. This is really great work, Axel! I've been reading this code for a while, and have done one pass looking through the PR with a few comments. src/hotspot/share/opto/library_call.cpp line 4620: > 4618: Node *unlocked_val = _gvn.MakeConX(markWord::unlocked_value); > 4619: Node *chk_unlocked = _gvn.transform(new CmpXNode(lmasked_header, unlocked_val)); > 4620: Node *test_not_unlocked = _gvn.transform(new BoolNode(chk_unlocked, BoolTest::ne)); I don't really know what this does. Someone from the c2 compiler group should look at this. src/hotspot/share/runtime/arguments.cpp line 1830: > 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT); > 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT"); > 1830: } Maybe we want this to have the opposite sense - turn off UseObjectMonitorTable if not LM_LIGHTWEIGHT? src/hotspot/share/runtime/javaThread.inline.hpp line 258: > 256: } > 257: > 258: _om_cache.clear(); This could be shorter, ie: if (UseObjectMonitorTable) _om_cache.clear(); I think the not having an assert was to make the caller unconditional, which is good. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 393: > 391: > 392: ObjectMonitor* LightweightSynchronizer::get_or_insert_monitor(oop object, JavaThread* current, const ObjectSynchronizer::InflateCause cause, bool try_read) { > 393: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); This assert should be assert(UseObjectMonitorTable not LM_LIGHTWEIGHT). src/hotspot/share/runtime/lightweightSynchronizer.cpp line 732: > 730: > 731: markWord mark = object->mark(); > 732: assert(!mark.is_unlocked(), "must be unlocked"); "must be locked" makes more sense. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 763: > 761: assert(mark.has_monitor(), "must be"); > 762: // The monitor exists > 763: ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(current, object, mark); This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? Or we got here because BasicLock.metadata was not the ObjectMonitor? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 773: > 771: } > 772: > 773: ObjectMonitor* LightweightSynchronizer::inflate_locked_or_imse(oop obj, const ObjectSynchronizer::InflateCause cause, TRAPS) { I figured out at one point why we now check IMSE here but now cannot remember. Can you add a comment why above this function? ------------- PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2167461168 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671214948 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671216649 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671220251 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671225452 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671229697 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671231155 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671231863 From almatvee at openjdk.org Tue Jul 9 21:21:18 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 9 Jul 2024 21:21:18 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4] In-Reply-To: References: Message-ID: <2nUVZf_w5-_LSVoV3pnZWP3h2Kg7XNUdLoWGyAgie4Q=.7f92234f-6eea-4546-a732-daf5d3443dc7@github.com> On Tue, 9 Jul 2024 16:12:58 GMT, Vanitha B P wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Addressed the review comment Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19536#pullrequestreview-2167519424 From liach at openjdk.org Tue Jul 9 21:48:42 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 21:48:42 GMT Subject: RFR: 8335905: CompoundElement API cleanup Message-ID: `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. ------------- Commit messages: - Missed tests - 8335905: CompoundElement API cleanup Changes: https://git.openjdk.org/jdk/pull/20103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20103&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335905 Stats: 83 lines in 32 files changed: 2 ins; 11 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/20103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20103/head:pull/20103 PR: https://git.openjdk.org/jdk/pull/20103 From liach at openjdk.org Tue Jul 9 22:26:17 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 22:26:17 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException In-Reply-To: References: Message-ID: On Fri, 26 Apr 2024 18:20:18 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Please keep this open @cushon Given we have specified in `Collection` that unmodifiability extends to all derived collection views: https://github.com/openjdk/jdk/blob/4c9a511f75174a3f3ae575fae2677c198c607b52/src/java.base/share/classes/java/util/Collection.java#L159-L160 Would you mind changing "Calling any mutator method on the Map will ..." to something like "... on the map or any derived view collection will ..." to emphasize our new consistency? (Our internal conversation agreed on this) https://github.com/openjdk/jdk/blob/4c9a511f75174a3f3ae575fae2677c198c607b52/src/java.base/share/classes/java/util/Map.java#L125-L126 ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2218833548 From cushon at openjdk.org Tue Jul 9 22:40:41 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 22:40:41 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v5] In-Reply-To: References: Message-ID: > This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Update unmodifiable map javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18522/files - new: https://git.openjdk.org/jdk/pull/18522/files/4c9a511f..8327a8e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522 PR: https://git.openjdk.org/jdk/pull/18522 From cushon at openjdk.org Tue Jul 9 22:40:41 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 22:40:41 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 22:23:57 GMT, Chen Liang wrote: > Would you mind changing "Calling any mutator method on the Map will ..." to something like "... on the map or any derived view collection will ..." to emphasize our new consistency? (Our internal conversation agreed on this) Done! Kevin made a similar note [in the CSR](https://bugs.openjdk.org/browse/JDK-8329284?focusedId=14688403&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14688403). I have updated the CSR to mention the javadoc change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2218846679 From liach at openjdk.org Tue Jul 9 22:45:19 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 22:45:19 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v5] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 22:40:41 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update unmodifiable map javadoc All three files can have their copyright year updated. ------------- PR Review: https://git.openjdk.org/jdk/pull/18522#pullrequestreview-2167632144 From cushon at openjdk.org Tue Jul 9 22:49:30 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 22:49:30 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v6] In-Reply-To: References: Message-ID: > This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Update copyright year and add the bug number to the modified test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18522/files - new: https://git.openjdk.org/jdk/pull/18522/files/8327a8e1..31dc4f5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=04-05 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522 PR: https://git.openjdk.org/jdk/pull/18522 From cushon at openjdk.org Tue Jul 9 22:49:30 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 22:49:30 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v5] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 22:43:05 GMT, Chen Liang wrote: > All three files can have their copyright year updated. Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2218861123 From cushon at openjdk.org Tue Jul 9 23:17:47 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 9 Jul 2024 23:17:47 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v7] In-Reply-To: References: Message-ID: > This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/util/Collection/MOAT.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18522/files - new: https://git.openjdk.org/jdk/pull/18522/files/31dc4f5e..3acac325 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522 PR: https://git.openjdk.org/jdk/pull/18522 From liach at openjdk.org Tue Jul 9 23:17:47 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 23:17:47 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v6] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 22:49:30 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year > > and add the bug number to the modified test Marked as reviewed by liach (Committer). test/jdk/java/util/Collection/MOAT.java line 541: > 539: */ > 540: private static void testCollMutatorsAlwaysThrow(Collection c) { > 541: testCollMutatorsAlwaysThrow(c, ABSENT_VALUE); Suggestion: testCollMutatorsAlwaysThrow(c, ABSENT_VALUE); ------------- PR Review: https://git.openjdk.org/jdk/pull/18522#pullrequestreview-2167636479 PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1671325840 From liach at openjdk.org Tue Jul 9 23:29:28 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 23:29:28 GMT Subject: RFR: 8335905: CompoundElement API cleanup [v2] In-Reply-To: References: Message-ID: <74UB8UTbTXEyYHqR1Cx6klodMQAj5xfqnVkzFjDZe_s=.1aabaeb6-f605-41ed-b181-31f9ed30dc34@github.com> > `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Two usages in tier3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20103/files - new: https://git.openjdk.org/jdk/pull/20103/files/ea069e81..9caa520d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20103&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20103&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20103/head:pull/20103 PR: https://git.openjdk.org/jdk/pull/20103 From liach at openjdk.org Tue Jul 9 23:37:19 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Jul 2024 23:37:19 GMT Subject: RFR: 8325679: Optimize ArrayList subList sort [v4] In-Reply-To: References: Message-ID: On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi wrote: >> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. >> >> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on. > > Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision: > > Remove test Can you bump the copyright year of `ArrayList.java`? Since `ListDefaults` covers your change, can you add your bugid here https://github.com/openjdk/jdk/blob/1472124489c841642996ae984e21c533ffec8091/test/jdk/java/util/List/ListDefaults.java#L53 and bump the copyright year as well? ------------- PR Review: https://git.openjdk.org/jdk/pull/17818#pullrequestreview-2167684628 From duke at openjdk.org Wed Jul 10 01:53:10 2024 From: duke at openjdk.org (lingjun-cg) Date: Wed, 10 Jul 2024 01:53:10 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v19] In-Reply-To: References: Message-ID: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: 8333396: Use StringBuilder internally for java.text.Format.* formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19513/files - new: https://git.openjdk.org/jdk/pull/19513/files/5fda8747..6573e413 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513 From darcy at openjdk.org Wed Jul 10 05:02:36 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 10 Jul 2024 05:02:36 GMT Subject: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4] In-Reply-To: References: Message-ID: > Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Narrow scope of the change. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20063/files - new: https://git.openjdk.org/jdk/pull/20063/files/66679fb8..ee007c3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20063&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20063&range=02-03 Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20063/head:pull/20063 PR: https://git.openjdk.org/jdk/pull/20063 From jpai at openjdk.org Wed Jul 10 05:08:15 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 10 Jul 2024 05:08:15 GMT Subject: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Narrow scope of the change. The proposed reduction of the scope of the change to just note that `toString()` should return a non-null value looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2168038159 From darcy at openjdk.org Wed Jul 10 05:08:16 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 10 Jul 2024 05:08:16 GMT Subject: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Narrow scope of the change. I'd like to get portions of this change in JDK 23 as well as 24. As the quality of implementation discussion on cyclic data structures, etc. looks like it needs more discussion before reaching consensus, I've filed JDK-8336043 for the broader quality of implementation discussion in JDK 24. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20063#issuecomment-2219563751 From dholmes at openjdk.org Wed Jul 10 05:51:17 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Jul 2024 05:51:17 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: <3rVX0mcF68BflX71dFK30ztQEn_RJp9UPrb04AS6ZJM=.c12a4765-e310-43e2-a8ab-c4c3b2628d0c@github.com> On Wed, 10 Jul 2024 05:46:31 GMT, David Holmes wrote: >> src/hotspot/share/utilities/exceptions.cpp line 208: >> >>> 206: Handle h_loader, Handle h_protection_domain) { >>> 207: // Check for special boot-strapping/compiler-thread handling >>> 208: if (special_exception(thread, file, line, h_cause)) return; >> >> This fixes a long standing bug where `special_exception` is being queried with the *cause* of the exception being thrown instead of the *name* of the exception being thrown. > > I'm not so sure this is in fact a bug. If we are throwing with a cause, but we can't actually throw and so will do vm_exit, then the exception of interest is the cause not the more generic exception that would otherwise contain the cause. > > Though I have to wonder why there is not an original `_throw` for the "cause" exception, that would have triggered the special_exception handling anyway? Though I see this is inconsistent with `Exceptions::_throw_msg_cause` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1671653968 From dholmes at openjdk.org Wed Jul 10 05:51:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Jul 2024 05:51:16 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 19:09:47 GMT, Doug Simon wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed TestTranslatedException > > src/hotspot/share/utilities/exceptions.cpp line 208: > >> 206: Handle h_loader, Handle h_protection_domain) { >> 207: // Check for special boot-strapping/compiler-thread handling >> 208: if (special_exception(thread, file, line, h_cause)) return; > > This fixes a long standing bug where `special_exception` is being queried with the *cause* of the exception being thrown instead of the *name* of the exception being thrown. I'm not so sure this is in fact a bug. If we are throwing with a cause, but we can't actually throw and so will do vm_exit, then the exception of interest is the cause not the more generic exception that would otherwise contain the cause. Though I have to wonder why there is not an original `_throw` for the "cause" exception, that would have triggered the special_exception handling anyway? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1671652583 From syan at openjdk.org Wed Jul 10 06:15:16 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 10 Jul 2024 06:15:16 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote: > Hi all, > Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. > I think it's necessory to receive jvm options from jtreg. > The change has been verified, only change the testacase, the risk is low. Hi, can anyone take look this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2219642848 From alanb at openjdk.org Wed Jul 10 06:21:15 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 Jul 2024 06:21:15 GMT Subject: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Narrow scope of the change. Reducing this to the clarification of toString is good. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2168127871 From dholmes at openjdk.org Wed Jul 10 06:23:15 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Jul 2024 06:23:15 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: <3rVX0mcF68BflX71dFK30ztQEn_RJp9UPrb04AS6ZJM=.c12a4765-e310-43e2-a8ab-c4c3b2628d0c@github.com> References: <3rVX0mcF68BflX71dFK30ztQEn_RJp9UPrb04AS6ZJM=.c12a4765-e310-43e2-a8ab-c4c3b2628d0c@github.com> Message-ID: On Wed, 10 Jul 2024 05:48:23 GMT, David Holmes wrote: >> I'm not so sure this is in fact a bug. If we are throwing with a cause, but we can't actually throw and so will do vm_exit, then the exception of interest is the cause not the more generic exception that would otherwise contain the cause. >> >> Though I have to wonder why there is not an original `_throw` for the "cause" exception, that would have triggered the special_exception handling anyway? > > Though I see this is inconsistent with `Exceptions::_throw_msg_cause` Okay I think I see how the logic works. If we were going to abort we would never reach `_throw_cause` as the initial `_throw` would have exited. But for the `!thread->can_call_Java()` case the original `_throw` would replace the intended real exception with the dummy `VM_exception()`, which is then "caught" and we try to replace with a more specific exception to be thrown via `throw_cause`, which will again replace whichever exception is requested with the dummy `VM_exception()` - so the end result is we will throw the dummy regardless of whether the cause or wrapping exception is specified. So your fix here makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1671680471 From asotona at openjdk.org Wed Jul 10 07:26:19 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 10 Jul 2024 07:26:19 GMT Subject: RFR: 8335935: Chained builders not sending transformed models to next transforms In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 17:34:14 GMT, Chen Liang wrote: > Please review the fix for a major transformation bug within the ClassFile API, where certain kinds of buffered elements produced by one transform is not sent to the next, and the "chained" (`andThen` transformation chains) builders returning the wrong builder for call chains. > > This is intended to be backported to JDK 23, as this has significant impact on user experience with ClassFile API transformations. The backport won't be clean as we already renamed `ClassFile.transform` to `transformClass`, which will be reverted in the backport. It looks good to me. Nice job! ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20100#pullrequestreview-2168251509 From asotona at openjdk.org Wed Jul 10 07:33:16 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 10 Jul 2024 07:33:16 GMT Subject: RFR: 8335642: Hide Transform implementation for Class-File API [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 19:00:45 GMT, Chen Liang wrote: >> Removes ClassFile API transformation implementation details accidentally leaked to public API. Users don't have access to classes necessary to correctly implement these transform resolutions. In addition, removed improper `canWriteDirect` and made `ClassFileBuilder::transform` chain returns. >> >> Replaces #19928. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > return tag required Looks good to me. Nice cleanup job! ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20102#pullrequestreview-2168266528 From rgiulietti at openjdk.org Wed Jul 10 08:18:16 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 10 Jul 2024 08:18:16 GMT Subject: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Narrow scope of the change. It's not only cyclic data that are problematic. It's quite easy to build a DAG (so no cycles) with just 50 `record`s that takes days to return `hashCode()` and that throws OOME on `toString()`. Whatever the future wording will be about resource consumption (time and space), it will be hard to get it right while still being reasonable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20063#issuecomment-2219847401 From aboldtch at openjdk.org Wed Jul 10 09:46:13 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Jul 2024 09:46:13 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v4] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with five additional commits since the last revision: - Add comment LightweightSynchronizer::inflate_locked_or_imse - Fix BasicLock::object_monitor_cache() for other platforms - Update LightweightSynchronizer::exit assert - Update LightweightSynchronizer::get_or_insert_monitor assert - Update JavaThread::om_clear_monitor_cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/173b75b8..d12aa5f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=02-03 Stats: 23 lines in 3 files changed: 17 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From aboldtch at openjdk.org Wed Jul 10 09:46:18 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Jul 2024 09:46:18 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: On Tue, 9 Jul 2024 20:44:58 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >> This reverts commit 2814350370cf142e130fe1d38610c646039f976d. > > src/hotspot/share/runtime/arguments.cpp line 1830: > >> 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT); >> 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT"); >> 1830: } > > Maybe we want this to have the opposite sense - turn off UseObjectMonitorTable if not LM_LIGHTWEIGHT? Maybe. It boils down to what to do when the JVM receives `-XX:LockingMode={LM_LEGACY,LM_MONITOR} -XX:+UseObjectMonitorTable` The options I see are 1. Select `LockingMode=LM_LIGHTWEIGHT` 2. Select `UseObjectMonitorTable=false` 3. Do not start the VM Between 1. and 2. it is impossible to know what the real intentions were. But with being a newer `-XX:+UseObjectMonitorTable` it somehow seems more likely. Option 3. is probably the sensible solution, but it is hard to determine. We tend to not close the VM because of incompatible options, rather fix them. But I believe there are precedence for both. If we do this however we will have to figure out all the interactions with our testing framework. And probably add some safeguards. > src/hotspot/share/runtime/javaThread.inline.hpp line 258: > >> 256: } >> 257: >> 258: _om_cache.clear(); > > This could be shorter, ie: if (UseObjectMonitorTable) _om_cache.clear(); > I think the not having an assert was to make the caller unconditional, which is good. Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 393: > >> 391: >> 392: ObjectMonitor* LightweightSynchronizer::get_or_insert_monitor(oop object, JavaThread* current, const ObjectSynchronizer::InflateCause cause, bool try_read) { >> 393: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); > > This assert should be assert(UseObjectMonitorTable not LM_LIGHTWEIGHT). Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 732: > >> 730: >> 731: markWord mark = object->mark(); >> 732: assert(!mark.is_unlocked(), "must be unlocked"); > > "must be locked" makes more sense. Done. > This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? We could. > Or we got here because BasicLock.metadata was not the ObjectMonitor? That is one reason we got here. We also get here from C1/interpreter as well as if there are other threads on the entry queues. I think there was an assumption that it would not be that crucial in those cases. One off the reasons we do not read the `BasicLock` cache from the runtime is that we are not as careful with keeping the `BasicLock` initialised on platforms without `UseObjectMonitorTable`. The idea was that as long as they call into the VM, we do not need to keep it invariant. But this made me realise `BasicLock::print_on` will be broken on non x86/aarch64 platforms if running with `UseObjectMonitorTable`. Rather then fix all platforms I will condition BasicLock::object_monitor_cache to return nullptr on not supported platforms. Could add this then. Should probably add an overload to `ObjectSynchronizer::read_monitor` which takes the lock and push i all the way here. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 773: > >> 771: } >> 772: >> 773: ObjectMonitor* LightweightSynchronizer::inflate_locked_or_imse(oop obj, const ObjectSynchronizer::InflateCause cause, TRAPS) { > > I figured out at one point why we now check IMSE here but now cannot remember. Can you add a comment why above this function? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959198 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959362 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959515 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959614 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959763 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959852 From archie.cobbs at gmail.com Wed Jul 10 16:00:13 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 10 Jul 2024 11:00:13 -0500 Subject: Read-only view of ByteArrayInputStream content In-Reply-To: <493e1579-6373-4047-9a2a-4427f10f9856@geomatys.com> References: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> <5d86f03f-8646-4650-8111-00da5aca8fb8@geomatys.com> <493e1579-6373-4047-9a2a-4427f10f9856@geomatys.com> Message-ID: On Tue, Jul 9, 2024 at 1:42?PM Martin Desruisseaux < martin.desruisseaux at geomatys.com> wrote: > > Basically, the BLOB API seems clearly designed to allow the implementation > to stream the data on demand if it wants to (which is good), but as a side > effect it doesn't provide a way for the caller to guarantee avoidance of > copying the entire array (if the implementation happens to not stream the > data on demand). > > Right. The wish to "unwrap" the ByteArrayInputStream original array come > from the empirical observation that many of the JDBC drivers that we are > using do not stream. > So would you accept a solution to this problem in the java.sql package instead? For example by adding two new methods: java.sql.Blob.asByteBuffer() java.sql.Clob.asCharBuffer() -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.desruisseaux at geomatys.com Wed Jul 10 17:05:29 2024 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Wed, 10 Jul 2024 19:05:29 +0200 Subject: Read-only view of ByteArrayInputStream content In-Reply-To: References: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> <5d86f03f-8646-4650-8111-00da5aca8fb8@geomatys.com> <493e1579-6373-4047-9a2a-4427f10f9856@geomatys.com> Message-ID: <0332f0f2-f0c6-4eed-aead-029489e5f2c6@geomatys.com> Le 2024-07-10 ? 18 h 00, Archie Cobbs a ?crit?: > > So would you accept a solution to this problem in the java.sql package > instead? For example by adding two new methods: > > java.sql.Blob.asByteBuffer() > java.sql.Clob.asCharBuffer() Yes, it would work for me if JDBC drivers provide their own implementation. But it would not be exactly equivalent. A Blob.asByteBuffer() method would be efficient when the JDBC driver loads all bytes anyway, but may be expansive if the JDBC driver was really doing streaming. Maybe some JDBC drivers do streaming only when the Blob size is over some threshold (I didn't verified). Since a Blob can be very large, wouldn't it be safer to avoid adding API that performs an unconditional loading of all bytes? Unless the plan was to return an Optional. By contrast, the ByteArrayInputStream.asByteBuffer() proposal never loads bytes that were not already in memory. Therefore, it can be used in a more opportunistic way ("only if all bytes happen to be in memory anyway, opportunistically use them directly without copy"). Also, it does not require changes in JDBC drivers, and could be used in contexts other than JDBC as well. ??? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Wed Jul 10 17:44:09 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 10 Jul 2024 12:44:09 -0500 Subject: Read-only view of ByteArrayInputStream content In-Reply-To: <0332f0f2-f0c6-4eed-aead-029489e5f2c6@geomatys.com> References: <49914cb1-f562-40d0-ba8a-d92ca72f46aa@geomatys.com> <5d86f03f-8646-4650-8111-00da5aca8fb8@geomatys.com> <493e1579-6373-4047-9a2a-4427f10f9856@geomatys.com> <0332f0f2-f0c6-4eed-aead-029489e5f2c6@geomatys.com> Message-ID: On Wed, Jul 10, 2024 at 12:05?PM Martin Desruisseaux < martin.desruisseaux at geomatys.com> wrote: > Le 2024-07-10 ? 18 h 00, Archie Cobbs a ?crit : > > So would you accept a solution to this problem in the java.sql package > instead? For example by adding two new methods: > java.sql.Blob.asByteBuffer() > java.sql.Clob.asCharBuffer() > > Yes, it would work for me if JDBC drivers provide their own > implementation. But it would not be exactly equivalent. A > Blob.asByteBuffer() method would be efficient when the JDBC driver loads > all bytes anyway, but may be expansive if the JDBC driver was really doing > streaming. Maybe some JDBC drivers do streaming only when the Blob size is > over some threshold (I didn't verified). Since a Blob can be very large, > wouldn't it be safer to avoid adding API that performs an unconditional > loading of all bytes? Unless the plan was to return an Optional. > But the API already has that problem - see Blob.getBytes(). So we wouldn't be adding any new constraints on how it must behave. In any case, the API seems designed to let you choose how you want to access the data - Blob.getBytes() for random access, Blob.getBinaryStream() for stream access. The bug here is that Blob.getBytes() seems to force the driver to make a copy of the entire blob (or at least the portion you want to access) simply by the way it's designed - because the "copyness" is unspecified, a defensive copy of the array data is required. The nice thing about a Blob.asByteBuffer() method is that it would fix that problem. And a smart implementation could download and cache regions of the blob on demand as they were accessed, providing a continuous middle ground between the current "all or none" downloading choices. > By contrast, the ByteArrayInputStream.asByteBuffer() proposal never loads > bytes that were not already in memory. Therefore, it can be used in a more > opportunistic way ("only if all bytes happen to be in memory anyway, > opportunistically use them directly without copy"). Also, it does not > require changes in JDBC drivers, and could be used in contexts other than > JDBC as well. > I'm not opposed to this either, but it's a separate (nice) idea. I'm curious to hear what other people think about both ideas... -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkarthikeyan at openjdk.org Wed Jul 10 20:07:04 2024 From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan) Date: Wed, 10 Jul 2024 20:07:04 GMT Subject: RFR: 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 ... The C2 changes look nice! I just added one comment here about style. It would also be good to add some IR tests checking that the intrinsic is creating `MaxL`/`MinL` nodes before macro expansion, and a microbenchmark to compare results. src/hotspot/share/opto/library_call.cpp line 8244: > 8242: bool LibraryCallKit::inline_long_min_max(vmIntrinsics::ID id) { > 8243: assert(callee()->signature()->size() == 4, "minL/maxL has 2 parameters of size 2 each."); > 8244: Node *a = argument(0); Suggestion: Node* a = argument(0); And the same for `b` and `n` as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2169250610 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1672350809 From naoto at openjdk.org Wed Jul 10 20:07:47 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 10 Jul 2024 20:07:47 GMT Subject: RFR: 8335668: NumberFormat integer only parsing should throw exception for edge case [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 20:29:48 GMT, Justin Lu wrote: >> Please review this PR which corrects a case in NumberFormat integer only parsing. >> >> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, >> >> >> var fmt = NumberFormat.getIntegerInstance(); >> fmt.parse(".5", new ParsePosition(0)); // should return null, not 0 >> >> >> The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex. >> >> In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20101#pullrequestreview-2169730057 From never at openjdk.org Wed Jul 10 20:07:46 2024 From: never at openjdk.org (Tom Rodriguez) Date: Wed, 10 Jul 2024 20:07:46 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote: >> This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: >> 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). >> 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. >> 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. >> >> An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. >> >> To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fixed TestTranslatedException looks good. ------------- Marked as reviewed by never (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20083#pullrequestreview-2169495478 From dnsimon at openjdk.org Wed Jul 10 20:07:48 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 10 Jul 2024 20:07:48 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: <3rVX0mcF68BflX71dFK30ztQEn_RJp9UPrb04AS6ZJM=.c12a4765-e310-43e2-a8ab-c4c3b2628d0c@github.com> Message-ID: On Wed, 10 Jul 2024 06:19:52 GMT, David Holmes wrote: >> Though I see this is inconsistent with `Exceptions::_throw_msg_cause` > > Okay I think I see how the logic works. If we were going to abort we would never reach `_throw_cause` as the initial `_throw` would have exited. But for the `!thread->can_call_Java()` case the original `_throw` would replace the intended real exception with the dummy `VM_exception()`, which is then "caught" and we try to replace with a more specific exception to be thrown via `throw_cause`, which will again replace whichever exception is requested with the dummy `VM_exception()` - so the end result is we will throw the dummy regardless of whether the cause or wrapping exception is specified. So your fix here makes sense. Great. Would you mind approving this PR as this is the only non-JVMCI file changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20083#discussion_r1672520461 From liach at openjdk.org Wed Jul 10 20:07:56 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 20:07:56 GMT Subject: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 23:06:17 GMT, Shaojin Wen wrote: > The current HexFormat defines an Enum to represent LowerCase and UpperCase > > > class HexFormat { > private enum Case { > LOWERCASE, > UPPERCASE > } > } > > > This will cause the JVM to load one more class when it starts, which can be seen as follows > > > public class Startup { > public static void main(String[] args) {} > } > > > > java -verbose:class Startup > > > > [0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base > > > There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit. The internal enum representation is an unnecessary abstraction; a boolean for uppercase is used for all public endpoints in `isUpperCase` and `toString`, so using the same boolean internally makes sense. Do you think we should call this field `ucase` or `uppercase`? src/java.base/share/classes/java/util/HexFormat.java line 1: > 1: /* Copyright year needs an update ------------- PR Review: https://git.openjdk.org/jdk/pull/20060#pullrequestreview-2169018970 PR Review Comment: https://git.openjdk.org/jdk/pull/20060#discussion_r1672225028 From aboldtch at openjdk.org Wed Jul 10 20:10:07 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Jul 2024 20:10:07 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v5] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with four additional commits since the last revision: - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object - Fix typos - Remove unused variable - Add missing inline qualifiers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/d12aa5f6..a207544b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=03-04 Stats: 16 lines in 3 files changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From joehw at openjdk.org Wed Jul 10 20:09:11 2024 From: joehw at openjdk.org (Joe Wang) Date: Wed, 10 Jul 2024 20:09:11 GMT Subject: RFR: 8336021: Doccheck: valign not allowed for HTML5 in java.xml Message-ID: Remove valign Attribute from the javadoc for org.w3c.dom.Attr. The table looks good with the default setting. ------------- Commit messages: - 8336021: Doccheck: valign not allowed for HTML5 in java.xml Changes: https://git.openjdk.org/jdk/pull/20117/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20117&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336021 Stats: 23 lines in 1 file changed: 0 ins; 2 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/20117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20117/head:pull/20117 PR: https://git.openjdk.org/jdk/pull/20117 From jvernee at openjdk.org Wed Jul 10 20:09:25 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 10 Jul 2024 20:09:25 GMT Subject: [jdk23] RFR: 8333884: MemorySegment::reinterpret removes read-only property Message-ID: Hi all, This pull request contains a backport of commit [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Per Minborg on 6 Jul 2024 and was reviewed by Jorn Vernee and Maurizio Cimadamore. Thanks! ------------- Commit messages: - Backport 6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef Changes: https://git.openjdk.org/jdk/pull/20119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20119&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333884 Stats: 38 lines in 4 files changed: 30 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20119/head:pull/20119 PR: https://git.openjdk.org/jdk/pull/20119 From liach at openjdk.org Wed Jul 10 20:09:26 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 20:09:26 GMT Subject: [jdk23] RFR: 8333884: MemorySegment::reinterpret removes read-only property In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 17:01:00 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 6 Jul 2024 and was reviewed by Jorn Vernee and Maurizio Cimadamore. > > Thanks! Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20119#pullrequestreview-2170052614 From duke at openjdk.org Wed Jul 10 20:11:03 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 10 Jul 2024 20:11:03 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 18:14:03 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Ensure normalized value in MutableBigInteger initialization with ints > > Everything not obvious that departs from the paper by Bertot, Magaud and Zimmermann should be commented. > Unfortunately, I can't say precisely what and to which extent until I see a first version. @rgiulietti I added a comment with the considerations on normalization in the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2220230697 From rgiulietti at openjdk.org Wed Jul 10 20:11:07 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 10 Jul 2024 20:11:07 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 20:06:40 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() Yes, thanks, I saw it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2220353812 From asemenyuk at openjdk.org Wed Jul 10 20:11:33 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 10 Jul 2024 20:11:33 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 16:12:58 GMT, Vanitha B P wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Addressed the review comment Marked as reviewed by asemenyuk (Reviewer). Looks good. Thank you for doing all the adjustments to the code! ------------- PR Review: https://git.openjdk.org/jdk/pull/19536#pullrequestreview-2169542074 PR Comment: https://git.openjdk.org/jdk/pull/19536#issuecomment-2220850428 From duke at openjdk.org Wed Jul 10 20:11:08 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 10 Jul 2024 20:11:08 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: Message-ID: <9ULfyZ3YgME29eN56_Sipe0DY6HDxK3rGPRswArAA9M=.b79b1b27-557d-4b9b-b98d-073a146ba0f0@github.com> On Wed, 10 Jul 2024 12:13:32 GMT, Raffaello Giulietti wrote: > Yes, thanks, I saw it. If some other clarifications are needed, please let me know. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2220362708 From liach at openjdk.org Wed Jul 10 20:12:10 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 20:12:10 GMT Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2] In-Reply-To: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> References: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> Message-ID: On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote: >> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. >> >> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). >> >> Before: >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.843 ? 0.149 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 2.363 ? 0.091 ns/op >> >> >> >> After: >> >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.121 ? 1.189 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 1.001 ? 0.001 ns/op > > Sean Gwizdak 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: > > - Remove trailing whitespace. > - Move hashCode benchmark into the newly created MethodBenchmark file > - Merge branch 'master' into method-hashcode-JDK-8332249 > - Remove changes to JavaDoc per guidance. > - Fix whitespace issues pointed by the bot > - Micro-optimize Method.hashCode Looks good as-is. JDK-8286288 can address the `@Stable` question once #19635 is merged. ------------- Marked as reviewed by liach (Committer). PR Review: https://git.openjdk.org/jdk/pull/19433#pullrequestreview-2169814002 From duke at openjdk.org Wed Jul 10 20:12:10 2024 From: duke at openjdk.org (Sean Gwizdak) Date: Wed, 10 Jul 2024 20:12:10 GMT Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2] In-Reply-To: References: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> Message-ID: <5Gb89LHxqfl6I1XsmUKsdvhSR-p9tLNu8Ep92xQwLcg=.f9fe84da-7a64-4eca-a349-1e4f2dea170a@github.com> On Tue, 11 Jun 2024 08:58:34 GMT, Aleksey Shipilev wrote: >> Sean Gwizdak 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: >> >> - Remove trailing whitespace. >> - Move hashCode benchmark into the newly created MethodBenchmark file >> - Merge branch 'master' into method-hashcode-JDK-8332249 >> - Remove changes to JavaDoc per guidance. >> - Fix whitespace issues pointed by the bot >> - Micro-optimize Method.hashCode > > As usual in these cases, we need to make a footprint argument as well. `Method` is a special class with lots of injected fields, so the only "true" source of layout information is `-XX:+PrintFieldLayout`. It tells me there is a 4-byte tail due to object alignment in compressed oops mode. This can accommodate a new `int` field. There seems to be no space when compressed oops are disabled. > > > # Out of the box, compressed oops enabled > Layout of class java/lang/reflect/Method > Instance fields: > @0 12/- RESERVED > @12 "override" Z 1/1 INHERITED > @13 "callerSensitive" B 1/1 REGULAR > @14 2/1 EMPTY > @16 "accessCheckCache" Ljava/lang/Object; 4/4 INHERITED > @20 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 4/4 INHERITED > @24 "declaredAnnotations" Ljava/util/Map; 4/4 INHERITED > @28 "slot" I 4/4 REGULAR > @32 "modifiers" I 4/4 REGULAR > @36 "clazz" Ljava/lang/Class; 4/4 REGULAR > @40 "name" Ljava/lang/String; 4/4 REGULAR > @44 "returnType" Ljava/lang/Class; 4/4 REGULAR > @48 "parameterTypes" [Ljava/lang/Class; 4/4 REGULAR > @52 "exceptionTypes" [Ljava/lang/Class; 4/4 REGULAR > @56 "signature" Ljava/lang/String; 4/4 REGULAR > @60 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 4/4 REGULAR > @64 "annotations" [B 4/4 REGULAR > @68 "parameterAnnotations" [B 4/4 REGULAR > @72 "annotationDefault" [B 4/4 REGULAR > @76 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 4/4 REGULAR > @80 "root" Ljava/lang/reflect/Method; 4/4 REGULAR > Instance size = 88 bytes > > # -XX:-UseCompressedOops > Layout of class java/lang/reflect/Method > Instance fields: > @0 12/- RESERVED > @12 "override" Z 1/1 INHERITED > @13 "callerSensitive" B 1/1 REGULAR > @14 2/1 EMPTY > @16 "accessCheckCache" Ljava/lang/Object; 8/8 INHERITED > @24 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 8/8 INHERITED > @32 "declaredAnnotations" Ljava/util/Map; 8/8 INHERITED > @40 "slot" I 4/4 REGULAR > @44 "modifiers" I 4/4 REGULAR > @48 "clazz" Ljava/lang/Class; 8/8 REGULAR > @56 "name" Ljava/lang/String; 8/8 REGULAR > @64 "returnType" Ljava/lang/Class; 8/8 REGULAR > @72 "parameterTypes" [Ljava/lang/Class; 8/8 REGULAR > @80 "exceptionTypes" [Ljava/lang/Class; 8/8 REGULAR > @88 "signature" Ljava/lang/String; 8/8 REGULAR > @96 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 8/8 REGULAR > @104 "annotations" [B 8/8 REGULAR > @112 "parameterAnnotations" [B 8/8 REGULAR > @120 "annotationDefault" [B 8/8 REGULAR > @128 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 8/8 REGULAR > @136 "root" Ljava/... Adding a new comment per bot. @shipilev Any recommendations on reducing footprint size? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2221026207 From smarks at openjdk.org Wed Jul 10 20:17:29 2024 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 10 Jul 2024 20:17:29 GMT Subject: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Narrow scope of the change. Marked as reviewed by smarks (Reviewer). Narrowed scope to non-null toString return looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2169697515 PR Comment: https://git.openjdk.org/jdk/pull/20063#issuecomment-2220970513 From darcy at openjdk.org Wed Jul 10 20:17:31 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 10 Jul 2024 20:17:31 GMT Subject: Integrated: 8335637: Add explicit non-null return value expectations to Object.toString() In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote: > Make well-behaved implementation expectations of Object.{toString, hashCode} explicit. This pull request has now been integrated. Changeset: 66db7156 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/66db71563c3ebd715a1192a9b399b618d7bdb8d0 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8335637: Add explicit non-null return value expectations to Object.toString() Reviewed-by: jpai, alanb, smarks, prappo ------------- PR: https://git.openjdk.org/jdk/pull/20063 From jvernee at openjdk.org Wed Jul 10 20:17:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 10 Jul 2024 20:17:46 GMT Subject: [jdk23] Integrated: 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory. Message-ID: Hi all, This pull request contains a backport of commit [c80e2eb3](https://github.com/openjdk/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Per Minborg on 12 Jun 2024 and was reviewed by Jorn Vernee and Maurizio Cimadamore. This is a P4 doc-only change, which is permitted in RDP1: https://openjdk.org/jeps/3#Quick-reference This change should also make it possible to cleanly backport: https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef Thanks! ------------- Commit messages: - Backport c80e2eb35c4eb03f17a2a31e979e5c369453e203 Changes: https://git.openjdk.org/jdk/pull/20116/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20116&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333886 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20116.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20116/head:pull/20116 PR: https://git.openjdk.org/jdk/pull/20116 From sundar at openjdk.org Wed Jul 10 20:17:46 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Wed, 10 Jul 2024 20:17:46 GMT Subject: [jdk23] Integrated: 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory. In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 16:08:51 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit [c80e2eb3](https://github.com/openjdk/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 12 Jun 2024 and was reviewed by Jorn Vernee and Maurizio Cimadamore. > > This is a P4 doc-only change, which is permitted in RDP1: https://openjdk.org/jeps/3#Quick-reference > > This change should also make it possible to cleanly backport: https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef > > Thanks! LGTM ------------- Marked as reviewed by sundar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20116#pullrequestreview-2169705274 From jvernee at openjdk.org Wed Jul 10 20:17:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 10 Jul 2024 20:17:46 GMT Subject: [jdk23] Integrated: 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory. In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 16:08:51 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit [c80e2eb3](https://github.com/openjdk/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 12 Jun 2024 and was reviewed by Jorn Vernee and Maurizio Cimadamore. > > This is a P4 doc-only change, which is permitted in RDP1: https://openjdk.org/jeps/3#Quick-reference > > This change should also make it possible to cleanly backport: https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef > > Thanks! This pull request has now been integrated. Changeset: 5b9ecb17 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/5b9ecb178667e373a834b241b8f8c8a13cef3b4d Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory. Reviewed-by: sundar Backport-of: c80e2eb35c4eb03f17a2a31e979e5c369453e203 ------------- PR: https://git.openjdk.org/jdk/pull/20116 From lancea at openjdk.org Wed Jul 10 20:56:58 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 10 Jul 2024 20:56:58 GMT Subject: RFR: 8336021: Doccheck: valign not allowed for HTML5 in java.xml In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 16:24:01 GMT, Joe Wang wrote: > Remove valign Attribute from the javadoc for org.w3c.dom.Attr. The table looks good with the default setting. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20117#pullrequestreview-2170285535 From liach at openjdk.org Wed Jul 10 21:08:59 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 21:08:59 GMT Subject: RFR: 8335935: Chained builders not sending transformed models to next transforms In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 17:34:14 GMT, Chen Liang wrote: > Please review the fix for a major transformation bug within the ClassFile API, where certain kinds of buffered elements produced by one transform is not sent to the next, and the "chained" (`andThen` transformation chains) builders returning the wrong builder for call chains. > > This is intended to be backported to JDK 23, as this has significant impact on user experience with ClassFile API transformations. The backport won't be clean as we already renamed `ClassFile.transform` to `transformClass`, which will be reverted in the backport. Thanks for the reviews! I will get hands-on the backporting ASAP. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20100#issuecomment-2221469895 From liach at openjdk.org Wed Jul 10 21:09:00 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 21:09:00 GMT Subject: Integrated: 8335935: Chained builders not sending transformed models to next transforms In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 17:34:14 GMT, Chen Liang wrote: > Please review the fix for a major transformation bug within the ClassFile API, where certain kinds of buffered elements produced by one transform is not sent to the next, and the "chained" (`andThen` transformation chains) builders returning the wrong builder for call chains. > > This is intended to be backported to JDK 23, as this has significant impact on user experience with ClassFile API transformations. The backport won't be clean as we already renamed `ClassFile.transform` to `transformClass`, which will be reverted in the backport. This pull request has now been integrated. Changeset: cad68e06 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/cad68e06ecad1e19091d1af9c0f9b8145d6842fb Stats: 293 lines in 10 files changed: 169 ins; 97 del; 27 mod 8335935: Chained builders not sending transformed models to next transforms Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20100 From darcy at openjdk.org Wed Jul 10 21:41:08 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 10 Jul 2024 21:41:08 GMT Subject: [jdk23] RFR: 8335637: Add explicit non-null return value expectations to Object.toString() Message-ID: 8335637: Add explicit non-null return value expectations to Object.toString() ------------- Commit messages: - Backport 66db71563c3ebd715a1192a9b399b618d7bdb8d0 Changes: https://git.openjdk.org/jdk/pull/20124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335637 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20124/head:pull/20124 PR: https://git.openjdk.org/jdk/pull/20124 From jlu at openjdk.org Wed Jul 10 21:52:20 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 10 Jul 2024 21:52:20 GMT Subject: [jdk23] RFR: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 Message-ID: Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This updates the IANA subtag registry to version 2024-06-14. ------------- Commit messages: - Backport 861aefcafacdc21459ef966307f52568e327fd49 Changes: https://git.openjdk.org/jdk/pull/20125/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334418 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20125/head:pull/20125 PR: https://git.openjdk.org/jdk/pull/20125 From naoto at openjdk.org Wed Jul 10 21:56:55 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 10 Jul 2024 21:56:55 GMT Subject: [jdk23] RFR: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This updates the IANA subtag registry to version 2024-06-14. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20125#pullrequestreview-2170443912 From duke at openjdk.org Wed Jul 10 22:02:12 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 10 Jul 2024 22:02:12 GMT Subject: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum [v2] In-Reply-To: References: Message-ID: > The current HexFormat defines an Enum to represent LowerCase and UpperCase > > > class HexFormat { > private enum Case { > LOWERCASE, > UPPERCASE > } > } > > > This will cause the JVM to load one more class when it starts, which can be seen as follows > > > public class Startup { > public static void main(String[] args) {} > } > > > > java -verbose:class Startup > > > > [0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base > > > There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20060/files - new: https://git.openjdk.org/jdk/pull/20060/files/bf8d7cb4..9b1bf851 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20060&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20060&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20060/head:pull/20060 PR: https://git.openjdk.org/jdk/pull/20060 From srl at openjdk.org Wed Jul 10 22:11:02 2024 From: srl at openjdk.org (Steven Loomis) Date: Wed, 10 Jul 2024 22:11:02 GMT Subject: RFR: 8334653: ISO 4217 Amendment 177 Update [v3] In-Reply-To: References: <-d44Rl_Lgf3-Jdn-BE5nu8eZ8oQujOD_GfbFaidWXos=.7b6511ac-29b4-4ddb-a489-a3b538c543f7@github.com> Message-ID: On Fri, 21 Jun 2024 01:58:05 GMT, Naoto Sato wrote: > Out of curiosity, what's the rationale behind the currency name change from "Zimbabwe Dollar" (ISO 4217 definition) to "Zimbabwean Dollar"? I'm not sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1673107271 From jlu at openjdk.org Wed Jul 10 22:16:13 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 10 Jul 2024 22:16:13 GMT Subject: [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update Message-ID: Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This change incorporates the ISO 4217 Amendment 177 Update. ------------- Commit messages: - Backport 86b0cf259fb3cbe3a1973151148e5d36c6a99d91 Changes: https://git.openjdk.org/jdk/pull/20126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334653 Stats: 23 lines in 6 files changed: 3 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/20126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20126/head:pull/20126 PR: https://git.openjdk.org/jdk/pull/20126 From naoto at openjdk.org Wed Jul 10 22:16:13 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 10 Jul 2024 22:16:13 GMT Subject: [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This change incorporates the ISO 4217 Amendment 177 Update. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20126#pullrequestreview-2170464176 From liach at openjdk.org Wed Jul 10 22:18:12 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 22:18:12 GMT Subject: [jdk23] RFR: 8335935: Chained builders not sending transformed models to next transforms Message-ID: Please review this non-clean backport of the bugfix in #20100 to release 23, where ClassFile API chained builders does not emit certain elements through downstream transforms and returns wrong builder for chaining. This backport includes an additional change that rolls back a rename done in #19952 that applies to the new test, intended for 24 only. ------------- Commit messages: - Roll back method names for transformClass rename - 8335935: Chained builders not sending transformed models to next transforms Changes: https://git.openjdk.org/jdk/pull/20127/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335935 Stats: 293 lines in 10 files changed: 169 ins; 97 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/20127.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20127/head:pull/20127 PR: https://git.openjdk.org/jdk/pull/20127 From duke at openjdk.org Wed Jul 10 23:18:55 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 10 Jul 2024 23:18:55 GMT Subject: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 13:01:21 GMT, Chen Liang wrote: > The internal enum representation is an unnecessary abstraction; a boolean for uppercase is used for all public endpoints in `isUpperCase` and `toString`, so using the same boolean internally makes sense. > > Do you think we should call this field `ucase` or `uppercase`? `ucase` is a name that has been used in this class. It is used in the formatOptDelimiter method. `ucase` is an abbreviation, but it is easy to understand. Using the name `ucase` also requires fewer changes than `uppercase`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20060#issuecomment-2221684843 From darcy at openjdk.org Wed Jul 10 23:19:06 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 10 Jul 2024 23:19:06 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} Message-ID: First pass at adding some quality of implementation discussions around the overridable methods of Object. ------------- Commit messages: - Appease jcheck. - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} Changes: https://git.openjdk.org/jdk/pull/20128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336043 Stats: 52 lines in 1 file changed: 52 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20128/head:pull/20128 PR: https://git.openjdk.org/jdk/pull/20128 From liach at openjdk.org Wed Jul 10 23:19:07 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 23:19:07 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 126: > 124: * > 125: * As as a quality of implementation concern, a particular > 126: * implementation of this method may or may not support generating "may not support generating hash codes" sounds weird; maybe like "may or may not guard against cyclic data structures in recursive hash code generation." I think the key is "recursive" here, as only recursive implementations are at risk of these faults. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1673145220 From darcy at openjdk.org Wed Jul 10 23:19:07 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 10 Jul 2024 23:19:07 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:54:23 GMT, Chen Liang wrote: >> First pass at adding some quality of implementation discussions around the overridable methods of Object. > > src/java.base/share/classes/java/lang/Object.java line 126: > >> 124: * >> 125: * As as a quality of implementation concern, a particular >> 126: * implementation of this method may or may not support generating > > "may not support generating hash codes" sounds weird; maybe like "may or may not guard against cyclic data structures in recursive hash code generation." > > I think the key is "recursive" here, as only recursive implementations are at risk of these faults. Well, recursion is the easiest way to accidentally write an infinite loop, but I think a few other ones would be possible too ;-) I'll considering updating the wording to highlight the most likely hazards; thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1673159791 From liach at openjdk.org Wed Jul 10 23:34:55 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 23:34:55 GMT Subject: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:02:12 GMT, Shaojin Wen wrote: >> The current HexFormat defines an Enum to represent LowerCase and UpperCase >> >> >> class HexFormat { >> private enum Case { >> LOWERCASE, >> UPPERCASE >> } >> } >> >> >> This will cause the JVM to load one more class when it starts, which can be seen as follows >> >> >> public class Startup { >> public static void main(String[] args) {} >> } >> >> >> >> java -verbose:class Startup >> >> >> >> [0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base >> >> >> There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright Thanks for the detailed rationale and explanations! Runs fine on CI. ------------- Marked as reviewed by liach (Committer). PR Review: https://git.openjdk.org/jdk/pull/20060#pullrequestreview-2170564329 From darcy at openjdk.org Wed Jul 10 23:55:55 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 10 Jul 2024 23:55:55 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 49: > 47: * particular, the implementations should take care to avoid using > 48: * excessive memory, computational time, or any other resources. > 49: * Additionally, during typical operation these methods should A note on terminology, I used "typical" for the new notes rather than "normal" to avoid conflating the discussion with the JLS concept of code "completing normally" (as opposed to completing abruptly due to an exception): https://docs.oracle.com/javase/specs/jls/se22/html/jls-14.html#jls-14.1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1673207400 From smarks at openjdk.org Thu Jul 11 00:08:55 2024 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Jul 2024 00:08:55 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 48: > 46: * to provide reasonable implementations of these methods. In > 47: * particular, the implementations should take care to avoid using > 48: * excessive memory, computational time, or any other resources. While it's not wrong, advising against "excessive" usage is so vague as not to be actionable. Given some piece of code it's hard to say whether or not it does anything excessive. Consider a List with a million elements; as a practical matter, any one of these methods requires visiting every element. Is that excessive? Why or why not? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1673223579 From smarks at openjdk.org Thu Jul 11 00:13:56 2024 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Jul 2024 00:13:56 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: <13yMIgfcXgfmSbDRsUfOPAdnay2-81vsMKG4xpwMkbs=.a12c7d6a-9147-49c4-bc60-f950805b6391@github.com> On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 53: > 51: * {@link VirtualMachineError} is possible during the execution of a > 52: * method, often due to factors outside of the method's direct > 53: * control. "Should not throw any exception or other throwable" is overly broad. However, there is a narrower sense where code that implements these methods "shouldn't" throw anything. I'd suggest focusing on precondition checking. Specifically, no object should ever be in a state such that calling one of these methods results in IllegalStateException or other exception based on the state of the object. In addition, no argument passed to equals() should ever cause IllegalArgumentException, ClassCastException, NullPointerException, or other exception based on the argument. (This comment applies to other locations where the "excessive" wording is used.) src/java.base/share/classes/java/lang/Object.java line 191: > 189: * should not be thrown if the argument has an incomparable type > 190: * to this object and {@link NullPointerException} should not be > 191: * thrown if the argument is {@code null}. The implementation For these cases the recommendation should be to return false instead of throwing such exceptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1673226617 PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1673227589 From smarks at openjdk.org Thu Jul 11 00:29:54 2024 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Jul 2024 00:29:54 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the overridable methods of Object. @kevinb9n You should take a look at this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20128#issuecomment-2221761107 From smarks at openjdk.org Thu Jul 11 00:29:56 2024 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Jul 2024 00:29:56 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 23:16:07 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/Object.java line 126: >> >>> 124: * >>> 125: * As as a quality of implementation concern, a particular >>> 126: * implementation of this method may or may not support generating >> >> "may not support generating hash codes" sounds weird; maybe like "may or may not guard against cyclic data structures in recursive hash code generation." >> >> I think the key is "recursive" here, as only recursive implementations are at risk of these faults. > > Well, recursion is the easiest way to accidentally write an infinite loop, but I think a few other ones would be possible too ;-) I'll considering updating the wording to highlight the most likely hazards; thanks. Unfortunately the typical implementation pattern is to recur through the component fields of the object. Not recursion through `this` but rather the hashCode implementation of some object will typically invoke hashCode of its component fields. Of course this can result in infinite recursion (really, StackOverflowError) if the object graph contains cycles, but in general, implementations of these methods don't guard against this possibility. (Nor should they. Adding such guard code seems impractical.) Note that the default implementations of these methods for records and for Collection classes doesn't guard against cycles. (The collections contain some special cases for collection that contains itself, but not cycles in general.) I have a general concern about advice that isn't actionable, such as "may not support" or "care should be taken" etc. If we really want to say something about cyclic data structures, maybe we could say something like this. For data structures that may contain cycles, these implementations should avoid traversing component fields that may lead to cycles. A class could simply inherit the method implementations from Object. Alternatively, the class could contain a unique ID that's used for determining the result of equals/hashCode/toString. (Of course, determining uniqueness is up to the application.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1673238207 From jpai at openjdk.org Thu Jul 11 01:35:04 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jul 2024 01:35:04 GMT Subject: [jdk23] RFR: 8335637: Add explicit non-null return value expectations to Object.toString() In-Reply-To: References: Message-ID: <1aZslwD5RpK_8iNEM9BAJYs8uVwe9EU2WJjJx9YpbiM=.e3e6d54e-cda7-407e-abed-28936d21b7b6@github.com> On Wed, 10 Jul 2024 21:35:55 GMT, Joe Darcy wrote: > 8335637: Add explicit non-null return value expectations to Object.toString() This is a clean backport of a doc-only change with an approved CSR. Looks good to me for 23. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20124#pullrequestreview-2170701403 From dholmes at openjdk.org Thu Jul 11 02:44:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Jul 2024 02:44:05 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote: >> This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: >> 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). >> 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. >> 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. >> >> An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. >> >> To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fixed TestTranslatedException Non JVMCI changes look good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20083#pullrequestreview-2170778148 From darcy at openjdk.org Thu Jul 11 03:08:57 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 11 Jul 2024 03:08:57 GMT Subject: [jdk23] Integrated: 8335637: Add explicit non-null return value expectations to Object.toString() In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 21:35:55 GMT, Joe Darcy wrote: > 8335637: Add explicit non-null return value expectations to Object.toString() This pull request has now been integrated. Changeset: 4aab58be Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/4aab58be4aa1bbe848084189b467d0c586a4ffbb Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8335637: Add explicit non-null return value expectations to Object.toString() Reviewed-by: jpai Backport-of: 66db71563c3ebd715a1192a9b399b618d7bdb8d0 ------------- PR: https://git.openjdk.org/jdk/pull/20124 From jkratochvil at openjdk.org Thu Jul 11 03:41:59 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 11 Jul 2024 03:41:59 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 14:43:58 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges. >> >> I'm adding those tests in order to not regress another time. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1. >> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to JDK-8322420) >> - [x] GHA > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Fix comments > - 8333446: Add tests for hierarchical container support test/hotspot/jtreg/ProblemList.txt line 119: > 117: containers/docker/TestMemoryAwareness.java 8303470 linux-all > 118: containers/docker/TestJFREvents.java 8327723 linux-x64 > 119: containers/systemd/SystemdMemoryAwarenessTest.java 8322420 linux-all This line should be removed as long as it gets applied after [17198](https://github.com/openjdk/jdk/pull/17198). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1673356918 From jkratochvil at openjdk.org Thu Jul 11 03:44:56 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 11 Jul 2024 03:44:56 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 14:43:58 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges. >> >> I'm adding those tests in order to not regress another time. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1. >> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to JDK-8322420) >> - [x] GHA > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Fix comments > - 8333446: Add tests for hierarchical container support [test.patch.txt](https://github.com/user-attachments/files/16171122/test.patch.txt) * `CPUQuota` (changed it to `AllowedCPUs`) does not work for me - it properly distributes the load but JDK still sees all available CPU cores (4 of my VM). * the change 2 -> 1 cores: // We could check 2 cores ("0-1") but then it would fail on single-core nodes / virtual machines. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2221959393 From duke at openjdk.org Thu Jul 11 04:58:20 2024 From: duke at openjdk.org (Vanitha B P) Date: Thu, 11 Jul 2024 04:58:20 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v5] In-Reply-To: References: Message-ID: > Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. > > The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Vanitha B P ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19536/files - new: https://git.openjdk.org/jdk/pull/19536/files/964742d9..889c5d7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19536&range=03-04 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19536/head:pull/19536 PR: https://git.openjdk.org/jdk/pull/19536 From duke at openjdk.org Thu Jul 11 04:58:20 2024 From: duke at openjdk.org (Vanitha B P) Date: Thu, 11 Jul 2024 04:58:20 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 15:36:52 GMT, Alexey Semenyuk wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed the review comment > > Looks good. Thank you for doing all the adjustments to the code! Thanks @alexeysemenyukoracle and @sashamatveev for reviewing and providing valuable inputs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19536#issuecomment-2222025477 From duke at openjdk.org Thu Jul 11 04:58:20 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 04:58:20 GMT Subject: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 16:12:58 GMT, Vanitha B P wrote: >> Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Addressed the review comment @Vanitha-bp Your change (at version 889c5d7b76be991cc3faf45627262a73c8d1a919) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19536#issuecomment-2222029348 From jpai at openjdk.org Thu Jul 11 05:48:55 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jul 2024 05:48:55 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 06:12:56 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> The change has been verified, only change the testacase, the risk is low. > > Hi, can anyone take look this PR. Hello @sendaoYan, can you add some details to the JBS issue explaining why this change is necessary and what fails (if anything) in the absence of this change? I suspect you might be running into some failure with this test, but in its current form in the JBS description, it's not clear what the issue is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2222083909 From sundar at openjdk.org Thu Jul 11 06:12:56 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Thu, 11 Jul 2024 06:12:56 GMT Subject: [jdk23] RFR: 8333884: MemorySegment::reinterpret removes read-only property In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 17:01:00 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 6 Jul 2024 and was reviewed by Jorn Vernee and Maurizio Cimadamore. > > Thanks! LGTM ------------- Marked as reviewed by sundar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20119#pullrequestreview-2170991812 From syan at openjdk.org Thu Jul 11 06:15:00 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 11 Jul 2024 06:15:00 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: <6Mp0SM65d1GOm717UBv0HYPBy-na9DcPDNmWQLNlxTI=.558022c6-7ddb-4d3c-9cb3-97ae871f6a81@github.com> On Wed, 10 Jul 2024 06:12:56 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> The change has been verified, only change the testacase, the risk is low. > > Hi, can anyone take look this PR. > Hello @sendaoYan, can you add some details to the JBS issue explaining why this change is necessary and what fails (if anything) in the absence of this change? I suspect you might be running into some failure with this test, but in its current form in the JBS description, it's not clear what the issue is. Okey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2222113909 From smarks at openjdk.org Thu Jul 11 06:26:57 2024 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Jul 2024 06:26:57 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v7] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 23:17:47 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/java/util/Collection/MOAT.java > > Co-authored-by: Chen Liang Please see the analysis I just added to the bug report: https://bugs.openjdk.org/browse/JDK-8328821?focusedId=14688968&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14688968 ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2222129207 From jkratochvil at openjdk.org Thu Jul 11 06:54:27 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 11 Jul 2024 06:54:27 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: References: Message-ID: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> > The testcase requires root permissions. > > Designed by Severin Gehwolf, implemented by Jan Kratochvil. Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: - Fix the gtest - fix compilation warning - fix the gtest - less refactorizations - remove not a real backward compat. - whitespace - less refactorizations - reduce refactorizations - Fix caching - Merge branch 'master' into master-cgroup - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 ------------- Changes: https://git.openjdk.org/jdk/pull/17198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=11 Stats: 793 lines in 16 files changed: 492 ins; 225 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From jkratochvil at openjdk.org Thu Jul 11 06:54:28 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 11 Jul 2024 06:54:28 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v11] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 15:02:18 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Designed by Severin Gehwolf, implemented by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - . > - . > - Merge branch 'jdk-8331560-cgroup-controller-delegation-merge-diamond' into jdk-8331560-cgroup-controller-delegation-merge-cgroup > - diamond > - Merge branch 'jerboaarefactor-merge-cgroup' into jdk-8331560-cgroup-controller-delegation-merge-cgroup > - Merge branch 'jerboaarefactor-merge' into jerboaarefactor-merge-cgroup > - Merge branch 'master' into jerboaarefactor-merge > - whitespace fix > - centos7 compat > - 64a5feb6: > - ... and 64 more: https://git.openjdk.org/jdk/compare/3d511ff6...25c0287d I have tried to make a minimal patch without any refactorizations just the reach the functionality. I plan to post some refactorizations later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2222163427 From jkratochvil at openjdk.org Thu Jul 11 06:54:28 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 11 Jul 2024 06:54:28 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Thu, 11 Jul 2024 06:50:21 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Designed by Severin Gehwolf, implemented by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: > > - Fix the gtest > - fix compilation warning > - fix the gtest > - less refactorizations > - remove not a real backward compat. > - whitespace > - less refactorizations > - reduce refactorizations > - Fix caching > - Merge branch 'master' into master-cgroup > - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp line 50: > 48: _path(construct_path(mount_path, cgroup_path)) { > 49: } > 50: // Shallow copy constructor I had to remove the "shallow" part as it was not memory safe afterwards and one could easily get: ================================================================= ==3770369==ERROR: AddressSanitizer: heap-use-after-free on address 0x502000001530 at pc 0x7f086bcc45c0 bp 0x7f086adfd7b0 sp 0x7f086adfcf70 READ of size 1 at 0x502000001530 thread T1 #0 0x7f086bcc45bf in strcmp.part.0 (/lib64/libasan.so.8+0xc45bf) (BuildId: c1431025b5d8af781c22c9ceea71f065c547d32d) #1 0x7f0862c77e55 in CgroupController::set_path(char const*) /home/azul/azul/openjdk-git/src/hotspot/os/linux/cgroupSubsystem_linux.cpp:841 ... 0x502000001530 is located 0 bytes inside of 2-byte region [0x502000001530,0x502000001532) freed by thread T1 here: ... #4 0x7f08655c537c in os::free(void*) /home/azul/azul/openjdk-git/src/hotspot/share/runtime/os.cpp:775 #5 0x7f0862c7a456 in CgroupController::~CgroupController() /home/azul/azul/openjdk-git/src/hotspot/os/linux/cgroupSubsystem_linux.hpp:184 ... previously allocated by thread T1 here: #0 0x7f086bcf7997 in malloc (/lib64/libasan.so.8+0xf7997) (BuildId: c1431025b5d8af781c22c9ceea71f065c547d32d) ... #7 0x7f08655c87df in os::strdup(char const*, MEMFLAGS) /home/azul/azul/openjdk-git/src/hotspot/share/runtime/os.cpp:605 #8 0x7f0862c7a26f in CgroupController::CgroupController(char*, char*, bool) /home/azul/azul/openjdk-git/src/hotspot/os/linux/cgroupSubsystem_linux.hpp:170 I plan to fix the ugly value-copy in a later refactorization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673497620 From asotona at openjdk.org Thu Jul 11 07:00:57 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 11 Jul 2024 07:00:57 GMT Subject: [jdk23] RFR: 8335935: Chained builders not sending transformed models to next transforms In-Reply-To: References: Message-ID: <4X8df8jvEozKCh3fiMNVp7wXPgzIdku-1OEW2kn6bvY=.a0f8168a-9b9f-437a-bc4b-a543ce77cd45@github.com> On Wed, 10 Jul 2024 22:10:50 GMT, Chen Liang wrote: > Please review this non-clean backport of the bugfix in #20100 to release 23, where ClassFile API chained builders does not emit certain elements through downstream transforms and returns wrong builder for chaining. This backport includes an additional change that rolls back a rename done in #19952 that applies to the new test, intended for 24 only. Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20127#pullrequestreview-2171073501 From dnsimon at openjdk.org Thu Jul 11 07:06:05 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 11 Jul 2024 07:06:05 GMT Subject: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote: >> This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: >> 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). >> 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. >> 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. >> >> An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. >> >> To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > fixed TestTranslatedException Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20083#issuecomment-2222187035 From dnsimon at openjdk.org Thu Jul 11 07:06:06 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 11 Jul 2024 07:06:06 GMT Subject: Integrated: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation In-Reply-To: References: Message-ID: <1hewrnDIw6jXlNydTQvT_A8ODaargcrVJyJkufOH-74=.baa6e8b9-e84e-43a1-bc85-ea4dc3c9b28b@github.com> On Mon, 8 Jul 2024 19:01:05 GMT, Doug Simon wrote: > This PR addresses intermittent failures in jtreg GC stress tests. The failures occur under these conditions: > 1. Using a libgraal build with assertions enabled as the top tier JIT compiler. Such a libgraal build will cause a VM exit if an assertion or GraalError occurs in a compiler thread (as this catches more errors in testing). > 2. A libgraal compiler thread makes a call into the VM (via `CompilerToVM`) to a routine that performs a HotSpot heap allocation that fails. > 3. The resulting OOME is wrapped in a GraalError, causing the VM to exit as described in 1. > > An OOME thrown in these specific conditions should not exit the VM as it not related to an OOME in the app or test. Instead, the failure should be treated as a bailout and the libgraal compiler should continue. > > To accomplish this, libgraal needs to be able to distinguish a GraalError caused by an OOME. This PR modifies the exception translation code to make this possible. This pull request has now been integrated. Changeset: cf940e13 Author: Doug Simon URL: https://git.openjdk.org/jdk/commit/cf940e139a76e5aabd52379b8a87065d82b2284c Stats: 103 lines in 6 files changed: 62 ins; 22 del; 19 mod 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation Reviewed-by: yzheng, never, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/20083 From sgehwolf at openjdk.org Thu Jul 11 09:15:58 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 11 Jul 2024 09:15:58 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 03:39:37 GMT, Jan Kratochvil wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into jdk-8333446-systemd-slice-tests >> - Merge branch 'master' into jdk-8333446-systemd-slice-tests >> - Fix comments >> - 8333446: Add tests for hierarchical container support > > test/hotspot/jtreg/ProblemList.txt line 119: > >> 117: containers/docker/TestMemoryAwareness.java 8303470 linux-all >> 118: containers/docker/TestJFREvents.java 8327723 linux-x64 >> 119: containers/systemd/SystemdMemoryAwarenessTest.java 8322420 linux-all > > This line should be removed as long as it gets applied after [17198](https://github.com/openjdk/jdk/pull/17198). Sure. We need to see which one goes in first and I'll adjust accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1673683205 From sgehwolf at openjdk.org Thu Jul 11 09:26:55 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 11 Jul 2024 09:26:55 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: References: Message-ID: <0U-PWBKKJ7mHmK_GQ77s_gZ0tPRbRIsQcdjJRWdVmGg=.8b319781-3628-400b-b9d7-c0750a2a8637@github.com> On Thu, 11 Jul 2024 03:42:27 GMT, Jan Kratochvil wrote: > [test.patch.txt](https://github.com/user-attachments/files/16171122/test.patch.txt) > > * `CPUQuota` (changed it to `AllowedCPUs`) does not work for me - it properly distributes the load but JDK still sees all available CPU cores (4 of my VM). Could you elaborate on that? What does not work? It's relying on the JVM properly detecting the set limit. `CPUQuota` sets the values in `cpu.max` on unified hierarchy for the `cpu` controller. See the [systemd doc](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html). It's available since systemd 213. RHEL 7 has 219 which should be good enough. `AllowedCPUs` on the other hand uses the `cpuset` controller, which is a different thing. For the purpose of this test, we should use `CPUQuota`. > * the change 2 -> 1 cores: // We could check 2 cores ("0-1") but then it would fail on single-core nodes / virtual machines. Yeah, we have a chicken/egg problem there. It seemed assuming 2 cores is reasonable. We could query the number of not restricted CPUs (of the physical system) using the WB API and take the minimum of the two. Let me work on that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2222448285 From yzheng at openjdk.org Thu Jul 11 09:29:00 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 11 Jul 2024 09:29:00 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v5] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 20:10:07 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with four additional commits since the last revision: > > - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object > - Fix typos > - Remove unused variable > - Add missing inline qualifiers src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 843: > 841: movptr(monitor, Address(box, BasicLock::object_monitor_cache_offset_in_bytes())); > 842: // null check with ZF == 0, no valid pointer below alignof(ObjectMonitor*) > 843: cmpptr(monitor, alignof(ObjectMonitor*)); Is this only for keeping `ZF == 0` and can be replaced by `test; je` if we are not using `jne` to jump to the slow path? Or is there any performance concern? Btw, I think `ZF` is always rewritten before entering into the slow path https://github.com/openjdk/jdk/blob/b32e4a68bca588d908bd81a398eb3171a6876dc5/src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp#L98-L102 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673704482 From prappo at openjdk.org Thu Jul 11 09:40:10 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 11 Jul 2024 09:40:10 GMT Subject: RFR: 8336239: Fix javadoc markup in java.lang.Process Message-ID: Was reading Process' documentation the other day and spotted a markup typo. Please review this utmost trivial fix. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/20133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336239 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20133/head:pull/20133 PR: https://git.openjdk.org/jdk/pull/20133 From jpai at openjdk.org Thu Jul 11 09:53:56 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jul 2024 09:53:56 GMT Subject: RFR: 8336239: Fix javadoc markup in java.lang.Process In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 09:36:02 GMT, Pavel Rappo wrote: > Was reading Process' documentation the other day and spotted a markup typo. Please review this utmost trivial fix. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20133#pullrequestreview-2171446396 From shade at openjdk.org Thu Jul 11 10:07:02 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Jul 2024 10:07:02 GMT Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2] In-Reply-To: References: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> Message-ID: On Tue, 11 Jun 2024 08:58:34 GMT, Aleksey Shipilev wrote: >> Sean Gwizdak 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: >> >> - Remove trailing whitespace. >> - Move hashCode benchmark into the newly created MethodBenchmark file >> - Merge branch 'master' into method-hashcode-JDK-8332249 >> - Remove changes to JavaDoc per guidance. >> - Fix whitespace issues pointed by the bot >> - Micro-optimize Method.hashCode > > As usual in these cases, we need to make a footprint argument as well. `Method` is a special class with lots of injected fields, so the only "true" source of layout information is `-XX:+PrintFieldLayout`. It tells me there is a 4-byte tail due to object alignment in compressed oops mode. This can accommodate a new `int` field. There seems to be no space when compressed oops are disabled. > > > # Out of the box, compressed oops enabled > Layout of class java/lang/reflect/Method > Instance fields: > @0 12/- RESERVED > @12 "override" Z 1/1 INHERITED > @13 "callerSensitive" B 1/1 REGULAR > @14 2/1 EMPTY > @16 "accessCheckCache" Ljava/lang/Object; 4/4 INHERITED > @20 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 4/4 INHERITED > @24 "declaredAnnotations" Ljava/util/Map; 4/4 INHERITED > @28 "slot" I 4/4 REGULAR > @32 "modifiers" I 4/4 REGULAR > @36 "clazz" Ljava/lang/Class; 4/4 REGULAR > @40 "name" Ljava/lang/String; 4/4 REGULAR > @44 "returnType" Ljava/lang/Class; 4/4 REGULAR > @48 "parameterTypes" [Ljava/lang/Class; 4/4 REGULAR > @52 "exceptionTypes" [Ljava/lang/Class; 4/4 REGULAR > @56 "signature" Ljava/lang/String; 4/4 REGULAR > @60 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 4/4 REGULAR > @64 "annotations" [B 4/4 REGULAR > @68 "parameterAnnotations" [B 4/4 REGULAR > @72 "annotationDefault" [B 4/4 REGULAR > @76 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 4/4 REGULAR > @80 "root" Ljava/lang/reflect/Method; 4/4 REGULAR > Instance size = 88 bytes > > # -XX:-UseCompressedOops > Layout of class java/lang/reflect/Method > Instance fields: > @0 12/- RESERVED > @12 "override" Z 1/1 INHERITED > @13 "callerSensitive" B 1/1 REGULAR > @14 2/1 EMPTY > @16 "accessCheckCache" Ljava/lang/Object; 8/8 INHERITED > @24 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 8/8 INHERITED > @32 "declaredAnnotations" Ljava/util/Map; 8/8 INHERITED > @40 "slot" I 4/4 REGULAR > @44 "modifiers" I 4/4 REGULAR > @48 "clazz" Ljava/lang/Class; 8/8 REGULAR > @56 "name" Ljava/lang/String; 8/8 REGULAR > @64 "returnType" Ljava/lang/Class; 8/8 REGULAR > @72 "parameterTypes" [Ljava/lang/Class; 8/8 REGULAR > @80 "exceptionTypes" [Ljava/lang/Class; 8/8 REGULAR > @88 "signature" Ljava/lang/String; 8/8 REGULAR > @96 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 8/8 REGULAR > @104 "annotations" [B 8/8 REGULAR > @112 "parameterAnnotations" [B 8/8 REGULAR > @120 "annotationDefault" [B 8/8 REGULAR > @128 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 8/8 REGULAR > @136 "root" Ljava/... > @shipilev Any recommendations on reducing footprint size? I see two ways from here: 1. There seems to be a 2-byte gap in the object, so if we can squeeze out 2 additional bytes, it would allow us to put another `int` in. It looks like `slot` does not have to be `int`: on VM side, it is `u2` (unsigned 2-byte), which might be just `short` or `char` with proper precautions about signs and conversions. That would probably be a bit ugly. 2. Ignore this regression and move on. It would have been a non-issue if `Method`-s were canonicalized/de-duplicated in some way. But AFAICS, `Method`-s are getting copied from `Class.getDeclaredMethods`, so it is probable we have quite a few instances floating around, and footprint regressions would stack up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2222532168 From prappo at openjdk.org Thu Jul 11 10:11:59 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 11 Jul 2024 10:11:59 GMT Subject: Integrated: 8336239: Fix javadoc markup in java.lang.Process In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 09:36:02 GMT, Pavel Rappo wrote: > Was reading Process' documentation the other day and spotted a markup typo. Please review this utmost trivial fix. This pull request has now been integrated. Changeset: 6fcd49f9 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/6fcd49f9431cc3507f96ef2acdca43fc6a394a14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8336239: Fix javadoc markup in java.lang.Process Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/20133 From aboldtch at openjdk.org Thu Jul 11 10:41:57 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Jul 2024 10:41:57 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v5] In-Reply-To: References: Message-ID: <50LctfChrqd3_HlWrKZKsq4gADeTHWqY1SuFMSwzpL4=.6c6df72a-9bdd-4390-a38d-5d1ee95b8543@github.com> On Thu, 11 Jul 2024 09:25:52 GMT, Yudi Zheng wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object >> - Fix typos >> - Remove unused variable >> - Add missing inline qualifiers > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 843: > >> 841: movptr(monitor, Address(box, BasicLock::object_monitor_cache_offset_in_bytes())); >> 842: // null check with ZF == 0, no valid pointer below alignof(ObjectMonitor*) >> 843: cmpptr(monitor, alignof(ObjectMonitor*)); > > Is this only for keeping `ZF == 0` and can be replaced by `test; je` if we are not using `jne` to jump to the slow path? Or is there any performance concern? Btw, I think `ZF` is always rewritten before entering into the slow path https://github.com/openjdk/jdk/blob/b32e4a68bca588d908bd81a398eb3171a6876dc5/src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp#L98-L102 You are correct the condition flag is not important here. At some point we had more than just `nullptr` and and `ObjectMonitor*` values, but also some small signal values which allowed us to move some slow path code into the runtime. When this was removed I just made the checks do the same on both aarch64 and x86. (Where aarch64 does not have a stub and jumps directly to the continuation requiring the correct condition flags after the branch.) _Side note: This might be something that will be explored further in the future. And allow to move a lot of the LM_LIGHTWEIGHT slow path code away from the lock node and code stub into the runtime._ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673800250 From jvernee at openjdk.org Thu Jul 11 12:45:01 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 11 Jul 2024 12:45:01 GMT Subject: [jdk23] Integrated: 8333884: MemorySegment::reinterpret removes read-only property In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 17:01:00 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 6 Jul 2024 and was reviewed by Jorn Vernee and Maurizio Cimadamore. > > Thanks! This pull request has now been integrated. Changeset: 9620b912 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/9620b912dd4be0b5c7440d0f9a0d8456e2ad1cd7 Stats: 38 lines in 4 files changed: 30 ins; 1 del; 7 mod 8333884: MemorySegment::reinterpret removes read-only property Reviewed-by: liach, sundar Backport-of: 6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef ------------- PR: https://git.openjdk.org/jdk/pull/20119 From sgehwolf at openjdk.org Thu Jul 11 13:01:10 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 11 Jul 2024 13:01:10 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Thu, 11 Jul 2024 06:54:27 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Designed by Severin Gehwolf, implemented by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: > > - Fix the gtest > - fix compilation warning > - fix the gtest > - less refactorizations > - remove not a real backward compat. > - whitespace > - less refactorizations > - reduce refactorizations > - Fix caching > - Merge branch 'master' into master-cgroup > - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 Conceptually, I think it would be cleaner if we did the "trim" action at construction time of `Subsystem` on a per controller basis. The path is a property of the controller. It would be best do do it before caching is set up. A couple of other comments: - We should fix Hotspot first (this bug) and do the Metrics (java) change in a separate patch - As soon as we have found a lower limit we can stop. Hierarchies which have a higher limit than the parent are ill-formed, and we can ignore it. - We ought to also trim the path for the CPU controller. This patch only fixes the memory controller. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 836: > 834: > 835: void CgroupController::set_path(const char *cgroup_path) { > 836: __attribute__((unused)) bool _cgroup_path; // Do not use the member variable. This seems an unusual pattern for Hotspot. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 910: > 908: memory_swap_limit_min = memory_swap_limit; > 909: best_level = dir_count; > 910: } There is no point in doing memory and memory and swap. Both are controlled by the same controller. So there is no chance that the paths would differ. src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 237: > 235: _metrics_cache = new CachedMetric(); > 236: return controller()->trim_path(dir_count); > 237: } We should get away with only doing it for the actual underlying controllers. I.e. we should do it before caching is set up. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 78: > 76: return (jlong)hier_memlimit; > 77: } > 78: log_trace(os, container)("Hierarchical Memory Limit is: Unlimited"); It is the hope to no longer needing to do this hierarchical look-up since we know where in the hierarchy we ought to look for the memory limit. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 116: > 114: log_trace(os, container)("Hierarchical Memory and Swap Limit is: Unlimited"); > 115: } else { > 116: return (jlong)hier_memswlimit; Same here. Hierarchical look-ups shouldn't be needed if we do this correctly. src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp line 36: > 34: class CgroupV1Controller: public CgroupController { > 35: public: > 36: using CgroupController::CgroupController; Inheriting constructors are not permitted as per the Hotspot style-guide: https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#inheriting-constructors test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp line 1: > 1: /* Why are those test changes needed? test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 1: > 1: /* I think a more generic solution would be to use https://bugs.openjdk.org/browse/JDK-8333446 for testing (requires only systemd vs. this requiring libcg). A hierarchy setup of two limits should be possible with it too, though I'm doubtful that's needed. ------------- PR Review: https://git.openjdk.org/jdk/pull/17198#pullrequestreview-2171534036 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673955179 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673958522 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673952238 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673797261 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673798080 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673795471 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673800271 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1673806004 From coleenp at openjdk.org Thu Jul 11 13:11:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Jul 2024 13:11:04 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: On Wed, 10 Jul 2024 09:41:08 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/arguments.cpp line 1830: >> >>> 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT); >>> 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT"); >>> 1830: } >> >> Maybe we want this to have the opposite sense - turn off UseObjectMonitorTable if not LM_LIGHTWEIGHT? > > Maybe. It boils down to what to do when the JVM receives `-XX:LockingMode={LM_LEGACY,LM_MONITOR} -XX:+UseObjectMonitorTable` > The options I see are > 1. Select `LockingMode=LM_LIGHTWEIGHT` > 2. Select `UseObjectMonitorTable=false` > 3. Do not start the VM > > Between 1. and 2. it is impossible to know what the real intentions were. But with being a newer `-XX:+UseObjectMonitorTable` it somehow seems more likely. > > Option 3. is probably the sensible solution, but it is hard to determine. We tend to not close the VM because of incompatible options, rather fix them. But I believe there are precedence for both. If we do this however we will have to figure out all the interactions with our testing framework. And probably add some safeguards. UseObjectMonitorTable is a Diagnostic option and LockingMode is (Deprecated) but a full-fledged product option, so I think the product option should override. So I pick 2. They might have changed to Legacy to compare performance or something like that, and missed that the table is only for lightweight locking when switching the command line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673989707 From duke at openjdk.org Thu Jul 11 13:13:10 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 13:13:10 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. @weibxiao Your change (at version 5903a482db3c3e84adeb13609e8f4497f49eaeca) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16502#issuecomment-1834214000 From coleenp at openjdk.org Thu Jul 11 13:13:57 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Jul 2024 13:13:57 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: <7_99_ouQ3MAtPFgIQzG01AlOOgFLGPrK1h1LMzzhK60=.0578b32c-8f8b-460c-a5c1-e5686369aba5@github.com> On Wed, 10 Jul 2024 09:41:37 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 763: >> >>> 761: assert(mark.has_monitor(), "must be"); >>> 762: // The monitor exists >>> 763: ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(current, object, mark); >> >> This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? Or we got here because BasicLock.metadata was not the ObjectMonitor? > >> This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? > > We could. > >> Or we got here because BasicLock.metadata was not the ObjectMonitor? > > That is one reason we got here. We also get here from C1/interpreter as well as if there are other threads on the entry queues. > > I think there was an assumption that it would not be that crucial in those cases. > > One off the reasons we do not read the `BasicLock` cache from the runtime is that we are not as careful with keeping the `BasicLock` initialised on platforms without `UseObjectMonitorTable`. The idea was that as long as they call into the VM, we do not need to keep it invariant. > > But this made me realise `BasicLock::print_on` will be broken on non x86/aarch64 platforms if running with `UseObjectMonitorTable`. > > Rather then fix all platforms I will condition BasicLock::object_monitor_cache to return nullptr on not supported platforms. > > Could add this then. Should probably add an overload to `ObjectSynchronizer::read_monitor` which takes the lock and push i all the way here. I think I'd prefer not another overloading of read_monitor. It's kind of confusing as is. This is okay and we'll see if there's any performance benefit to checking BasicLock instead later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673993770 From wxiao at openjdk.org Thu Jul 11 13:25:56 2024 From: wxiao at openjdk.org (Weibing Xiao) Date: Thu, 11 Jul 2024 13:25:56 GMT Subject: [jdk23] RFR: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 In-Reply-To: References: Message-ID: <37TEpPA1pn28CwVcBy65eqnSvG2J2LmligBz9svA-4w=.3981738d-7812-48be-81e0-59d7ebf81a61@github.com> On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This updates the IANA subtag registry to version 2024-06-14. The change was merged into jdk23, see the commmit https://github.com/openjdk/jdk/pull/20125 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20125#issuecomment-2222931615 From jkratochvil at openjdk.org Thu Jul 11 14:28:55 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 11 Jul 2024 14:28:55 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: <0U-PWBKKJ7mHmK_GQ77s_gZ0tPRbRIsQcdjJRWdVmGg=.8b319781-3628-400b-b9d7-c0750a2a8637@github.com> References: <0U-PWBKKJ7mHmK_GQ77s_gZ0tPRbRIsQcdjJRWdVmGg=.8b319781-3628-400b-b9d7-c0750a2a8637@github.com> Message-ID: On Thu, 11 Jul 2024 09:23:58 GMT, Severin Gehwolf wrote: > > ``` > > * `CPUQuota` (changed it to `AllowedCPUs`) does not work for me - it properly distributes the load but JDK still sees all available CPU cores (4 of my VM). > > ``` > > Could you elaborate on that? What does not work? In the log there is (`/proc/cpuinfo` has 4 entries on this system): [0.139s][trace][os,container] OSContainer::active_processor_count: 4 and therefore it fails with: ``` java.lang.RuntimeException: 'OSContainer::active_processor_count: 2' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252) at SystemdMemoryAwarenessTest.testHelloSystemd(SystemdMemoryAwarenessTest.java:58) at SystemdMemoryAwarenessTest.main(SystemdMemoryAwarenessTest.java:43) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1575) It is on Fedora 40 x86_64 (`systemd-255.8-1.fc40.x86_64`). ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2223083324 From sgehwolf at openjdk.org Thu Jul 11 14:39:55 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 11 Jul 2024 14:39:55 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v3] In-Reply-To: References: <0U-PWBKKJ7mHmK_GQ77s_gZ0tPRbRIsQcdjJRWdVmGg=.8b319781-3628-400b-b9d7-c0750a2a8637@github.com> Message-ID: On Thu, 11 Jul 2024 14:26:23 GMT, Jan Kratochvil wrote: > > > ``` > > > * `CPUQuota` (changed it to `AllowedCPUs`) does not work for me - it properly distributes the load but JDK still sees all available CPU cores (4 of my VM). > > > ``` > > > > > > Could you elaborate on that? What does not work? > > In the log there is (`/proc/cpuinfo` has 4 entries on this system): > > ``` > [0.139s][trace][os,container] OSContainer::active_processor_count: 4 > ``` > > and therefore it fails with: > > ``` > java.lang.RuntimeException: 'OSContainer::active_processor_count: 2' missing from stdout/stderr > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252) > at SystemdMemoryAwarenessTest.testHelloSystemd(SystemdMemoryAwarenessTest.java:58) > at SystemdMemoryAwarenessTest.main(SystemdMemoryAwarenessTest.java:43) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) > at java.base/java.lang.Thread.run(Thread.java:1575) > ``` > > It is on Fedora 40 x86_64 (`systemd-255.8-1.fc40.x86_64`). Well yes, because the limit isn't properly detected (needs a JVM change that does that; imo https://github.com/openjdk/jdk/pull/17198). ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2223109654 From rgiulietti at openjdk.org Thu Jul 11 14:47:56 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 11 Jul 2024 14:47:56 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the overridable methods of Object. Here's a classical example of a directed acyclic graph (DAG, no cycles) consisting of 100 `ArrayList`s, each of size 2. It takes some 1000x the _age of the universe_ to compute `hashCode()` or to compare two such DAGs with `equals()`, so no machine will ever come to completion. And `toString()` throws an OOME because the results wouldn't fit in the limits of `String`. This is to say that even without cycles and even with quite small data structures as here, we might encounter excessive resource usages in space or time by just invoking these methods. (The same would hold by replacing `ArrayList` with a `record` of 2 components that does not override the default methods.) import java.util.ArrayList; public class DAG { private static final int DEPTH = 100; public static void main(String[] args) { ArrayList dag0 = createSmallDAG(); ArrayList dag1 = createSmallDAG(); System.out.println(dag0.equals(dag1)); System.out.println(dag0.hashCode()); System.out.println(dag0); } private static ArrayList createSmallDAG() { ArrayList n = growDAG(null); for (int i = 1; i < DEPTH; ++i) { n = growDAG(n); } return n; } private static ArrayList growDAG(ArrayList n) { ArrayList m = new ArrayList<>(); m.add(n); m.add(n); return m; } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/20128#issuecomment-2223130481 From syan at openjdk.org Thu Jul 11 15:13:55 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 11 Jul 2024 15:13:55 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote: > Hi all, > Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. > I think it's necessory to receive jvm options from jtreg. > Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850). ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2223198687 From sgehwolf at openjdk.org Thu Jul 11 16:46:13 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 11 Jul 2024 16:46:13 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v4] In-Reply-To: References: Message-ID: > Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges. > > I'm adding those tests in order to not regress another time. > > Testing: > - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1. > - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to JDK-8322420) > - [x] GHA Severin Gehwolf 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: - Add Whitebox check for host cpu - Merge branch 'master' into jdk-8333446-systemd-slice-tests - Merge branch 'master' into jdk-8333446-systemd-slice-tests - Merge branch 'master' into jdk-8333446-systemd-slice-tests - Fix comments - 8333446: Add tests for hierarchical container support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19530/files - new: https://git.openjdk.org/jdk/pull/19530/files/22141a48..139a9069 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=02-03 Stats: 13132 lines in 454 files changed: 8669 ins; 2561 del; 1902 mod Patch: https://git.openjdk.org/jdk/pull/19530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19530/head:pull/19530 PR: https://git.openjdk.org/jdk/pull/19530 From sgehwolf at openjdk.org Thu Jul 11 16:59:56 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 11 Jul 2024 16:59:56 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v4] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 16:46:13 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges. >> >> I'm adding those tests in order to not regress another time. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1. >> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to JDK-8322420) >> - [x] GHA > > Severin Gehwolf 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: > > - Add Whitebox check for host cpu > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Fix comments > - 8333446: Add tests for hierarchical container support Example test run on cgv1 with a fixed JVM: https://cr.openjdk.org/~sgehwolf/webrevs/jdk-8333446-systemd-slice-tests/cgv1/SystemdMemoryAwarenessTest.jtr Example test run on cgv2 with a fixed JVM: https://cr.openjdk.org/~sgehwolf/webrevs/jdk-8333446-systemd-slice-tests/cgv2/SystemdMemoryAwarenessTest.jtr ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2223432957 From duke at openjdk.org Thu Jul 11 17:41:14 2024 From: duke at openjdk.org (Olivier Masseau) Date: Thu, 11 Jul 2024 17:41:14 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: <4QqW1hotlgDnm9hH4MuBpGKWzToVRYLc210z_fKfIyY=.08683fe9-6ecf-4390-97e4-009438e77ace@github.com> On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. Hello, Has this been backported to Java 8 ? I can't really find the info. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16502#issuecomment-2222903484 From iris at openjdk.org Thu Jul 11 18:33:28 2024 From: iris at openjdk.org (Iris Clark) Date: Thu, 11 Jul 2024 18:33:28 GMT Subject: [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This change incorporates the ISO 4217 Amendment 177 Update. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20126#pullrequestreview-2172722556 From iris at openjdk.org Thu Jul 11 18:43:02 2024 From: iris at openjdk.org (Iris Clark) Date: Thu, 11 Jul 2024 18:43:02 GMT Subject: [jdk23] RFR: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 In-Reply-To: References: Message-ID: <-5S7_MmoHm8iFJAHSn9gd3uUK1CV6117vka_JIKFJHo=.2ceedf92-864b-46bc-9a71-d6392acde75c@github.com> On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This updates the IANA subtag registry to version 2024-06-14. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20125#pullrequestreview-2172753557 From joehw at openjdk.org Thu Jul 11 18:43:08 2024 From: joehw at openjdk.org (Joe Wang) Date: Thu, 11 Jul 2024 18:43:08 GMT Subject: Integrated: 8336021: Doccheck: valign not allowed for HTML5 in java.xml In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 16:24:01 GMT, Joe Wang wrote: > Remove valign Attribute from the javadoc for org.w3c.dom.Attr. The table looks good with the default setting. This pull request has now been integrated. Changeset: 58c98420 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/58c98420b65bcea08f37982fdfba747005c03553 Stats: 23 lines in 1 file changed: 0 ins; 2 del; 21 mod 8336021: Doccheck: valign not allowed for HTML5 in java.xml Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/20117 From jlu at openjdk.org Thu Jul 11 18:44:05 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 Jul 2024 18:44:05 GMT Subject: Integrated: 8335668: NumberFormat integer only parsing should throw exception for edge case In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 18:42:25 GMT, Justin Lu wrote: > Please review this PR which corrects a case in NumberFormat integer only parsing. > > [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only parsing when the value has a suffix, although it caused incorrect behavior for the following case: when the parsed string does not contain an integer portion, and the format has integer only parsing, parsing should fail, instead of 0 being returned. For example, > > > var fmt = NumberFormat.getIntegerInstance(); > fmt.parse(".5", new ParsePosition(0)); // should return null, not 0 > > > The changes to the _badParseStrings_ data provider in _StrictParseTest.java_ are needed since those cases _should_ fail in different indexes depending on if integer parsing is enabled. Thus, they were updated to ensure they fail for both integer and non-integer parsing with the same errorIndex. > > In the fix itself, I also updated the initial value of `intIndex` to -1 from 0, to provide better clarity. This pull request has now been integrated. Changeset: 5100303c Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/5100303c6c5e4224d2c41f90719139bb5f4e236e Stats: 67 lines in 3 files changed: 56 ins; 0 del; 11 mod 8335668: NumberFormat integer only parsing should throw exception for edge case Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/20101 From lowasser at google.com Tue Jul 9 19:27:16 2024 From: lowasser at google.com (Louis Wasserman) Date: Tue, 9 Jul 2024 12:27:16 -0700 Subject: More useful structured concurrency stack traces In-Reply-To: References: Message-ID: Moved to loom-dev; core-libs-dev to bcc. On Tue, Jul 9, 2024 at 12:10?PM Alan Bateman wrote: > Probably best to bring this to loom-dev as there have been some > exploration into but where we decided not to expose any APIs at this time. > > -Alan > > On 09/07/2024 19:50, Louis Wasserman wrote: > > My understanding of the structured concurrency APIs now in preview is that > when a subtask is forked, exceptions thrown in that stack trace will have > stack traces going up to the beginning of that subtask, not e.g. up the > structured concurrency task tree. (My tests suggest this is the case for > simple virtual threads without structured concurrency.) Most concurrency > frameworks on the JVM that I?ve encountered share the property that stack > traces for exceptions don?t trace through the entire causal chain ? and, > not unrelatedly, that developers struggle to debug concurrent applications, > especially with stack traces from production and not full debuggers > attached. > > In some cases, like chained CompletableFutures, this seems necessary to > ensure that executing what amounts to a loop does not result in stack > traces that grow linearly with the number of chained futures. But when > structured concurrency is involved, it seems more plausible to me that the > most useful possible stack traces would go up the tree of tasks ? that is, > whenever a task was forked, the stack trace would look roughly as if it > were a normal/sequential/direct invocation of the task. This could > conceivably cause stack overflows where they didn?t happen before, but only > for code that violates the expectations we have around normal sequential > code: you can?t recurse unboundedly; use iteration instead. > > I?m curious if there are ways we could make the upcoming structured > concurrency APIs give those stack traces all the way up the tree, or > provide hooks to enable you to do that yourself. Last year?s JVMLS talk on > Continuations Under the Covers demonstrated how stacks were redesigned in > ways that frequently and efficiently snapshot the stack itself ? not just > the trace, but the thing that includes all the variables in use. There?s a > linked list of StackChunks, and all but maybe the top of the stack has > those elements frozen, etc, and the top of the stack gets frozen when the > thread is yielded. Without certainty about how stack traces are managed in > the JVM today, I would imagine you could possibly do something similar ? > you?d add a way to cheaply snapshot a reference to the current stack trace > that can be traversed later. If you?re willing to hold on to all the > references currently on the stack ? which might be acceptable for the > structured concurrency case in particular, where you might be able to > assume you?ll return to the parent task and its stack at some point ? you > might be able to do this by simply wrapping the existing StackChunks. > Then, each `fork` or `StructuredTaskScope` creation might snapshot the > current call stack, and you?d stitch together the stack traces > later?somewhere. That part is a little more open ended: would you add a > new variant of `fillInStackTrace`? Would it only apply to exceptions that > bubbled up to the task scope? Or would we be adding new semantics to what > happens when you throw an exception or walk the stack in general? The most > plausible vision I have at this point is an API that spawns a virtual > thread which receives a stack trace of some sort ? or perhaps snapshots the > current stack trace ? and prepends that trace to all stack traces within > the virtual thread?s execution. > > I suppose this is doable today if you?re willing to pay the performance > cost of explicitly getting the current stack trace every time you fork a > task or start a scope. That is kind of antithetical to the point of > virtual threads ? making forking tasks very efficient ? but it?s something > you might be willing to turn on during testing. > > Right now, my inspiration for this question is attempting to improve the > stack trace situation with Kotlin coroutines, where Google production apps > have complained about the difficulty of debugging with the current stack > traces. But this is something I'd expect to apply equally well to all JVM > languages: the ability to snapshot and string together stack trace causal > chains like this in production could significantly improve the experience > of debugging concurrent code. > > -- > Louis Wasserman > > > -- Louis Wasserman (he/they) -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Thu Jul 11 19:19:20 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Jul 2024 19:19:20 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear Message-ID: [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks. Additional testing: - [x] Linux x86_64 server fastdebug, `all` - [ ] Linux AArch64 server fastdebug, `all` ------------- Commit messages: - Move the membar at the end - Revert C1 parts - Work Changes: https://git.openjdk.org/jdk/pull/20139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329597 Stats: 132 lines in 7 files changed: 132 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139 PR: https://git.openjdk.org/jdk/pull/20139 From shade at openjdk.org Thu Jul 11 19:19:20 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Jul 2024 19:19:20 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote: > [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` On Mac AArch64, which suffers from both native call and WX transition: Benchmark Mode Cnt Score Error Units # Intrinsic OFF ReferenceClear.phantom avgt 9 52,297 ? 0,294 ns/op ReferenceClear.phantom_new avgt 9 57,075 ? 0,296 ns/op ReferenceClear.soft avgt 9 52,567 ? 0,393 ns/op ReferenceClear.soft_new avgt 9 57,640 ? 0,264 ns/op ReferenceClear.weak avgt 9 53,018 ? 1,285 ns/op ReferenceClear.weak_new avgt 9 57,227 ? 0,483 ns/op # Intrinsic ON (default) ReferenceClear.phantom avgt 9 0,780 ? 0,017 ns/op ReferenceClear.soft avgt 9 0,784 ? 0,022 ns/op ReferenceClear.weak avgt 9 0,793 ? 0,033 ns/op ReferenceClear.phantom_new avgt 9 3,018 ? 0,015 ns/op ReferenceClear.soft_new avgt 9 3,268 ? 0,014 ns/op ReferenceClear.weak_new avgt 9 3,004 ? 0,057 ns/op On x86_64 m7a.16xlarge, which only suffers from the native call: Benchmark Mode Cnt Score Error Units # Intrinsic OFF ReferenceClear.phantom avgt 9 14.643 ? 0.049 ns/op ReferenceClear.soft avgt 9 14.939 ? 0.438 ns/op ReferenceClear.weak avgt 9 14.648 ? 0.081 ns/op ReferenceClear.phantom_new avgt 9 19.859 ? 2.405 ns/op ReferenceClear.soft_new avgt 9 20.208 ? 1.805 ns/op ReferenceClear.weak_new avgt 9 20.385 ? 2.570 ns/op # Intrinsic ON (default) ReferenceClear.phantom avgt 9 0.821 ? 0.010 ns/op ReferenceClear.soft avgt 9 0.817 ? 0.007 ns/op ReferenceClear.weak avgt 9 0.819 ? 0.010 ns/op ReferenceClear.phantom_new avgt 9 4.195 ? 0.729 ns/op ReferenceClear.soft_new avgt 9 4.315 ? 0.599 ns/op ReferenceClear.weak_new avgt 9 3.986 ? 0.596 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2223248114 From smarks at openjdk.org Thu Jul 11 20:33:51 2024 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Jul 2024 20:33:51 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the overridable methods of Object. Bloch's _Effective Java, 3/e,_ Items 10, 11, and 12 have some useful background information on implementing equals, hashCode, and toString. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20128#issuecomment-2223871986 From liach at openjdk.org Thu Jul 11 20:53:55 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Jul 2024 20:53:55 GMT Subject: [jdk23] Integrated: 8335935: Chained builders not sending transformed models to next transforms In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:10:50 GMT, Chen Liang wrote: > Please review this non-clean backport of the bugfix in #20100 to release 23, where ClassFile API chained builders does not emit certain elements through downstream transforms and returns wrong builder for chaining. This backport includes an additional change that rolls back a rename done in #19952 that applies to the new test, intended for 24 only. This pull request has now been integrated. Changeset: 06191aca Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/06191aca86cff4b83de9f0bb1b8f35c11b5f6266 Stats: 293 lines in 10 files changed: 169 ins; 97 del; 27 mod 8335935: Chained builders not sending transformed models to next transforms Reviewed-by: asotona Backport-of: cad68e06ecad1e19091d1af9c0f9b8145d6842fb ------------- PR: https://git.openjdk.org/jdk/pull/20127 From nbenalla at openjdk.org Thu Jul 11 21:02:03 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 11 Jul 2024 21:02:03 GMT Subject: RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation Message-ID: Can I please get a review for this small change, the relative link to the stylesheet isn't needed as it wasn't used anyway in the generated HTML. The correct link to the stylesheet is already in the generated HTML. This is the difference between the generated docs before and after this change, by running `diff -r` on the docs before and after the change. GeneratedDocs % diff -r 8336259-stylesheet old-docs diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html old-docs/api/java.base/java/lang/doc-files/ValueBased.html 13a14 > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html old-docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html 13a14 > Here is the link for the generated docs after the change, no visual change is seen but the erronous link is gone. Value based classes [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/ValueBased.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html) Java Thread Primitive Deprecation [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) ------------- Commit messages: - (C) - remove incorrect link to stylesheet Changes: https://git.openjdk.org/jdk/pull/20145/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20145&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336259 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20145.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20145/head:pull/20145 PR: https://git.openjdk.org/jdk/pull/20145 From duke at openjdk.org Thu Jul 11 21:16:58 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:16:58 GMT Subject: RFR: 8333749: Consolidate ConstantDesc conversion in java.base [v6] In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang wrote: >> In java.base, especially in bytecode generators, we have many different methods converting known valid Class and MethodType into ClassDesc and MethodTypeDesc. These conversions should be consolidated into the same utility method for the ease of future maintenance. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > ExE-Boss review, go through validated path in Class @liach Your change (at version d3938b4b9f4837dd5697545638e184bd1984fe09) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19585#issuecomment-2155631028 From duke at openjdk.org Thu Jul 11 21:18:08 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:18:08 GMT Subject: RFR: 8332109: Convert remaining tests using com.sun.tools.classfile to ClassFile API In-Reply-To: References: Message-ID: On Sun, 12 May 2024 08:36:44 GMT, Chen Liang wrote: > Some tests are not migrated to the ClassFile API in previous migrations. > > - Some are simple oversights that didn't remove usages of com.sun.tools.classfile; > - The CallerSensitive ones used an old utility, replaced by CF API-based new code; > - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`; > - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs. > > Testing: all modified tests pass. @liach Your change (at version 4880f3a375ff46a4be94d0fe483f8ec927f1933a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19206#issuecomment-2117386568 From duke at openjdk.org Thu Jul 11 21:18:08 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:18:08 GMT Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated [v2] In-Reply-To: <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com> References: <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com> Message-ID: On Fri, 10 May 2024 04:55:21 GMT, Chen Liang wrote: >> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it. >> >> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Add CDS test case to ensure LF resolution success @liach Your change (at version fc393dbc16bf8e726f3b7ea3cd5d7a3bd0e79630) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19164#issuecomment-2105504638 From duke at openjdk.org Thu Jul 11 21:18:04 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:18:04 GMT Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull [v6] In-Reply-To: References: Message-ID: On Wed, 29 May 2024 19:27:17 GMT, Chen Liang wrote: >> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles. >> >> Requesting a review from @asotona. Thanks! >> >> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html > > 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 10 additional commits since the last revision: > > - Add test to validate ClassReader behavior > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type > - Null-check the entry class eagerly, avoid returning null or throwing IAE > - Remove redundant import > - Use switch > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type > - Use constants, beautify code > - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull @liach Your change (at version e9021f24d905741ac1e836c198789c37c368a166) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19330#issuecomment-2139368471 From duke at openjdk.org Thu Jul 11 21:18:00 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:18:00 GMT Subject: RFR: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the Classfile API [v2] In-Reply-To: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com> References: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com> Message-ID: On Sun, 12 May 2024 02:42:32 GMT, Chen Liang wrote: >> Summary of the changes: >> - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later. >> - A few visitor patterns have been rewritten with pattern matching, notably in: >> - `CPEntries`/`CPSelector` (removed) >> - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies. >> - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`. >> - Otherwise, the changes are mostly mechanical replacements. >> >> All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Migrate omitted getdeps test in langtools @liach Your change (at version be8c25b1175911e6c4c414ca30760abd3c198c1f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19193#issuecomment-2117387196 From duke at openjdk.org Thu Jul 11 21:19:10 2024 From: duke at openjdk.org (duke) Date: Thu, 11 Jul 2024 21:19:10 GMT Subject: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v5] In-Reply-To: References: Message-ID: On Wed, 1 May 2024 22:39:05 GMT, Chen Liang wrote: >> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html >> >> Additional questions: >> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE` > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Missing since tags > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Missed renaming in tests, thanks to Adam Sotona > > Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com> > - Rename no wildcard indicator, improve docs slightly > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Merge branch 'master' into fix/typearg-model > - redundant line > - Fix a test in langtools, copyright year > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - ... and 5 more: https://git.openjdk.org/jdk/compare/0a24daec...f9af4182 @liach Your change (at version f9af4182c35a8ed2e6cc3d2eb230419b3d69f347) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16517#issuecomment-2091977070 From duke at openjdk.org Thu Jul 11 21:29:58 2024 From: duke at openjdk.org (Vanitha B P) Date: Thu, 11 Jul 2024 21:29:58 GMT Subject: Integrated: 8325525: Create jtreg test case for JDK-8325203 In-Reply-To: References: Message-ID: <-dfXOzOlh-AQ7eScoSsEvaeL3277qhga4dXp7XJmxDI=.50a0c78d-77aa-424d-8622-8bdbdaf236e1@github.com> On Tue, 4 Jun 2024 07:13:15 GMT, Vanitha B P wrote: > Created jtreg test case for [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. > > The JpackageTest created tests that the child process started from the app launched by jpackage launcher is not automatically terminated when the the launcher is terminated. This pull request has now been integrated. Changeset: 81a0d1ba Author: Vanitha B P Committer: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/81a0d1ba03bbdbe718302b3925cdc207d5d05232 Stats: 125 lines in 2 files changed: 125 ins; 0 del; 0 mod 8325525: Create jtreg test case for JDK-8325203 Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/19536 From darcy at openjdk.org Thu Jul 11 21:50:51 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 11 Jul 2024 21:50:51 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 00:06:33 GMT, Stuart Marks wrote: > While it's not wrong, advising against "excessive" usage is so vague as not to be actionable. Given some piece of code it's hard to say whether or not it does anything excessive. Consider a List with a million elements; as a practical matter, any one of these methods requires visiting every element. Is that excessive? Why or why not? Hmm. In rare cases, I think providing not-quite-actionable advice is on net helpful. My basic goal here is to convey "when you're implementing these methods, be considerate to your expected users." If that results in some extra contemplation during development or code review about whether or not the worst-case behavior of hashCode/toString/equals is excessive, I think that would be a reasonable outcome from this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1674739279 From darcy at openjdk.org Thu Jul 11 21:56:50 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 11 Jul 2024 21:56:50 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 20:31:07 GMT, Stuart Marks wrote: > Bloch's _Effective Java, 3/e,_ Items 10, 11, and 12 have some useful background information on implementing equals, hashCode, and toString. Agreed; I reread over those items before posting the PR. The "typical" wording was meant to cover guidance like Bloch's "have equals throw an AssertionError if the method should never be called if it escapes its intended domain." ------------- PR Comment: https://git.openjdk.org/jdk/pull/20128#issuecomment-2224008203 From vlivanov at openjdk.org Thu Jul 11 22:33:51 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 11 Jul 2024 22:33:51 GMT Subject: RFR: 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 ... Overall, looks fine. So, there will be `inline_min_max`, `inline_fp_min_max`, and `inline_long_min_max` which slightly vary. I'd prefer to see them unified. (Or, at least, enhance `inline_min_max` to cover `minL`/maxL` cases). Also, it's a bit confusing to see int variants names w/o basic type (`_min`/`_minL` vs `_minI`/`_minL`). Please, clean it up along the way. (FTR I'm also fine handling the renaming as a separate change.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2224062122 From liach at openjdk.org Thu Jul 11 23:00:52 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Jul 2024 23:00:52 GMT Subject: RFR: 8335182: Consolidate and streamline String concat code shapes [v3] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 21:16:33 GMT, Claes Redestad wrote: >> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape >> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. >> >> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements): >> >> >> Name Cnt Base Error Test Error Unit Change >> StringConcat.concat13String 50 66.380 ? 0.189 53.017 ? 0.241 ns/op 1.25x (p = 0.000*) >> StringConcat.concat4String 50 13.620 ? 0.053 12.382 ? 0.089 ns/op 1.10x (p = 0.000*) >> StringConcat.concat6String 50 17.168 ? 0.070 16.046 ? 0.064 ns/op 1.07x (p = 0.000*) >> StringConcat.concatConst2String 50 9.820 ? 0.081 8.158 ? 0.041 ns/op 1.20x (p = 0.000*) >> StringConcat.concatConst4String 50 14.938 ? 0.124 12.800 ? 0.049 ns/op 1.17x (p = 0.000*) >> StringConcat.concatConst6Object 50 56.115 ? 0.288 54.046 ? 0.214 ns/op 1.04x (p = 0.000*) >> StringConcat.concatConst6String 50 19.032 ? 0.073 16.213 ? 0.093 ns/op 1.17x (p = 0.000*) >> StringConcat.concatConstBoolByte 50 8.486 ? 0.066 8.556 ? 0.050 ns/op 0.99x (p = 0.004*) >> StringConcat.concatConstInt 50 8.942 ? 0.052 7.677 ? 0.029 ns/op 1.16x (p = 0.000*) >> StringConcat.concatConstIntConstInt 50 12.883 ? 0.070 12.431 ? 0.070 ns/op 1.04x (p = 0.000*) >> StringConcat.concatConstString 50 7.523 ? 0.050 7.486 ? 0.044 ns/op 1.00x (p = 0.058 ) >> StringConcat.concatConstStringConstInt 50 11.961 ? 0.032 11.699 ? 0.049 ns/op 1.02x (p = 0.000*) >> StringConcat.concatEmptyConstInt 50 7.778 ? 0.038 7.723 ? 0.037 ns/op 1.01x (p = 0.000*) >> StringConcat.concatEmptyConstString 50 3.506 ? 0.026 3.505 ? 0.015 ns/op 1.00x (p = 0.930 ) >> StringConcat.concatEmptyLeft 50 3.573 ? 0.075 3.518 ? 0.057 ns/op 1.02x (p = 0.044 ) >> StringConcat.concatEmptyRight 50 3.713 ? 0.049 3.622 ? 0.053 ns/op 1.02x (p = 0.000*) >> StringConcat.concatMethodConstString 50 7.418 ? 0.030 7.478 ? 0.066 ns/op 0.99x (p... > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Excess blankspace Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19927#pullrequestreview-2173216930 From vlivanov at openjdk.org Fri Jul 12 00:01:56 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 12 Jul 2024 00:01:56 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> On Tue, 2 Jul 2024 14:52:09 GMT, Andrew Haley wrote: > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Looks very good, Andrew! Some comments on minor things follow. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1433: > 1431: > 1432: // Don't check secondary_super_cache > 1433: if (super_check_offset.is_register() Do you see any effects from this particular change? It adds a runtime check on the fast path for all subtype checks (irrespective of whether it checks primary or secondary super). Moreover, the very same check is performed after primary super slot is checked. Unless `_secondary_super_cache` field is removed, unconditionally checking the slot at `super_check_offset` is benign. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1040: > 1038: > 1039: // Secondary subtype checking > 1040: void lookup_secondary_supers_table(Register sub_klass, While browsing the code, I noticed that it's far from evident at call sites which overload is used (especially with so many arguments). Does it make sense to avoid method overloads here and use distinct method names instead? src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 1981: > 1979: __ load_klass(r19_klass, copied_oop);// query the object klass > 1980: > 1981: BLOCK_COMMENT("type_check:"); Why don't you move it inside `generate_type_check`? src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4781: > 4779: Label* L_success, > 4780: Label* L_failure) { > 4781: if (! UseSecondarySupersTable) { Any particular reason to keep the condition negated? (Here and in general. There are multiple places where `!UseSecondarySupersTable` is used.) src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4810: > 4808: Label* L_success, > 4809: Label* L_failure) { > 4810: // NB! Callers may assume that, when temp2_reg is a valid register, Oh, that's a subtle point... Can we make it more evident at call sites? src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5062: > 5060: > 5061: #ifdef DEBUG > 5062: call_VM_leaf_base((address)&poo, /*number_of_arguments*/0); A leftover from debugging? src/hotspot/share/memory/universe.cpp line 443: > 441: > 442: { > 443: Universe::_the_array_interfaces_bitmap = Klass::compute_secondary_supers_bitmap(_the_array_interfaces_array); Cleanup idea: remove `Universe::` prefixes. The rest of the method don't use qualified names for class members. src/hotspot/share/oops/instanceKlass.cpp line 1410: > 1408: return nullptr; > 1409: } else if (num_extra_slots == 0) { > 1410: if (num_extra_slots == 0 && interfaces->length() <= 1) { Since `secondary_supers` are hashed unconditionally now, is `interfaces->length() <= 1` check still needed? src/hotspot/share/oops/instanceKlass.cpp line 3524: > 3522: > 3523: st->print(BULLET"secondary supers: "); secondary_supers()->print_value_on(st); st->cr(); > 3524: { Any particular reason to keep brackets around `hash_slot` and `bitmap`? src/hotspot/share/oops/klass.cpp line 175: > 173: if (secondary_supers()->at(i) == k) { > 174: if (UseSecondarySupersCache) { > 175: ((Klass*)this)->set_secondary_super_cache(k); Does it make sense to assert `UseSecondarySupersCache` in `Klass::set_secondary_super_cache()`? src/hotspot/share/oops/klass.cpp line 284: > 282: // which doesn't zero out the memory before calling the constructor. > 283: Klass::Klass(KlassKind kind) : _kind(kind), > 284: _bitmap(SECONDARY_SUPERS_BITMAP_FULL), I like the idea, but what are the benefits of initializing `_bitmap` separately from `_secondary_supers`? src/hotspot/share/oops/klass.cpp line 469: > 467: #endif > 468: > 469: bitmap = hash_secondary_supers(secondary_supers, /*rewrite=*/true); // rewrites freshly allocated array I like that hashing is performed unconditionally now. Looks like you can remove `UseSecondarySupersTable`-specific CDS support (in `filemap.cpp`). CDS archive should unconditionally contain hashed tables. src/hotspot/share/oops/klass.inline.hpp line 117: > 115: } > 116: > 117: inline bool Klass::search_secondary_supers(Klass *k) const { I see you moved `Klass::search_secondary_supers` in `klass.inline.hpp`, but I'm not sure how it interacts with `Klass::is_subtype_of` (the sole caller) being declared in `klass.hpp`. Will the inlining still happen if `Klass::is_subtype_of()` callers include `klass.hpp`? src/hotspot/share/oops/klass.inline.hpp line 122: > 120: return true; > 121: > 122: bool result = lookup_secondary_supers_table(k); Should `UseSecondarySupersTable` affect `Klass::search_secondary_supers` as well? ------------- PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2161098896 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674812600 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674823519 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674790160 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667194729 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674832710 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667037608 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667194339 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674792021 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667193916 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667190974 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667192207 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667192783 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674806107 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1667193323 From vlivanov at openjdk.org Fri Jul 12 00:01:56 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 12 Jul 2024 00:01:56 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> On Thu, 11 Jul 2024 23:17:10 GMT, Vladimir Ivanov wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1433: > >> 1431: >> 1432: // Don't check secondary_super_cache >> 1433: if (super_check_offset.is_register() > > Do you see any effects from this particular change? > > It adds a runtime check on the fast path for all subtype checks (irrespective of whether it checks primary or secondary super). Moreover, the very same check is performed after primary super slot is checked. > > Unless `_secondary_super_cache` field is removed, unconditionally checking the slot at `super_check_offset` is benign. BTW `MacroAssembler::check_klass_subtype_fast_path` deserves a cleanup: `super_check_offset` can be safely turned into `Register` thus eliminating the code guarded by `super_check_offset.is_register() == false`. > src/hotspot/share/oops/instanceKlass.cpp line 1410: > >> 1408: return nullptr; >> 1409: } else if (num_extra_slots == 0) { >> 1410: if (num_extra_slots == 0 && interfaces->length() <= 1) { > > Since `secondary_supers` are hashed unconditionally now, is `interfaces->length() <= 1` check still needed? Also, `num_extra_slots == 0` check is redundant. > src/hotspot/share/oops/klass.cpp line 284: > >> 282: // which doesn't zero out the memory before calling the constructor. >> 283: Klass::Klass(KlassKind kind) : _kind(kind), >> 284: _bitmap(SECONDARY_SUPERS_BITMAP_FULL), > > I like the idea, but what are the benefits of initializing `_bitmap` separately from `_secondary_supers`? Another observation while browsing the code: `_secondary_supers_bitmap` would be a better name. (Same considerations apply to `_hash_slot`.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674815196 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674798719 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1674828164 From darcy at openjdk.org Fri Jul 12 04:07:50 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 12 Jul 2024 04:07:50 GMT Subject: RFR: 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 ... Marked as reviewed by darcy (Reviewer). Core libs changes looks fine; bumping review count for the remainder of the PR. ------------- PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2173771454 PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2224456985 From jjg at openjdk.org Fri Jul 12 04:08:52 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 12 Jul 2024 04:08:52 GMT Subject: RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote: > Can I please get a review for this small change, the relative link to the stylesheet isn't needed as it wasn't used anyway in the generated HTML. The correct link to the stylesheet is already in the generated HTML. > > This is the difference between the generated docs before and after this change, by running `diff -r` on the docs before and after the change. > > > GeneratedDocs % diff -r 8336259-stylesheet old-docs > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html old-docs/api/java.base/java/lang/doc-files/ValueBased.html > 13a14 >> > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html old-docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html > 13a14 >> > > > Here is the link for the generated docs after the change, no visual change is seen but the erronous link is gone. > Value based classes [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/ValueBased.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html) > > Java Thread Primitive Deprecation [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20145#pullrequestreview-2173773933 From liach at openjdk.org Fri Jul 12 04:37:00 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Jul 2024 04:37:00 GMT Subject: RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote: > Can I please get a review for this small change, the relative link to the stylesheet isn't needed as it wasn't used anyway in the generated HTML. The correct link to the stylesheet is already in the generated HTML. > > This is the difference between the generated docs before and after this change, by running `diff -r` on the docs before and after the change. > > > GeneratedDocs % diff -r 8336259-stylesheet old-docs > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html old-docs/api/java.base/java/lang/doc-files/ValueBased.html > 13a14 >> > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html old-docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html > 13a14 >> > > > Here is the link for the generated docs after the change, no visual change is seen but the erronous link is gone. > Value based classes [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/ValueBased.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html) > > Java Thread Primitive Deprecation [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20145#pullrequestreview-2173846026 From aboldtch at openjdk.org Fri Jul 12 05:57:30 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 05:57:30 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Update arguments.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/a207544b..15997bc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From rgiulietti at openjdk.org Fri Jul 12 06:33:40 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 06:33:40 GMT Subject: RFR: 8334758: Incorrect note in Javadoc for a few RandomGenerator methods Message-ID: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> Small corrections to @implSpec notes in a few methods in RandomGenerator. ------------- Commit messages: - 8334758: Incorrect note in Javadoc for a few RandomGenerator methods Changes: https://git.openjdk.org/jdk/pull/20152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334758 Stats: 28 lines in 1 file changed: 0 ins; 5 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/20152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20152/head:pull/20152 PR: https://git.openjdk.org/jdk/pull/20152 From nbenalla at openjdk.org Fri Jul 12 06:36:50 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 12 Jul 2024 06:36:50 GMT Subject: RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote: > Can I please get a review for this small change, the relative link to the stylesheet isn't needed as it wasn't used anyway in the generated HTML. The correct link to the stylesheet is already in the generated HTML. > > This is the difference between the generated docs before and after this change, by running `diff -r` on the docs before and after the change. > > > GeneratedDocs % diff -r 8336259-stylesheet old-docs > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html old-docs/api/java.base/java/lang/doc-files/ValueBased.html > 13a14 >> > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html old-docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html > 13a14 >> > > > Here is the link for the generated docs after the change, no visual change is seen but the erronous link is gone. > Value based classes [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/ValueBased.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html) > > Java Thread Primitive Deprecation [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) Thank you both for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/20145#issuecomment-2224891104 From duke at openjdk.org Fri Jul 12 06:36:51 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Jul 2024 06:36:51 GMT Subject: RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote: > Can I please get a review for this small change, the relative link to the stylesheet isn't needed as it wasn't used anyway in the generated HTML. The correct link to the stylesheet is already in the generated HTML. > > This is the difference between the generated docs before and after this change, by running `diff -r` on the docs before and after the change. > > > GeneratedDocs % diff -r 8336259-stylesheet old-docs > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html old-docs/api/java.base/java/lang/doc-files/ValueBased.html > 13a14 >> > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html old-docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html > 13a14 >> > > > Here is the link for the generated docs after the change, no visual change is seen but the erronous link is gone. > Value based classes [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/ValueBased.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html) > > Java Thread Primitive Deprecation [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) @nizarbenalla Your change (at version 504f2b2dd0787d453618538b18b55c99f353d6db) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20145#issuecomment-2224893741 From jwaters at openjdk.org Fri Jul 12 06:40:20 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 12 Jul 2024 06:40:20 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK Message-ID: snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the null terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) ------------- Commit messages: - Obliterate most references to _snprintf in the Windows JDK Changes: https://git.openjdk.org/jdk/pull/20153/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336289 Stats: 35 lines in 12 files changed: 0 ins; 16 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From jpai at openjdk.org Fri Jul 12 07:08:51 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Jul 2024 07:08:51 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote: > Hi all, > Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. > I think it's necessory to receive jvm options from jtreg. > Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. I'll run this change against our CI instance just to be sure this doesn't cause unexpected issues. I'll approve the PR once those runs complete. Thank you for updating the JBS issue description. It now states: > we found that the test case would start a new java process during the test, but the started java child process did not receive the jvm options configured from the parent process, resulting in the failure of the fix verification to continue normally. Therefore, it is necessary to pass in the jvm options configured from the parent process when starting the child java process. What you propose in this PR looks fine to me and matches some other tests which do a similar thing. Maybe we should do the same thing in some other tests in this directory, to keep them consistent. For now though, I think what you have here is fine and I don't expect you to update these other places. test/jdk/tools/jlink/JLinkReproducibleTest.java line 41: > 39: public class JLinkReproducibleTest { > 40: > 41: static final String TOOL_VM_OPTIONS = System.getProperty("test.tool.vm.opts", ""); Nit - this can be made `private` ------------- PR Review: https://git.openjdk.org/jdk/pull/19669#pullrequestreview-2174025942 PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2224957014 PR Review Comment: https://git.openjdk.org/jdk/pull/19669#discussion_r1675413193 From syan at openjdk.org Fri Jul 12 07:28:53 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 07:28:53 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 07:05:34 GMT, Jaikiran Pai wrote: > I'll run this change against our CI instance just to be sure this doesn't cause unexpected issues. I'll approve the PR once those runs complete. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2224988113 From jpai at openjdk.org Fri Jul 12 07:37:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Jul 2024 07:37:53 GMT Subject: RFR: 8334394: Race condition in Class::protectionDomain [v2] In-Reply-To: References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> Message-ID: <3ctNdnFfn87ogHxU1hdpTe75iR-X9i2vco64do4OQhg=.461439a9-a510-4430-8a2e-b3aab5e0d871@github.com> On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote: >> Make sure `pd` is always the same object when `getProtectionDomain0` is null. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > explain why the test is related to the fix Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19752#pullrequestreview-2174075188 From syan at openjdk.org Fri Jul 12 07:39:11 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 07:39:11 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: > Hi all, > Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. > I think it's necessory to receive jvm options from jtreg. > Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: make variable TOOL_VM_OPTIONS to private ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19669/files - new: https://git.openjdk.org/jdk/pull/19669/files/60e746fd..89418239 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19669&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19669&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19669.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19669/head:pull/19669 PR: https://git.openjdk.org/jdk/pull/19669 From syan at openjdk.org Fri Jul 12 07:39:11 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 07:39:11 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 07:05:58 GMT, Jaikiran Pai wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> make variable TOOL_VM_OPTIONS to private > > test/jdk/tools/jlink/JLinkReproducibleTest.java line 41: > >> 39: public class JLinkReproducibleTest { >> 40: >> 41: static final String TOOL_VM_OPTIONS = System.getProperty("test.tool.vm.opts", ""); > > Nit - this can be made `private` Thanks for the review. The variable has made to private. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19669#discussion_r1675445554 From asotona at openjdk.org Fri Jul 12 08:25:51 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 12 Jul 2024 08:25:51 GMT Subject: RFR: 8335905: CompoundElement API cleanup [v2] In-Reply-To: <74UB8UTbTXEyYHqR1Cx6klodMQAj5xfqnVkzFjDZe_s=.1aabaeb6-f605-41ed-b181-31f9ed30dc34@github.com> References: <74UB8UTbTXEyYHqR1Cx6klodMQAj5xfqnVkzFjDZe_s=.1aabaeb6-f605-41ed-b181-31f9ed30dc34@github.com> Message-ID: On Tue, 9 Jul 2024 23:29:28 GMT, Chen Liang wrote: >> `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Two usages in tier3 Nice cleanup. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20103#pullrequestreview-2174161566 From duke at openjdk.org Fri Jul 12 08:45:31 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 08:45:31 GMT Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization Message-ID: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros. ------------- Commit messages: - Removed trailing whitespace - MutableBigInteger.leftShift(int) optimization Changes: https://git.openjdk.org/jdk/pull/20008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336274 Stats: 624 lines in 5 files changed: 587 ins; 10 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/20008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008 PR: https://git.openjdk.org/jdk/pull/20008 From liach at openjdk.org Fri Jul 12 08:45:31 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Jul 2024 08:45:31 GMT Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com> References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com> Message-ID: On Wed, 3 Jul 2024 14:17:37 GMT, fabioromano1 wrote: > This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros. Filed https://bugs.openjdk.org/browse/JDK-8336274 for you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2224093859 From jpai at openjdk.org Fri Jul 12 09:28:19 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Jul 2024 09:28:19 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Message-ID: Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. ------------- Commit messages: - 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Changes: https://git.openjdk.org/jdk/pull/20154/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334167 Stats: 152 lines in 3 files changed: 74 ins; 37 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/20154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20154/head:pull/20154 PR: https://git.openjdk.org/jdk/pull/20154 From rkennke at openjdk.org Fri Jul 12 09:55:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 09:55:52 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update arguments.cpp I've reviewed and tested some earlier versions of this change in the context of Lilliput, and haven't encountered any showstopping problems. Very nice work! When you say 'This patch has been evaluated to be performance neutral when UseObjectMonitorTable is turned off (the default).' - what does the performance look like with +UOMT? How does it compare to -UOMT? I've only reviewed the platform-specific changes so far. Mostly looks good, I only have some relatively minor remarks. Will review the shared code changes separately. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 318: > 316: > 317: // Loop after unrolling, advance iterator. > 318: increment(t3_t, in_bytes(OMCache::oop_to_oop_difference())); Maybe I am misreading this but... in the unroll loop you avoid emitting the increment on the last iteration, but then you emit it explicitely here? Wouldn't it be cleaner to do it in the unroll loop always and elide the explicit increment after loop? src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: > 341: const Register t3_owner = t3; > 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); > 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674: > 672: > 673: // Loop after unrolling, advance iterator. > 674: increment(t, in_bytes(OMCache::oop_to_oop_difference())); Same issue as in aarch64 code. ------------- Changes requested by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2174300266 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675587650 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675597362 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675605009 From rkennke at openjdk.org Fri Jul 12 10:14:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 10:14:52 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update arguments.cpp Is there a plan to get rid of the UseObjectMonitorTable flag in a future release? Ideally we would have one fast-locking implementation (LW locking) with one OM mapping (+UOMT), right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2225260710 From eosterlund at openjdk.org Fri Jul 12 10:18:51 2024 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 12 Jul 2024 10:18:51 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote: > [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` The reason we did not do this before is that this is not a strong reference store. Strong reference stores with a SATB collector will keep the referent alive, which is typically the exact opposite of what a user wants when they clear a Reference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2225266939 From shade at openjdk.org Fri Jul 12 10:24:57 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 12 Jul 2024 10:24:57 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 10:16:13 GMT, Erik ?sterlund wrote: > The reason we did not do this before is that this is not a strong reference store. Strong reference stores with a SATB collector will keep the referent alive, which is typically the exact opposite of what a user wants when they clear a Reference. You mean not doing this store just on the Java side? Yes, I agree, it would be awkward. In intrinsic, we are storing with the same decorators that `JVM_ReferenceClear` is using, which should be good with SATB collectors. Perhaps I am misunderstanding the comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2225277261 From aboldtch at openjdk.org Fri Jul 12 10:54:23 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 10:54:23 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v7] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Cleanup c2 cache lookup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/15997bc3..e1eb8c95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=05-06 Stats: 12 lines in 2 files changed: 0 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From aboldtch at openjdk.org Fri Jul 12 10:54:24 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 10:54:24 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:32:44 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 318: > >> 316: >> 317: // Loop after unrolling, advance iterator. >> 318: increment(t3_t, in_bytes(OMCache::oop_to_oop_difference())); > > Maybe I am misreading this but... in the unroll loop you avoid emitting the increment on the last iteration, but then you emit it explicitely here? Wouldn't it be cleaner to do it in the unroll loop always and elide the explicit increment after loop? You are correct. It is a leftover from when it was possible to tweak the number of unrolled lookups as well as whether it should loop the tail. Fixed. > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: > >> 341: const Register t3_owner = t3; >> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); >> 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; > > That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. I see. I tend to prefer uniform initialization as it makes narrowing conversions illegal. I remember `uniform initialization` coming up in some previous PR as well. It is really only neccesary for some types of templated code, but it does also makes easier to not make mistakes in the general case (as long as you avoid `std::initializer_list`, which I think we explicitly forbid in our coding guidelines). I do not recall what the conclusion of that discussion was. But maybe it was that this feature is to exotic and foreign for hotspot. I prefer it tough. Even if I fail to consistently use it. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674: > >> 672: >> 673: // Loop after unrolling, advance iterator. >> 674: increment(t, in_bytes(OMCache::oop_to_oop_difference())); > > Same issue as in aarch64 code. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675676768 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675676879 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675677068 From aboldtch at openjdk.org Fri Jul 12 11:08:53 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 11:08:53 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:53:11 GMT, Roman Kennke wrote: > When you say 'This patch has been evaluated to be performance neutral when UseObjectMonitorTable is turned off (the default).' - what does the performance look like with +UOMT? How does it compare to -UOMT? Most benchmarks are unaffected as they do not use any contended locking or wait/notify. Some see improvements and some show regressions. The most significant regressions are in `DaCapo-xalan` which is very sensitive to the timing of enter. It seems to rely quite heavily on how fast you can get to `ObjectMonitor::TrySpin` as well as the exact behaviour of this spinning. Then there are all the workloads which have not been tested in all these benchmark suites. The hope is to be able to incrementally iterate on the performance of the worst outliers. > Is there a plan to get rid of the UseObjectMonitorTable flag in a future release? Ideally we would have one fast-locking implementation (LW locking) with one OM mapping (+UOMT), right? My understanding (and shared hope) is that this is the ambition. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2225341285 From eosterlund at openjdk.org Fri Jul 12 12:00:56 2024 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 12 Jul 2024 12:00:56 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 10:22:42 GMT, Aleksey Shipilev wrote: > > The reason we did not do this before is that this is not a strong reference store. Strong reference stores with a SATB collector will keep the referent alive, which is typically the exact opposite of what a user wants when they clear a Reference. > > You mean not doing this store just on the Java side? Yes, I agree, it would be awkward. In intrinsic, we are storing with the same decorators that `JVM_ReferenceClear` is using, which should be good with SATB collectors. Perhaps I am misunderstanding the comment. The runtime use of the Access API knows how to resolve an unknown oop ref strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength. However, we do not have support for that in the C2 backend. In fact, it does not understand non-strong oop stores at all. Because there hasn't really been a use case for it, other than clearing a Reference. That's the precise reason why we do not have a clear intrinsic; it would have to add that infrastructure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2225430174 From aph at openjdk.org Fri Jul 12 12:08:55 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 12 Jul 2024 12:08:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:40:45 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: > >> 341: const Register t3_owner = t3; >> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); >> 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; > > That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. I agree with @rkennke . When we wrote the AArch64 MacroAssembler we were concentrating on readability and familiarity, and this separate declaration and use, with unusual syntax, IMO makes life harder for the reader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675751592 From aturbanov at openjdk.org Fri Jul 12 12:11:02 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 12 Jul 2024 12:11:02 GMT Subject: [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update In-Reply-To: References: Message-ID: <9miIlVD596DkRNWzvYSBcMX9cDV0JLRxn_QLRFsDDfo=.3f459a78-edf9-4126-9a35-85f8b9d3a1d2@github.com> On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote: >Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This message is kind of confusing. This PR is for `openjdk/jdk` repository too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20126#issuecomment-2225445985 From jkratochvil at openjdk.org Fri Jul 12 12:30:52 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 12 Jul 2024 12:30:52 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v4] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 16:46:13 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be verified. The added test, `SystemdMemoryAwarenessTest` currently passes on cgroups v1 and fails on cgroups v2 due to the way how [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) was implemented when JDK 13 was a thing. Therefore immediately problem-listed. It should get unlisted once [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420) merges. >> >> I'm adding those tests in order to not regress another time. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v2 and Linux x86_64 cgroups v1. >> - [x] New systemd test on cg v1 (passes). Fails on cg v2 (due to JDK-8322420) >> - [x] GHA > > Severin Gehwolf 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: > > - Add Whitebox check for host cpu > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Merge branch 'master' into jdk-8333446-systemd-slice-tests > - Fix comments > - 8333446: Add tests for hierarchical container support With #17198 and this updated patch I still get the a FAIL due to: [0.333s][trace][os,container] OSContainer::active_processor_count: 4 But let's resolve it after #17198 gets final/approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2225475953 From sgehwolf at openjdk.org Fri Jul 12 12:46:50 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 12 Jul 2024 12:46:50 GMT Subject: RFR: 8333446: Add tests for hierarchical container support [v4] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 12:28:16 GMT, Jan Kratochvil wrote: > With #17198 and this updated patch I still get the a FAIL due to: > > ``` > [0.333s][trace][os,container] OSContainer::active_processor_count: 4 > ``` > > But let's resolve it after #17198 gets final/approved. Because the #17198 is incomplete. As mentioned in the review: > We ought to also trim the path for the CPU controller. This patch only fixes the memory controller. That's exactly why the test is failing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2225501718 From coleenp at openjdk.org Fri Jul 12 12:50:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Jul 2024 12:50:52 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v7] In-Reply-To: References: Message-ID: <6Aa4oWKwpgo9Br75tCLj3AGQLxP9Rw2dgjzOXJQ6CTo=.e92e83f5-e4b3-43d8-8e89-3349de99524d@github.com> On Fri, 12 Jul 2024 10:54:23 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup c2 cache lookup Thank you for making the argument change. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2174647655 From aboldtch at openjdk.org Fri Jul 12 13:06:40 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 13:06:40 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 12:06:05 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: >> >>> 341: const Register t3_owner = t3; >>> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); >>> 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; >> >> That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. > > I agree with @rkennke . When we wrote the AArch64 MacroAssembler we were concentrating on readability and familiarity, and this separate declaration and use, with unusual syntax, IMO makes life harder for the reader. Fair enough. ? _To me uniform initialization is just safer less problematic way of expressing the same thing._ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675828324 From aboldtch at openjdk.org Fri Jul 12 13:06:40 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 13:06:40 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v8] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Avoid uniform initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/e1eb8c95..cccffeda Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=06-07 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From rgiulietti at openjdk.org Fri Jul 12 13:13:10 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 13:13:10 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: Message-ID: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> On Tue, 9 Jul 2024 20:06:40 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() @fabioromano1 This is a first reading, comparing with the well documented algorithm in the Bertot, Margaud, Zimmermann paper. src/java.base/share/classes/java/math/BigInteger.java line 2724: > 2722: if (this.signum < 0) { > 2723: throw new ArithmeticException("Negative BigInteger"); > 2724: } Please restore the original braces. src/java.base/share/classes/java/math/MutableBigInteger.java line 46: > 44: * @author Michael McCloskey > 45: * @author Timothy Buktu > 46: * @author Fabio Romano In recent years we no longer add the @author tag. In fact, at some point we plan to remove them from the codebase. Authorship is part of the git commits. src/java.base/share/classes/java/math/MutableBigInteger.java line 128: > 126: intLen = 2; > 127: value[0] = hi; > 128: value[1] = (int) val; Suggestion: value = new int[] {hi, (int) val} intLen = 2; src/java.base/share/classes/java/math/MutableBigInteger.java line 1916: > 1914: * @throws ArithmeticException if the value returned by {@code bitLength()} > 1915: * overflows the range of {@code int}. > 1916: * @return the integer square root of {@code this} and the remainder if needed To emphasize, make use of `` tags, not ``. By convention, a blank line precedes `@return`, which precedes `@throws` (see some public API examples). src/java.base/share/classes/java/math/MutableBigInteger.java line 1941: > 1939: > 1940: // Initial estimate is the square root of the unsigned long value. > 1941: long s = (long) Math.sqrt(x > 0 ? x : x + 0x1p64); As a matter of simplification, the above cases can be collapsed to just this one. I don't think there's a real need to optimize for 0, [1, 4), `int`. Also, there should be a proof that the code below is correct, as there are many roundings involved. Suggestion: long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); src/java.base/share/classes/java/math/MutableBigInteger.java line 1967: > 1965: MutableBigInteger[] sqrtRem = x.sqrtRemZimmermann(x.intLen, needRemainder); > 1966: > 1967: // Unnormalize This unnormalization code, as well as the one in the next method, requires a full explanation, perhaps in abstract, mathematical terms, to help understanding. src/java.base/share/classes/java/math/MutableBigInteger.java line 1997: > 1995: if (len == 2) { // Base case > 1996: long x = ((value[offset] & LONG_MASK) << 32) | (value[offset + 1] & LONG_MASK); > 1997: long s = (long) Math.sqrt(x > 0 ? x : x + 0x1p64); Again, this needs a proof that doing so is always correct. Suggestion: long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); src/java.base/share/classes/java/math/MutableBigInteger.java line 2020: > 2018: * The length is normalized to a mutiple of 4 because, in this way, > 2019: * the input can be always split in blocks of words without twiddling with bits. > 2020: */ What's substantially different here from the Bertot, Magaud, Zimmermann paper? This is not explained in detail, so it is way harder to understand than the paper. src/java.base/share/classes/java/math/MutableBigInteger.java line 2021: > 2019: * the input can be always split in blocks of words without twiddling with bits. > 2020: */ > 2021: final int limit = len; The name `limit` reminds more an offset than a length. src/java.base/share/classes/java/math/MutableBigInteger.java line 2023: > 2021: final int limit = len; > 2022: final int excessInts = (-len) & 3; > 2023: len += excessInts; // len must be a multiple of 4 A comment like "this computes `excessInts = 4 * ceil(len / 4) - len`" or similar is welcome. src/java.base/share/classes/java/math/MutableBigInteger.java line 2030: > 2028: MutableBigInteger dividend = sr[1]; > 2029: dividend.leftShift(blockBitLen); > 2030: dividend.add(getBlockZimmermann(1, len, limit, blockLen)); Maybe there's no need to use `add` here and just copying the block into the lower `blockLen` words is sufficient? src/java.base/share/classes/java/math/MutableBigInteger.java line 2040: > 2038: sqrt.add(q); > 2039: > 2040: MutableBigInteger chunk = u; I don't get the need for `chunk`. It should be possible to use `u` directly. Is it for readability? Then maybe use a more "mathematical" name. src/java.base/share/classes/java/math/MutableBigInteger.java line 2054: > 2052: > 2053: rem.add(ONE); > 2054: rem.subtract(twiceSqrt); Shouldn't these be `rem + twiceSqrt - 1`? src/java.base/share/classes/java/math/MutableBigInteger.java line 2063: > 2061: } > 2062: > 2063: // Unnormalize Again, this unnormalization code requires a full explanation. src/java.base/share/classes/java/math/MutableBigInteger.java line 2091: > 2089: } > 2090: > 2091: private MutableBigInteger getBlockZimmermann(int blockIndex, int len, int limit, int blockLen) { Please add a comment on what this method is supposed to do. ------------- PR Review: https://git.openjdk.org/jdk/pull/19710#pullrequestreview-2174704290 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675834855 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675836169 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675837722 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675842182 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675847407 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675848405 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675849681 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675851990 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675852854 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675853104 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675854097 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675854623 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675855041 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675856204 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675856482 From sgehwolf at openjdk.org Fri Jul 12 13:14:56 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 12 Jul 2024 13:14:56 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Thu, 11 Jul 2024 06:54:27 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Designed by Severin Gehwolf, implemented by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: > > - Fix the gtest > - fix compilation warning > - fix the gtest > - less refactorizations > - remove not a real backward compat. > - whitespace > - less refactorizations > - reduce refactorizations > - Fix caching > - Merge branch 'master' into master-cgroup > - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 Feel free to take this alternative fix as inspiration: https://github.com/openjdk/jdk/compare/master...jerboaa:jdk:jdk-8322420_cgroup_hierarchy_walk_init There ought to be a way to remove the duplication between cgv1 and cgv2's impl of `adjust_controller()` but I haven't spent time on that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2225563522 From liach at openjdk.org Fri Jul 12 13:18:52 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Jul 2024 13:18:52 GMT Subject: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v5] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 10:16:09 GMT, Jan Lahoda wrote: >> For general pattern matching switches, the `SwitchBootstraps` class currently generates a cascade of `if`-like statements, computing the correct target case index for the given input. >> >> There is one special case which permits a relatively easy faster handling, and that is when all the case labels case enum constants (but the switch is still a "pattern matching" switch, as tranditional enum switches do not go through `SwitchBootstraps`). Like: >> >> >> enum E {A, B, C} >> E e = ...; >> switch (e) { >> case null -> {} >> case A a -> {} >> case C c -> {} >> case B b -> {} >> } >> >> >> We can create an array mapping the runtime ordinal to the appropriate case number, which is somewhat similar to what javac is doing for ordinary switches over enums. >> >> The `SwitchBootstraps` class was trying to do so, when the restart index is zero, but failed to do so properly, so that code is not used (and does not actually work properly). >> >> This patch is trying to fix that - when all the case labels are enum constants, an array mapping the runtime enum ordinals to the case number will be created (lazily), for restart index == 0. And this map will then be used to quickly produce results for the given input. E.g. for the case above, the mapping will be `{0 -> 0, 1 -> 2, 2 -> 1}` (meaning `{A -> 0, B -> 2, C -> 1}`). >> >> When the restart index is != 0 (i.e. when there's a guard in the switch, and the guard returned `false`), the if cascade will be generated lazily and used, as in the general case. If it would turn out there are significant enum-only switches with guards/restart index != 0, we could improve there as well, by generating separate mappings for every (used) restart index. >> >> I believe the current tests cover the code functionally sufficiently - see `SwitchBootstrapsTest.testEnums`. It is only that the tests do not (and regression tests cannot easily, I think) differentiate whether the special-case or generic implementation is used. >> >> I've added a new microbenchmark attempting to demonstrate the difference. There are two benchmarks, both having only enum constants as case labels. One, `enumSwitchTraditional` is an "old" switch, desugared fully by javac, the other, `enumSwitchWithBootstrap` is an equivalent switch that uses the `SwitchBootstraps`. Before this patch, I was getting values like: >> >> Benchmark Mode Cnt Score Error Units >> SwitchEnum.enumSwitchTraditional avgt 15 11.719 ? 0.333 ns/op >> Swi... > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback - using instanceof rather than isAssignableFrom Looks great to me, thanks for the cleanup! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19906#pullrequestreview-2174769920 From shade at openjdk.org Fri Jul 12 13:21:50 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 12 Jul 2024 13:21:50 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 11:57:56 GMT, Erik ?sterlund wrote: > The runtime use of the Access API knows how to resolve an unknown oop ref strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength. However, we do not have support for that in the C2 backend. In fact, it does not understand non-strong oop stores at all. Aw, nice usability landmine. I thought C2 barrier set would assert on me if it cannot deliver. Apparently not, I see it just does pre-barriers when it is not sure what strongness the store is. Hrmpf. OK, let me see what can be done here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2225577027 From duke at openjdk.org Fri Jul 12 13:30:54 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 13:30:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: <_LN1rwXTTBrpJJfZu2U8WafTcJ815fEdi-L0QccKkys=.2ef0f91a-8615-4c2f-9083-8add3be90788@github.com> On Fri, 12 Jul 2024 13:04:42 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 128: > >> 126: intLen = 2; >> 127: value[0] = hi; >> 128: value[1] = (int) val; > > Suggestion: > > value = new int[] {hi, (int) val} > intLen = 2; In this case, should the same method be applied in the inizialization with an int? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675924466 From rgiulietti at openjdk.org Fri Jul 12 13:36:53 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 13:36:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LN1rwXTTBrpJJfZu2U8WafTcJ815fEdi-L0QccKkys=.2ef0f91a-8615-4c2f-9083-8add3be90788@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> <_LN1rwXTTBrpJJfZu2U8WafTcJ815fEdi-L0QccKkys=.2ef0f91a-8615-4c2f-9083-8add3be90788@github.com> Message-ID: <7dn-tDaJLEGZLMA7_smie8Q8pwCsN2YdK2e_HVlXzVQ=.4ee2b55b-0ef7-4389-bc7a-9cd0224b239f@github.com> On Fri, 12 Jul 2024 13:28:14 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 128: >> >>> 126: intLen = 2; >>> 127: value[0] = hi; >>> 128: value[1] = (int) val; >> >> Suggestion: >> >> value = new int[] {hi, (int) val} >> intLen = 2; > > In this case, should the same method be applied in the inizialization with an int? You mean, in `init()`? Then yes, please. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675937382 From duke at openjdk.org Fri Jul 12 13:45:54 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 13:45:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:06:35 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 1941: > >> 1939: >> 1940: // Initial estimate is the square root of the unsigned long value. >> 1941: long s = (long) Math.sqrt(x > 0 ? x : x + 0x1p64); > > As a matter of simplification, the above cases can be collapsed to just this one. I don't think there's a real need to optimize for 0, [1, 4), `int`. > > Also, there should be a proof that the code below is correct, as there are many roundings involved. > > Suggestion: > > long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); The proof has been made simply by exaustive experiment: for every long value `s` in [0, 2^32) such that `x == s * s`, it is true that `s == (long) Math.sqrt(x >= 0 ? x : x + 0x1p64)`. This can be verified directly by a Java program. It means that Math.sqrt() returns the correct value for every perfect square, and so the value returned by Math.sqrt() for whatever long value in the range [0, 2^64) is either correct, or rounded up by one if the value is too high and too close to a perfect square. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675951166 From rgiulietti at openjdk.org Fri Jul 12 13:53:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 13:53:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:43:29 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1941: >> >>> 1939: >>> 1940: // Initial estimate is the square root of the unsigned long value. >>> 1941: long s = (long) Math.sqrt(x > 0 ? x : x + 0x1p64); >> >> As a matter of simplification, the above cases can be collapsed to just this one. I don't think there's a real need to optimize for 0, [1, 4), `int`. >> >> Also, there should be a proof that the code below is correct, as there are many roundings involved. >> >> Suggestion: >> >> long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); > > The proof has been made simply by exaustive experiment: for every long value `s` in [0, 2^32) such that `x == s * s`, it is true that `s == (long) Math.sqrt(x >= 0 ? x : x + 0x1p64)`. This can be verified directly by a Java program. > It means that Math.sqrt() returns the correct value for every perfect square, and so the value returned by Math.sqrt() for whatever long value in the range [0, 2^64) is either correct, or rounded up by one if the value is too high and too close to a perfect square. (Yes, I proved it to myself in this way.) A similar explanation should be in a comment in the code, not here. The source of truth is the code, not the comments on GitHub ;-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675959960 From duke at openjdk.org Fri Jul 12 13:53:55 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 13:53:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:06:46 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 1967: > >> 1965: MutableBigInteger[] sqrtRem = x.sqrtRemZimmermann(x.intLen, needRemainder); >> 1966: >> 1967: // Unnormalize > > This unnormalization code, as well as the one in the next method, requires a full explanation, perhaps in abstract, mathematical terms, to help understanding. The full explanation for the unnormalization is in the second paper, "A proof of GMP square root", par. 3.2 at page 11. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675961884 From duke at openjdk.org Fri Jul 12 14:01:54 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:01:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:07:02 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 1997: > >> 1995: if (len == 2) { // Base case >> 1996: long x = ((value[offset] & LONG_MASK) << 32) | (value[offset + 1] & LONG_MASK); >> 1997: long s = (long) Math.sqrt(x > 0 ? x : x + 0x1p64); > > Again, this needs a proof that doing so is always correct. > > Suggestion: > > long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); Here there's no need to modify `x > 0` with `x >= 0`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675972896 From duke at openjdk.org Fri Jul 12 14:01:53 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:01:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:49:55 GMT, Raffaello Giulietti wrote: >> The proof has been made simply by exaustive experiment: for every long value `s` in [0, 2^32) such that `x == s * s`, it is true that `s == (long) Math.sqrt(x >= 0 ? x : x + 0x1p64)`. This can be verified directly by a Java program. >> It means that Math.sqrt() returns the correct value for every perfect square, and so the value returned by Math.sqrt() for whatever long value in the range [0, 2^64) is either correct, or rounded up by one if the value is too high and too close to a perfect square. > > (Yes, I proved it to myself in this way.) > > A similar explanation should be in a comment in the code, not here. The source of truth is the code, not the comments on GitHub ;-) I would keep zero as the only special case, so as not to have to modify `x > 0` with `x >= 0` in `Math.sqrt(x > 0 ? x : x + 0x1p64)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675970940 From duke at openjdk.org Fri Jul 12 14:06:53 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:06:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:07:39 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2020: > >> 2018: * The length is normalized to a mutiple of 4 because, in this way, >> 2019: * the input can be always split in blocks of words without twiddling with bits. >> 2020: */ > > What's substantially different here from the Bertot, Magaud, Zimmermann paper? > This is not explained in detail, so it is way harder to understand than the paper. In the paper, the number is normalized to an even number of words... but this is not done in the pseudocode, since the pseudocode assumes that the number is already normalized, so actually there's no substantial difference... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675978798 From duke at openjdk.org Fri Jul 12 14:09:53 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:09:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:07:51 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2021: > >> 2019: * the input can be always split in blocks of words without twiddling with bits. >> 2020: */ >> 2021: final int limit = len; > > The name `limit` reminds more an offset than a length. The solution can be either to change its name, or to use it as an offset, but this second involves to modify the logic of the code, with higher risk of introducing errors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675984041 From duke at openjdk.org Fri Jul 12 14:19:00 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:19:00 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:08:29 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2040: > >> 2038: sqrt.add(q); >> 2039: >> 2040: MutableBigInteger chunk = u; > > I don't get the need for `chunk`. It should be possible to use `u` directly. > Is it for readability? Then maybe use a more "mathematical" name. Ok, but what should the name be? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1675996081 From duke at openjdk.org Fri Jul 12 14:22:52 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Jul 2024 14:22:52 GMT Subject: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 22:02:12 GMT, Shaojin Wen wrote: >> The current HexFormat defines an Enum to represent LowerCase and UpperCase >> >> >> class HexFormat { >> private enum Case { >> LOWERCASE, >> UPPERCASE >> } >> } >> >> >> This will cause the JVM to load one more class when it starts, which can be seen as follows >> >> >> public class Startup { >> public static void main(String[] args) {} >> } >> >> >> >> java -verbose:class Startup >> >> >> >> [0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base >> >> >> There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright @wenshao Your change (at version 9b1bf851e614e2f5b1517e1b37b8b4d7203d77d3) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20060#issuecomment-2225687328 From duke at openjdk.org Fri Jul 12 14:25:53 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:25:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 14:16:38 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2040: >> >>> 2038: sqrt.add(q); >>> 2039: >>> 2040: MutableBigInteger chunk = u; >> >> I don't get the need for `chunk`. It should be possible to use `u` directly. >> Is it for readability? Then maybe use a more "mathematical" name. > > Ok, but what should the name be? Like `u_a0`? It is the most `mathematical` name that comes to my mind. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676001072 From duke at openjdk.org Fri Jul 12 14:25:54 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:25:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: <62d2L1CR5Wp4CHJYZ2CEO7iUWrfQm_ZnQDkYgUJy__E=.df7a5ca7-58b7-42f9-a431-b93f21ee2afb@github.com> On Fri, 12 Jul 2024 13:08:37 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2054: > >> 2052: >> 2053: rem.add(ONE); >> 2054: rem.subtract(twiceSqrt); > > Shouldn't these be `rem + twiceSqrt - 1`? No, because `rem` is unsigned, so to perform the correct computation you must first add the absolute value of the addends with the same sign, and the subtract the absolute value of those with opposite sign. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676004129 From duke at openjdk.org Fri Jul 12 14:28:53 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:28:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:08:59 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann() > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2063: > >> 2061: } >> 2062: >> 2063: // Unnormalize > > Again, this unnormalization code requires a full explanation. Same reference which I provided above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676010744 From duke at openjdk.org Fri Jul 12 14:38:55 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 12 Jul 2024 14:38:55 GMT Subject: Integrated: 8335802: Improve startup speed HexFormat uses boolean instead of enum In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 23:06:17 GMT, Shaojin Wen wrote: > The current HexFormat defines an Enum to represent LowerCase and UpperCase > > > class HexFormat { > private enum Case { > LOWERCASE, > UPPERCASE > } > } > > > This will cause the JVM to load one more class when it starts, which can be seen as follows > > > public class Startup { > public static void main(String[] args) {} > } > > > > java -verbose:class Startup > > > > [0.094s][info][class,load] java.util.HexFormat$Case source: /Users/.../jdk/modules/java.base > > > There are only two cases here, which can be represented by boolean, which is clearer and can improve the startup speed a little bit. This pull request has now been integrated. Changeset: 84c74ad0 Author: Shaojin Wen Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/84c74ad0a94f5c36529c63d846f15916259ee6a5 Stats: 26 lines in 1 file changed: 1 ins; 6 del; 19 mod 8335802: Improve startup speed HexFormat uses boolean instead of enum Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/20060 From jvernee at openjdk.org Fri Jul 12 14:43:25 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 12 Jul 2024 14:43:25 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena Message-ID: This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. In this PR: - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: Benchmark Threads Mode Cnt Score Error Units ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op ConcurrentClose.confinedAccess 32 avgt 10 25.517 ? 1.069 us/op ConcurrentClose.confinedAccess 1 avgt 10 12.398 ? 0.098 us/op (I manually added the `Threads` collumn btw) Testing: tier 1-4 ------------- Commit messages: - polish - slightly improve comment - tweak comment - improve benchmark parameters - cleanup - add benchmark - add note about lacking session oop at safepoint - Only deopt if necessary - refactor close handshake - Return before deoptimizing of target thread already has async exception Changes: https://git.openjdk.org/jdk/pull/20158/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335480 Stats: 428 lines in 6 files changed: 339 ins; 19 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/20158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20158/head:pull/20158 PR: https://git.openjdk.org/jdk/pull/20158 From rgiulietti at openjdk.org Fri Jul 12 14:44:53 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 14:44:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:57:55 GMT, fabioromano1 wrote: >> (Yes, I proved it to myself in this way.) >> >> A similar explanation should be in a comment in the code, not here. The source of truth is the code, not the comments on GitHub ;-) > > I would keep zero as the only special case, so as not to have to modify `x > 0` with `x >= 0` in `Math.sqrt(x > 0 ? x : x + 0x1p64)`. I can't see any real-world performance benefit in having a special case for `0` since, functionally, the code for the generic (unsigned) `long` works correctly. Except if there's evidence that a `0` argument is used in a vast majority of cases, which I doubt. The aim is to simplify as much as reasonably possible without incurring real performance issues. Changing `>` to `>=` makes the code correct even when nothing is assumed about the range of `x`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676035453 From rgiulietti at openjdk.org Fri Jul 12 14:44:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 14:44:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 13:51:24 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1967: >> >>> 1965: MutableBigInteger[] sqrtRem = x.sqrtRemZimmermann(x.intLen, needRemainder); >>> 1966: >>> 1967: // Unnormalize >> >> This unnormalization code, as well as the one in the next method, requires a full explanation, perhaps in abstract, mathematical terms, to help understanding. > > The full explanation for the unnormalization is in the second paper, "A proof of GMP square root", par. 3.2 at page 11. Well, I have to compare that section, which is clear to me, with the code again. >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1997: >> >>> 1995: if (len == 2) { // Base case >>> 1996: long x = ((value[offset] & LONG_MASK) << 32) | (value[offset + 1] & LONG_MASK); >>> 1997: long s = (long) Math.sqrt(x > 0 ? x : x + 0x1p64); >> >> Again, this needs a proof that doing so is always correct. >> >> Suggestion: >> >> long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); > > Here there's no need to modify `x > 0` with `x >= 0`. Sure, but again: changing `>` to `>=` makes the code correct even for `0`. >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2020: >> >>> 2018: * The length is normalized to a mutiple of 4 because, in this way, >>> 2019: * the input can be always split in blocks of words without twiddling with bits. >>> 2020: */ >> >> What's substantially different here from the Bertot, Magaud, Zimmermann paper? >> This is not explained in detail, so it is way harder to understand than the paper. > > In the paper, the input is normalized to an even number of words... but this is not done in the pseudocode, since the pseudocode assumes that the input is already normalized, so actually there's no substantial difference... Yes, normalization is done in ?3.2. Will have another look. >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2021: >> >>> 2019: * the input can be always split in blocks of words without twiddling with bits. >>> 2020: */ >>> 2021: final int limit = len; >> >> The name `limit` reminds more an offset than a length. > > The solution can be either to change its name, or to use it as an offset, but this second involves to modify the logic of the code, with higher risk of introducing errors. I suggest changing the name: `maxLen`, `hiLen`, something similar. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676036185 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676037890 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676039724 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676040186 From rgiulietti at openjdk.org Fri Jul 12 14:44:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 14:44:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: <10Kt7HC_0XVeAVaBxAP7lpQaTmx551M10bt-Lp21gm4=.e4bfacc6-7847-4995-bea2-1a967c94e6a1@github.com> On Fri, 12 Jul 2024 14:20:23 GMT, fabioromano1 wrote: >> Ok, but what should the name be? > > Like `u_a0`? It is the most "mathematical" name that comes to my mind. In the paper `u` is called R'', so I'd rename it as `rpp` (for R prime prime). Generally, the more the names in the code match the ones in the paper, the easier it becomes to read the code with the paper at hand. Then you can then use `u` rather than `chunk`, but with a comment like "this corresponds to R'' L + N_0 in the paper". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676042479 From duke at openjdk.org Fri Jul 12 14:57:55 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 14:57:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <10Kt7HC_0XVeAVaBxAP7lpQaTmx551M10bt-Lp21gm4=.e4bfacc6-7847-4995-bea2-1a967c94e6a1@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> <10Kt7HC_0XVeAVaBxAP7lpQaTmx551M10bt-Lp21gm4=.e4bfacc6-7847-4995-bea2-1a967c94e6a1@github.com> Message-ID: On Fri, 12 Jul 2024 14:42:33 GMT, Raffaello Giulietti wrote: >> Like `u_a0`? It is the most "mathematical" name that comes to my mind. > > In the paper `u` is called R'', so I'd rename it as `rpp` (for R prime prime). Generally, the more the names in the code match the ones in the paper, the easier it becomes to read the code with the paper at hand. > > Then you can then use `u` rather than `chunk`, but with a comment like "this corresponds to R'' L + N_0 in the paper". Actually, `u` is the name used by Zimmermann in the first paper. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676061878 From rgiulietti at openjdk.org Fri Jul 12 15:15:52 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 15:15:52 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> <10Kt7HC_0XVeAVaBxAP7lpQaTmx551M10bt-Lp21gm4=.e4bfacc6-7847-4995-bea2-1a967c94e6a1@github.com> Message-ID: On Fri, 12 Jul 2024 14:55:19 GMT, fabioromano1 wrote: >> In the paper `u` is called R'', so I'd rename it as `rpp` (for R prime prime). Generally, the more the names in the code match the ones in the paper, the easier it becomes to read the code with the paper at hand. >> >> Then you can then use `u` rather than `chunk`, but with a comment like "this corresponds to R'' L + N_0 in the paper". > > Actually, `u` is the name used by Zimmermann in the first paper. That paper, while very concise, is not very "operational". Anyway, adherence to the names of one of the paper (I prefer the 2nd, more detailed one) is very helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676085563 From rgiulietti at openjdk.org Fri Jul 12 15:15:53 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Jul 2024 15:15:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: <62d2L1CR5Wp4CHJYZ2CEO7iUWrfQm_ZnQDkYgUJy__E=.df7a5ca7-58b7-42f9-a431-b93f21ee2afb@github.com> References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> <62d2L1CR5Wp4CHJYZ2CEO7iUWrfQm_ZnQDkYgUJy__E=.df7a5ca7-58b7-42f9-a431-b93f21ee2afb@github.com> Message-ID: <-T59kjBt668vvpZoFD3XuYxzQiX4yQ6gnNBYiCop3zQ=.f5e65d1e-f5d8-4373-adc4-2b43762119ef@github.com> On Fri, 12 Jul 2024 14:22:33 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2054: >> >>> 2052: >>> 2053: rem.add(ONE); >>> 2054: rem.subtract(twiceSqrt); >> >> Shouldn't these be `rem + twiceSqrt - 1`? > > No, because `rem` is unsigned, so to perform the correct computation you must first add the absolute value of the addends with the same sign, and then subtract the absolute value of those with opposite sign. Ah right, this is the semantics of `MBI.subtract`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676082417 From duke at openjdk.org Fri Jul 12 16:07:01 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Jul 2024 16:07:01 GMT Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2] In-Reply-To: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> References: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> Message-ID: On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote: >> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. >> >> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). >> >> Before: >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.843 ? 0.149 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 2.363 ? 0.091 ns/op >> >> >> >> After: >> >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.121 ? 1.189 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 1.001 ? 0.001 ns/op > > Sean Gwizdak 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: > > - Remove trailing whitespace. > - Move hashCode benchmark into the newly created MethodBenchmark file > - Merge branch 'master' into method-hashcode-JDK-8332249 > - Remove changes to JavaDoc per guidance. > - Fix whitespace issues pointed by the bot > - Micro-optimize Method.hashCode @s-gwizdak Your change (at version 4364d99d4b1b3a57694f4a0ac6da54898ec6848b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2225890476 From rkennke at openjdk.org Fri Jul 12 16:18:02 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 16:18:02 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update arguments.cpp Here comes my first-pass review of the shared code. (Man, I hope we can get rid of UOMT soon, again...) src/hotspot/share/oops/instanceKlass.cpp line 1090: > 1088: > 1089: // Step 2 > 1090: // If we were to use wait() instead of waitUninterruptibly() then This is a nice correction (even though, the actual call below is wait_uninterruptibly() ;-) ), but seems totally unrelated. src/hotspot/share/oops/markWord.cpp line 27: > 25: #include "precompiled.hpp" > 26: #include "oops/markWord.hpp" > 27: #include "runtime/basicLock.inline.hpp" I don't think this include is needed (at least not by the changed code parts, I haven't checked existing code). src/hotspot/share/runtime/arguments.cpp line 1820: > 1818: warning("New lightweight locking not supported on this platform"); > 1819: } > 1820: if (UseObjectMonitorTable) { Uhm, wait a second. That list of platforms covers all existing platforms anyway, so the whole block could be removed? Or is there a deeper meaning here that I don't understand? src/hotspot/share/runtime/basicLock.cpp line 37: > 35: if (mon != nullptr) { > 36: mon->print_on(st); > 37: } I am not sure if we wanted to do this, but we know the owner, therefore we could also look-up the OM from the table, and print it. It wouldn't have all that much to do with the BasicLock, though. src/hotspot/share/runtime/basicLock.inline.hpp line 45: > 43: return reinterpret_cast(get_metadata()); > 44: #else > 45: // Other platforms does not make use of the cache yet, If it's not used, why does it matter to special case the code here? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 28: > 26: > 27: #include "classfile/vmSymbols.hpp" > 28: #include "javaThread.inline.hpp" This include is incorrect (and my IDE says it's not needed). src/hotspot/share/runtime/lightweightSynchronizer.cpp line 31: > 29: #include "jfrfiles/jfrEventClasses.hpp" > 30: #include "logging/log.hpp" > 31: #include "logging/logStream.hpp" Include of logStream.hpp not needed? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 58: > 56: > 57: // > 58: // Lightweight synchronization. This comment doesn't really say anything. Either remove it, or add a nice summary of how LW locking and OM table stuff works. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 80: > 78: > 79: ConcurrentTable* _table; > 80: volatile size_t _table_count; Looks like a misnomer to me. We only have one table, but we do have N entries/nodes. This is counted when new nodes are allocated or old nodes are freed. Consider renaming this to '_entry_count' or '_node_count'? I'm actually a bit surprised if ConcurrentHashTable doesn't already track this... src/hotspot/share/runtime/lightweightSynchronizer.cpp line 88: > 86: > 87: public: > 88: Lookup(oop obj) : _obj(obj) {} Make explicit? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 97: > 95: > 96: bool equals(ObjectMonitor** value) { > 97: // The entry is going to be removed soon. What does this comment mean? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 112: > 110: > 111: public: > 112: LookupMonitor(ObjectMonitor* monitor) : _monitor(monitor) {} Make explicit? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 159: > 157: static size_t min_log_size() { > 158: // ~= log(AvgMonitorsPerThreadEstimate default) > 159: return 10; Uh wait - are we assuming that threads hold 1024 monitors *on average* ? Isn't this a bit excessive? I would have thought maybe 8 monitors/thread. Yes there are workloads that are bonkers. Or maybe the comment/flag name does not say what I think it says. Or why not use AvgMonitorsPerThreadEstimate directly? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 349: > 347: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); > 348: > 349: if (try_read) { All the callers seem to pass try_read = true. Why do we have the branch at all? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401: > 399: > 400: if (inserted) { > 401: // Hopefully the performance counters are allocated on distinct It doesn't look like the counters are on distinct cache lines (see objectMonitor.hpp, lines 212ff). If this is a concern, file a bug to investigate it later? The comment here is a bit misplaced, IMO. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 473: > 471: int _length; > 472: > 473: void do_oop(oop* o) final { C++ always provides something to learn - C++ has got a final keyword! :-) Looks like a reasonable use of it here, though. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 477: > 475: if (obj->mark_acquire().has_monitor()) { > 476: if (_length > 0 && _contended_oops[_length-1] == obj) { > 477: // assert(VM_Version::supports_recursive_lightweight_locking(), "must be"); Uncomment or remove assert? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 554: > 552: bool _no_safepoint; > 553: union { > 554: struct {} _dummy; Uhh ... Why does this need to be wrapped in a union and struct? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 563: > 561: assert(locking_thread == current || locking_thread->is_obj_deopt_suspend(), "locking_thread may not run concurrently"); > 562: if (_no_safepoint) { > 563: ::new (&_nsv) NoSafepointVerifier(); I'm thinking that it might be easier and cleaner to just re-do what the NoSafepointVerifier does? It just calls thread->inc/dec _no_safepoint_count(). src/hotspot/share/runtime/lightweightSynchronizer.cpp line 748: > 746: } > 747: > 748: // Fast-locking does not use the 'lock' argument. I believe the comment is outdated. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 969: > 967: > 968: for (;;) { > 969: // Fetch the monitor from the table Wrong intendation. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1157: > 1155: // enter can block for safepoints; clear the unhandled object oop > 1156: PauseNoSafepointVerifier pnsv(&nsv); > 1157: object = nullptr; What is the point of that statement? object is not an out-arg (afaict), and not used subsequently. src/hotspot/share/runtime/lightweightSynchronizer.hpp line 68: > 66: static void exit(oop object, JavaThread* current); > 67: > 68: static ObjectMonitor* inflate_into_object_header(Thread* current, JavaThread* inflating_thread, oop object, const ObjectSynchronizer::InflateCause cause); My IDE flags this with a warning 'Parameter 'cause' is const-qualified in the function declaration; const-qualification of parameters only has an effect in function definitions' *shrugs* src/hotspot/share/runtime/lockStack.inline.hpp line 232: > 230: oop obj = monitor->object_peek(); > 231: assert(obj != nullptr, "must be alive"); > 232: assert(monitor == LightweightSynchronizer::get_monitor_from_table(JavaThread::current(), obj), "must be exist in table"); "must be exist in table" -> "must exist in table" src/hotspot/share/runtime/objectMonitor.cpp line 56: > 54: #include "runtime/safepointMechanism.inline.hpp" > 55: #include "runtime/sharedRuntime.hpp" > 56: #include "runtime/synchronizer.hpp" This include is not used. src/hotspot/share/runtime/objectMonitor.hpp line 193: > 191: ObjectWaiter* volatile _WaitSet; // LL of threads wait()ing on the monitor > 192: volatile int _waiters; // number of waiting threads > 193: private: You can now also remove the 'private:' here src/hotspot/share/runtime/synchronizer.cpp line 390: > 388: > 389: static bool useHeavyMonitors() { > 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) || defined(RISCV64) || defined(S390) Why are those if-defs here? Why is ARM excluded? ------------- Changes requested by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2174478048 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675695457 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675696406 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675704824 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675707735 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675711809 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675744474 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675745048 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676111067 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675773683 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675747483 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675765460 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675766088 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675781420 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675791687 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675799897 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675803217 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675805690 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675824394 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675832868 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675854207 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675876915 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675932005 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675936943 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676107048 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676112375 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676125325 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676140201 From rkennke at openjdk.org Fri Jul 12 16:18:03 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 16:18:03 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: On Tue, 9 Jul 2024 20:43:06 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >> This reverts commit 2814350370cf142e130fe1d38610c646039f976d. > > src/hotspot/share/opto/library_call.cpp line 4620: > >> 4618: Node *unlocked_val = _gvn.MakeConX(markWord::unlocked_value); >> 4619: Node *chk_unlocked = _gvn.transform(new CmpXNode(lmasked_header, unlocked_val)); >> 4620: Node *test_not_unlocked = _gvn.transform(new BoolNode(chk_unlocked, BoolTest::ne)); > > I don't really know what this does. Someone from the c2 compiler group should look at this. Yes, that looks correct. I'm familiar with this code because I messed with it in my attempts to implement compact identity hashcode in Lilliput2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675699672 From rkennke at openjdk.org Fri Jul 12 16:18:03 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 16:18:03 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 15:56:59 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/runtime/synchronizer.cpp line 390: > >> 388: >> 389: static bool useHeavyMonitors() { >> 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) || defined(RISCV64) || defined(S390) > > Why are those if-defs here? Why is ARM excluded? Oh I see, you only moved this up. Still a bit puzzling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676142470 From jlu at openjdk.org Fri Jul 12 16:28:53 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Jul 2024 16:28:53 GMT Subject: [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update In-Reply-To: <9miIlVD596DkRNWzvYSBcMX9cDV0JLRxn_QLRFsDDfo=.3f459a78-edf9-4126-9a35-85f8b9d3a1d2@github.com> References: <9miIlVD596DkRNWzvYSBcMX9cDV0JLRxn_QLRFsDDfo=.3f459a78-edf9-4126-9a35-85f8b9d3a1d2@github.com> Message-ID: On Fri, 12 Jul 2024 12:08:15 GMT, Andrey Turbanov wrote: >> Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch. >> >> This change incorporates the ISO 4217 Amendment 177 Update. > >>Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This message is kind of confusing. This PR is for `openjdk/jdk` repository too. @turbanoff true, I adjusted the message to indicate the original commit is from mainline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20126#issuecomment-2225923927 From coleenp at openjdk.org Fri Jul 12 17:44:53 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Jul 2024 17:44:53 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 15:58:56 GMT, Roman Kennke wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 390: >> >>> 388: >>> 389: static bool useHeavyMonitors() { >>> 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) || defined(RISCV64) || defined(S390) >> >> Why are those if-defs here? Why is ARM excluded? > > Oh I see, you only moved this up. Still a bit puzzling. This code was just moved. No idea why ARM is excluded. I filed this to deal with this. https://bugs.openjdk.org/browse/JDK-8336325 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676253183 From kbarrett at openjdk.org Fri Jul 12 19:20:51 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 Jul 2024 19:20:51 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) This should be using `os::snprintf` rather than `snprintf`. Rationale is in the comment here: https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126 And yes, I know there are lots of bare uses of snprintf (about 125?), including in shared code. That's why it isn't currently in the forbidden list. There's some cleanup to do there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2226218368 From jlu at openjdk.org Fri Jul 12 20:20:57 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Jul 2024 20:20:57 GMT Subject: [jdk23] Integrated: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 In-Reply-To: References: Message-ID: <8wZH9uSU9bbrYVQJXbVX7V0EM-7UoeVnA32qDXEnJys=.20589b51-9f2a-4686-9ae4-90211807ac25@github.com> On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch. > > This updates the IANA subtag registry to version 2024-06-14. This pull request has now been integrated. Changeset: 0a9e3bfc Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/0a9e3bfc904911bc9b83a75fd6023575995e8c2b Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 Reviewed-by: naoto, iris Backport-of: 861aefcafacdc21459ef966307f52568e327fd49 ------------- PR: https://git.openjdk.org/jdk/pull/20125 From duke at openjdk.org Fri Jul 12 20:41:27 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 12 Jul 2024 20:41:27 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v24] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: - Removed trailing whitespace - First revision changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/95be919e..53672737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=22-23 Stats: 90 lines in 2 files changed: 48 ins; 18 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From jvernee at openjdk.org Fri Jul 12 20:59:26 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 12 Jul 2024 20:59:26 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: Message-ID: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside compiled code. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.confinedAccess 32 avgt 10 25.517 ? 1.069 ... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: track has_scoped_access for compiled methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20158/files - new: https://git.openjdk.org/jdk/pull/20158/files/34ff5fd8..d1266b53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=00-01 Stats: 42 lines in 15 files changed: 38 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20158/head:pull/20158 PR: https://git.openjdk.org/jdk/pull/20158 From jvernee at openjdk.org Fri Jul 12 20:59:26 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 12 Jul 2024 20:59:26 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena In-Reply-To: References: Message-ID: <-ywJLT6LHavlxhuYXJQTh6xvvhz00oFECkpiCvz_Y4w=.a67a4c7d-b503-475f-aee0-0e042acbccc6@github.com> On Fri, 12 Jul 2024 13:57:23 GMT, Jorn Vernee wrote: > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside compiled code. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.confinedAccess 32 avgt 10 25.517 ? 1.069 ... > This could be narrowed down further by tracking for each compiled method if it has an (inlined) call to an `@Scoped` method, but I've left that out for now. I decided to add this to the PR for completeness, so that we don't go and deoptimize frames that are not using scoped accesses at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2226341535 From duke at openjdk.org Fri Jul 12 21:53:03 2024 From: duke at openjdk.org (Sean Gwizdak) Date: Fri, 12 Jul 2024 21:53:03 GMT Subject: Integrated: 8332249: Micro-optimize Method.hashCode In-Reply-To: References: Message-ID: On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak wrote: > Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. > > This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). > > Before: > > Benchmark Mode Cnt Score Error Units > # Intel Skylake > MethodHashCode.benchmarkHashCode avgt 5 1.843 ? 0.149 ns/op > # Arm Neoverse N1 > MethodHashCode.benchmarkHashCode avgt 5 2.363 ? 0.091 ns/op > > > > After: > > > Benchmark Mode Cnt Score Error Units > # Intel Skylake > MethodHashCode.benchmarkHashCode avgt 5 1.121 ? 1.189 ns/op > # Arm Neoverse N1 > MethodHashCode.benchmarkHashCode avgt 5 1.001 ? 0.001 ns/op This pull request has now been integrated. Changeset: 8ba9bc6f Author: Sean Gwizdak Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/8ba9bc6f1735be98dcc039244a28884b4d9620ae Stats: 20 lines in 2 files changed: 17 ins; 0 del; 3 mod 8332249: Micro-optimize Method.hashCode Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/19433 From liach at openjdk.org Fri Jul 12 21:53:03 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Jul 2024 21:53:03 GMT Subject: RFR: 8332249: Micro-optimize Method.hashCode [v2] In-Reply-To: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> References: <_cZQqk-UhO06IobPUiqc0kCoRfquUsz2SkrSuo2RDdM=.3da1e381-920c-4be1-9409-d0f6382c82de@github.com> Message-ID: On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote: >> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. >> >> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). >> >> Before: >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.843 ? 0.149 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 2.363 ? 0.091 ns/op >> >> >> >> After: >> >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.121 ? 1.189 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 1.001 ? 0.001 ns/op > > Sean Gwizdak 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: > > - Remove trailing whitespace. > - Move hashCode benchmark into the newly created MethodBenchmark file > - Merge branch 'master' into method-hashcode-JDK-8332249 > - Remove changes to JavaDoc per guidance. > - Fix whitespace issues pointed by the bot > - Micro-optimize Method.hashCode I don't think we need to worry about the object footprint size. There are a few opportunities available, such as sharing the generic factories from the root object, or removing the unused slot field. And the hashcode cache will be required once we take parameter into account. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2226398217 From liach at openjdk.org Fri Jul 12 21:53:55 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Jul 2024 21:53:55 GMT Subject: RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote: > Can I please get a review for this small change, the relative link to the stylesheet isn't needed as it wasn't used anyway in the generated HTML. The correct link to the stylesheet is already in the generated HTML. > > This is the difference between the generated docs before and after this change, by running `diff -r` on the docs before and after the change. > > > GeneratedDocs % diff -r 8336259-stylesheet old-docs > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html old-docs/api/java.base/java/lang/doc-files/ValueBased.html > 13a14 >> > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html old-docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html > 13a14 >> > > > Here is the link for the generated docs after the change, no visual change is seen but the erronous link is gone. > Value based classes [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/ValueBased.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html) > > Java Thread Primitive Deprecation [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) Thanks nizar! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20145#issuecomment-2226399579 From nbenalla at openjdk.org Fri Jul 12 21:53:55 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 12 Jul 2024 21:53:55 GMT Subject: Integrated: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote: > Can I please get a review for this small change, the relative link to the stylesheet isn't needed as it wasn't used anyway in the generated HTML. The correct link to the stylesheet is already in the generated HTML. > > This is the difference between the generated docs before and after this change, by running `diff -r` on the docs before and after the change. > > > GeneratedDocs % diff -r 8336259-stylesheet old-docs > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html old-docs/api/java.base/java/lang/doc-files/ValueBased.html > 13a14 >> > diff -r 8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html old-docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html > 13a14 >> > > > Here is the link for the generated docs after the change, no visual change is seen but the erronous link is gone. > Value based classes [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/ValueBased.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/ValueBased.html) > > Java Thread Primitive Deprecation [before](https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) - [after](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336259-stylesheet/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html) This pull request has now been integrated. Changeset: 5bc86f33 Author: Nizar Benalla Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/5bc86f332986e3fffc1363f569029bb73a706064 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod 8336259: Wrong link to stylesheet.css in JavaDoc API documentation Reviewed-by: jjg, liach ------------- PR: https://git.openjdk.org/jdk/pull/20145 From liach at openjdk.org Fri Jul 12 23:43:01 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Jul 2024 23:43:01 GMT Subject: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation Message-ID: Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and erroneous links in the doc files. ------------- Commit messages: - Backport 5bc86f332986e3fffc1363f569029bb73a706064 Changes: https://git.openjdk.org/jdk/pull/20166/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20166&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336259 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20166/head:pull/20166 PR: https://git.openjdk.org/jdk/pull/20166 From liach at openjdk.org Fri Jul 12 23:47:52 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Jul 2024 23:47:52 GMT Subject: RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero [v2] In-Reply-To: References: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> Message-ID: On Mon, 8 Jul 2024 14:14:02 GMT, Adam Sotona wrote: >> Class-File API constant pool implementation requires non-zero entry hash code. >> Unfortunately current implementation computes zero hash code for specific CP entries. >> >> This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation and assures all pool entries have non-zero hash. A regression test of the actual zero-hash `IntegerEntry` has been added. >> >> All pre-computed hash codes in `BoundAttribute::standardAttribute` are updated. >> >> The patch has no performance effect measurable by any of the actual Class-File API benchmarks. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed BootstrapMethodEntryImpl::computeHashCode @asotona This patch is ready for integration. You can still backport this critical fix before rdp1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20074#issuecomment-2226536671 From duke at openjdk.org Fri Jul 12 23:59:16 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 12 Jul 2024 23:59:16 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong Message-ID: Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. ------------- Commit messages: - optimize parseInt & parseLong Changes: https://git.openjdk.org/jdk/pull/20168/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317980 Stats: 126 lines in 6 files changed: 56 ins; 36 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/20168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168 PR: https://git.openjdk.org/jdk/pull/20168 From duke at openjdk.org Sat Jul 13 00:50:18 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 13 Jul 2024 00:50:18 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v2] In-Reply-To: References: Message-ID: > Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. > > The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Reduce changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20168/files - new: https://git.openjdk.org/jdk/pull/20168/files/d15e4ed6..e2cbf4a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=00-01 Stats: 69 lines in 3 files changed: 26 ins; 24 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/20168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168 PR: https://git.openjdk.org/jdk/pull/20168 From jpai at openjdk.org Sat Jul 13 01:54:55 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Jul 2024 01:54:55 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > make variable TOOL_VM_OPTIONS to private The changes look good to me and the testing shows no related failures. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19669#pullrequestreview-2176039655 From duke at openjdk.org Sat Jul 13 02:51:57 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 13 Jul 2024 02:51:57 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v2] In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote: >> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. >> >> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Reduce changes The performance numbers are as follows ## MacBook M1 Pro # baseline -Benchmark (size) Mode Cnt Score Error Units -Longs.parseLong 500 avgt 15 2.613 ? 0.020 us/op -Integers.parseInt 500 avgt 15 2.303 ? 0.006 us/op +Benchmark (size) Mode Cnt Score Error Units +Longs.parseLong 500 avgt 15 2.473 ? 0.020 us/op +5.66% +Integers.parseInt 500 avgt 15 2.219 ? 0.002 us/op +3.78% ## MacBook 2018 i9 -Benchmark (size) Mode Cnt Score Error Units -Integers.parseInt 500 avgt 15 3.114 ? 0.058 us/op -Longs.parseLong 500 avgt 15 3.569 ? 0.059 us/op +Benchmark (size) Mode Cnt Score Error Units +Integers.parseInt 500 avgt 15 3.038 ? 0.033 us/op +2.50% +Longs.parseLong 500 avgt 15 3.065 ? 0.032 us/op +16.44% ------------- PR Comment: https://git.openjdk.org/jdk/pull/20168#issuecomment-2226731713 From liach at openjdk.org Sat Jul 13 03:09:56 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 13 Jul 2024 03:09:56 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v2] In-Reply-To: References: Message-ID: <1iFWfuBYHJiCln8_ix1v__3mahl2hz115qXsoRmeL2A=.992206b7-833e-4898-86ac-58435c5c84b7@github.com> On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote: >> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. >> >> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Reduce changes A straightforward guess would be converting the `Character.digit()` call to a utility method like: private static int digit(char ch/*, int radix*/) { if (ch >= '0' && ch <= '9') // or replace it with something like Math.min('9', '0' + radix) return ch - '0'; // ascii base-10 fast path return digit(ch/*, radix*/); } Inspired by this: https://github.com/openjdk/jdk/blob/ae9f318fc35eeab497e546ebab9faed6ec774ec5/src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java#L236 However I don't know how JIT has compiled the code, so not sure how my speculative approach works compared to yours. But it is definitely somewhat less invasive, without the new table and latin1 requirements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20168#issuecomment-2226736083 From duke at openjdk.org Sat Jul 13 03:54:53 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 13 Jul 2024 03:54:53 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v2] In-Reply-To: References: Message-ID: <9Nmbr1TJ7N4HjG4T-j_oSR6rVKlVO9nC1LNepr6RVxk=.0ec79b18-cd9e-4f95-8e4a-6bd6829e73f1@github.com> On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote: >> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. >> >> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Reduce changes > A straightforward guess would be converting the `Character.digit()` call to a utility method like: > > ```java > private static int digit(char ch/*, int radix*/) { > if (ch >= '0' && ch <= '9') // or replace it with something like Math.min('9', '0' + radix) > return ch - '0'; // ascii base-10 fast path > return digit(ch/*, radix*/); > } > ``` > > Inspired by this: > > https://github.com/openjdk/jdk/blob/ae9f318fc35eeab497e546ebab9faed6ec774ec5/src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java#L236 > > However I don't know how JIT has compiled the code, so not sure how my speculative approach works compared to yours. But it is definitely somewhat less invasive, without the new table and latin1 requirements. In the parse scenario, I made many attempts and found no method faster than table lookup, because the input length will be greater than 1 and the table will be looked up multiple times. In this scenario, I think it is correct to use table lookup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20168#issuecomment-2226754795 From jwaters at openjdk.org Sat Jul 13 05:14:52 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 13 Jul 2024 05:14:52 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 19:18:09 GMT, Kim Barrett wrote: > This should be using `os::snprintf` rather than `snprintf`. Rationale is in the comment here: > > https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126 > > And yes, I know there are lots of bare uses of snprintf (about 125?), including in shared code. That's why it isn't currently in the forbidden list. There's some cleanup to do there. Ah, I'd assumed that the places where bare _snprintf was used had a reason for using it directly. I'll change all the usages in this Pull Request to use os::snprintf ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2226776993 From jwaters at openjdk.org Sat Jul 13 05:34:24 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 13 Jul 2024 05:34:24 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) Julian Waters has updated the pull request incrementally with one additional commit since the last revision: USe os::snprintf in HotSpot ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20153/files - new: https://git.openjdk.org/jdk/pull/20153/files/20a8e2a0..1bd6bc09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From jwaters at openjdk.org Sat Jul 13 05:36:50 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 13 Jul 2024 05:36:50 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) I would add a FORBID_C_FUNCTION for _snprintf for Windows, but unfortunately that would be completely useless since there's no way to restrict methods on Visual Studio ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2226782288 From syan at openjdk.org Sat Jul 13 08:42:53 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 13 Jul 2024 08:42:53 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > make variable TOOL_VM_OPTIONS to private Thanks for the review and the testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2226824048 From forax at openjdk.org Sat Jul 13 11:12:51 2024 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 13 Jul 2024 11:12:51 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside compiled code. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op >> ConcurrentClose.confine... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods Nice work ! Thinking a bit about how to improve the benchmark and given the semantics of Arena.close(), there is a trick that you can use. There are two kinds of memory segments, the one that only visible from Java and the one that are visible not only from Java. By example, a memory segment created from a mmap or a memory segment with an address sent to a C code are visible from outside Java, for those, you have no choice but wait in Arena.close() until all threads have answered to the handshakes. For all the other memory segments, because they are only visible from Java, their memory can be reclaimed asynchronously, i.e. the last thread of the handshakes can free the corresponding memory segments, so the thread that call Arena.close() is free to run even if the memory is not yet reclaimed. >From my armchair, that seems a awful lot of engeneering so it may not worth it, but now you know :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2226858328 From jvernee at openjdk.org Sat Jul 13 14:29:55 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 13 Jul 2024 14:29:55 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods That is something we considered in the past as well (I think Maurizio even had a prototype at some point). The issue is that close should be deterministic. i.e. after the call to `close()` returns, all memory should be freed. That is an essential property for applications that have most of their virtual address space tied up, and then want to release and immediately re-use a big chunk of it. If it's not important that memory is freed deterministically, but memory should still be accessible from multiple threads, an automatic arena might be a better choice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2226929736 From eosterlund at openjdk.org Sat Jul 13 15:15:51 2024 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Sat, 13 Jul 2024 15:15:51 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20158#pullrequestreview-2176318150 From eosterlund at openjdk.org Sat Jul 13 15:31:55 2024 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Sat, 13 Jul 2024 15:31:55 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods @dougxc might want to have a look at Graal support for this one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2226957995 From jvernee at openjdk.org Sat Jul 13 16:08:50 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 13 Jul 2024 16:08:50 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Sat, 13 Jul 2024 15:28:57 GMT, Erik ?sterlund wrote: > @dougxc might want to have a look at Graal support for this one. Yes, I conservatively implemented `has_scoped_access()` for Graal (see `jvmciRuntime.cpp` changes). It won't regress anything, but there's still an opportunity for improvement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2226974681 From forax at openjdk.org Sat Jul 13 16:45:50 2024 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 13 Jul 2024 16:45:50 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: <0zSpYFkv6lAR8G0FpPDyFP-uLqh92ZQ5uW5xVCRXmyg=.c14d0ee0-e0bf-4367-9dfa-c613489684c9@github.com> On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods Knowing that all the segments are freed during close() is something you may want. But having the execution time of close() be linear with the number of threads is also problematic. Maybe, it means that we need another kind of Arena that works like shared() but allow the freed to be done asynchronously (ofSharedAsyncFree ?). Note that the semantics of ofSharedAsyncFree() is different from ofAuto(), ofAuto() relies on the GC to free a segment so the delay before a segment is freed is not time bounded if the application has enough memory, the memory of the segment may never be reclaimed. With ofSharedAsyncFree(), the segments are freed by the last thread, so while this mechanism is not deterministic, it is time bounded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2226992713 From duke at openjdk.org Sat Jul 13 19:15:53 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 13 Jul 2024 19:15:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23] In-Reply-To: References: <_LdhreSe7ZazQZqsGGPHFCGVbkN41r2T0ODKktindKI=.0e527d96-5489-4573-b1af-2665ebd3bcd5@github.com> Message-ID: On Fri, 12 Jul 2024 14:39:51 GMT, Raffaello Giulietti wrote: >> The full explanation for the unnormalization is in the second paper, "A proof of GMP square root", par. 3.2 at page 11. > > Well, I have to compare that section, which is clear to me, with the code again. @rgiulietti I noticed that, after this unnormalization, while the square root can't have leading zeros by construction, the remainder could have them. Although there's not a general contract of the class MutableBigInteger that imposes the results must be always normalized (in the sense of `MBI.isNormalized()`), this might be an issue if `MBI.sqrtRem()` were used to do intermediate computations with MutableBigIntegers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1676884262 From darcy at openjdk.org Sat Jul 13 22:44:31 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 13 Jul 2024 22:44:31 GMT Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v5] In-Reply-To: References: Message-ID: > Misc small doc updates and addition of `@Overrides` annotations. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Sample precision-based conversion. - Merge branch 'master' into JDK-8333768 - Include "-" to HTML minus update. - Merge branch 'master' into JDK-8333768 - Respond to review feedback. - Merge branch 'master' into JDK-8333768 - Merge branch 'master' into JDK-8333768 - JDK-8333768: Minor doc updates to java.lang.{Float, Double} ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19590/files - new: https://git.openjdk.org/jdk/pull/19590/files/4277c32b..9b83dbc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19590&range=03-04 Stats: 45967 lines in 1153 files changed: 30174 ins; 10270 del; 5523 mod Patch: https://git.openjdk.org/jdk/pull/19590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19590/head:pull/19590 PR: https://git.openjdk.org/jdk/pull/19590 From darcy at openjdk.org Sat Jul 13 22:44:31 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 13 Jul 2024 22:44:31 GMT Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 01:43:27 GMT, Joe Darcy wrote: >> Misc small doc updates and addition of `@Overrides` annotations. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Added some typographical updates to Math/StrictMath to replace hyphens with HTML minus characters, which read better in that context. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19590#issuecomment-2227122249 From darcy at openjdk.org Sat Jul 13 22:44:31 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 13 Jul 2024 22:44:31 GMT Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v5] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 14:22:38 GMT, Raffaello Giulietti wrote: > Take the `double` closest to the exact decimal 0.1. > > My understanding is that IEEE with a precision of 17 would convert it to the decimal 0.10000000000000001. > > However, `Formatter` with a specifier `"%.17f"` will render this as 0.10000000000000000. That's because `Formatter`'s spec is based on this method (which produces 0.1), so cannot generate the trailing 1. > > Similarly, the `double` closest to 1.2 is converted to 1.19999999999999996 by IEEE and to 1.20000000000000000 by `Formatter`, because this method produces 1.2. > > In other words, neither this method nor the functionality offered by `Formatter` and friends correspond to IEEE, at least not in full. Updated to use a conversion through BigDecimal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19590#discussion_r1676965169 From uschindler at openjdk.org Sun Jul 14 11:04:54 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Sun, 14 Jul 2024 11:04:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods Hi Jorn, Many thanks for working on this! I have one problem with the benchmark: I think it is not measuring the whole setup in a way that is our workload: The basic problem is that we don't want to deoptimize threads which are not related to MemorySegments. So basically, the throughput of those threads should not be affected. For threads currently in a memory-segment read it should have a bit of effect, but it should recover fast. The given benchmark somehow only measures the following: It starts many threads; in each it opens a shared memory segment, does some work and closes it. So it measures the throughput of the whole "create shared/work on it/close shared" workload. Actually the problems we see in Lucene are more that we have many threads working on shared memory segments or on other tasks not related to memory segments at all, while a few threads are concurrently closing and opening new arenas. With more threads concurrently closing the arenas, also the throughput on other threads degrades. So IMHO, the benchamrk should be improved to have a few threads (configurable) that open/close memory segments and a list of other threads that do other work and finally a list of threads reading from the memory segments opened by first thread. The testcase you wrote is more fitting the above workload. Maybe the benchmark should be setup more like the test. If you have a benchmark with that workload it should better show an improvement. The current benchmark has the problem that it measures the whole open/work/close on shared sgements. And slosing a shared segment is always heavy, because it has to trigger and wait for the thread-local handshake. Why is the test preventing inlining of the inner read method? I may be able to benchmark a Lucene workload with a custom JDK build next week. It might be an idea to use the wrong DaCapoBenchmark (downgrade to older version before it has fixed https://github.com/dacapobench/dacapobench/issues/264 , specifically https://github.com/dacapobench/dacapobench/commit/76588b28d516ae19f51a80e7287d404385a2c146). Uwe ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2227303884 From uschindler at openjdk.org Sun Jul 14 11:10:00 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Sun, 14 Jul 2024 11:10:00 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0zSpYFkv6lAR8G0FpPDyFP-uLqh92ZQ5uW5xVCRXmyg=.c14d0ee0-e0bf-4367-9dfa-c613489684c9@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> <0zSpYFkv6lAR8G0FpPDyFP-uLqh92ZQ5uW5xVCRXmyg=.c14d0ee0-e0bf-4367-9dfa-c613489684c9@github.com> Message-ID: On Sat, 13 Jul 2024 16:43:16 GMT, R?mi Forax wrote: > Knowing that all the segments are freed during close() is something you may want. But having the execution time of close() be linear with the number of threads is also problematic. Maybe, it means that we need another kind of Arena that works like shared() but allow the freed to be done asynchronously (ofSharedAsyncFree ?). > > Note that the semantics of ofSharedAsyncFree() is different from ofAuto(), ofAuto() relies on the GC to free a segment so the delay before a segment is freed is not time bounded if the application has enough memory, the memory of the segment may never be reclaimed. With ofSharedAsyncFree(), the segments are freed by the last thread, so while this mechanism is not deterministic, it is time bounded. That's a great suggestion! In our case we just want the index files open as soon as possible, but not on next GC (which will be horrible and brings us back into the times of DirectByteBuffer). The problem with GC is that the Arena/MemorySegments and so on are tiny objects which will live for very long time, especially when they were used for quite some time (like an index segment of an Lucene index). Of course for testing purposes in Lucene we could use `ofShared()` (to make sure all mmapped files are freeed, especially on Windows as soon as index is close), but in production environments we could offer the option to use delayed close to improve throughput. Uwe ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2227305407 From jpai at openjdk.org Sun Jul 14 13:27:05 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 14 Jul 2024 13:27:05 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. Hello Olivier, this has been backported to 11, 17 and 21 update releases but not to JDK 8. I don't closely follow the update releases, so I don't know if there's a reason for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16502#issuecomment-2227348410 From liach at openjdk.org Sun Jul 14 13:49:09 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 14 Jul 2024 13:49:09 GMT Subject: RFR: 8335642: Hide Transform implementation for Class-File API [v3] In-Reply-To: References: Message-ID: > Removes ClassFile API transformation implementation details accidentally leaked to public API. Users don't have access to classes necessary to correctly implement these transform resolutions. In addition, removed improper `canWriteDirect` and made `ClassFileBuilder::transform` chain returns. > > Replaces #19928. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/hide-transform - return tag required - 8335642: Hide Transform implementation for Class-File API ------------- Changes: https://git.openjdk.org/jdk/pull/20102/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20102&range=02 Stats: 169 lines in 10 files changed: 28 ins; 100 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/20102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20102/head:pull/20102 PR: https://git.openjdk.org/jdk/pull/20102 From duke at openjdk.org Sun Jul 14 13:55:07 2024 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Jul 2024 13:55:07 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v25] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Simplified the computation of the space to hold the square root ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/53672737..7133c0af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=23-24 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Sun Jul 14 14:19:27 2024 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Jul 2024 14:19:27 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v26] In-Reply-To: References: Message-ID: <5wVN1SJWueDYEVpu7I0VbizjYrvGg8-9t8hItGRUYNk=.f0f3382b-5959-4498-85ae-6a21c20c05ec@github.com> > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: An optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/7133c0af..f333ac46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=24-25 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Sun Jul 14 14:34:08 2024 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Jul 2024 14:34:08 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v27] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Correct typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/f333ac46..9248fbd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=25-26 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From jpai at openjdk.org Sun Jul 14 14:40:51 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 14 Jul 2024 14:40:51 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote: > We cannot pass GNU style options like `--enable-preview` to `jlink --add-option`. It is hard to use for complex application. > > We have workaround for this issue (see JBS), but I think it is better to fix on JDK side. Hello @YaSuenag, I haven't had a chance to build your change locally and try it myself, but I suspect this change isn't enough to address the issue. Does this change allow for: jlink ... --add-options --add-exports java.base/jdk.internal.misc=ALL-UNNAMED to work correctly and have the `--add-exports java.base/jdk.internal.misc=ALL-UNNAMED` be considered as the option value for `--add-options`. Additionally, do the current tests pass with your proposed change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19987#issuecomment-2227372098 From liach at openjdk.org Sun Jul 14 15:00:55 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 14 Jul 2024 15:00:55 GMT Subject: RFR: 8335642: Hide Transform implementation for Class-File API [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 07:30:36 GMT, Adam Sotona wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> return tag required > > Looks good to me. > Nice cleanup job! @asotona I have fixed the merge conflict (imports) and rerun the tests. Can you review again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20102#issuecomment-2227377874 From liach at openjdk.org Sun Jul 14 15:04:54 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 14 Jul 2024 15:04:54 GMT Subject: RFR: 8335905: CompoundElement API cleanup [v2] In-Reply-To: <74UB8UTbTXEyYHqR1Cx6klodMQAj5xfqnVkzFjDZe_s=.1aabaeb6-f605-41ed-b181-31f9ed30dc34@github.com> References: <74UB8UTbTXEyYHqR1Cx6klodMQAj5xfqnVkzFjDZe_s=.1aabaeb6-f605-41ed-b181-31f9ed30dc34@github.com> Message-ID: On Tue, 9 Jul 2024 23:29:28 GMT, Chen Liang wrote: >> `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Two usages in tier3 Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20103#issuecomment-2227378896 From liach at openjdk.org Sun Jul 14 15:04:55 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 14 Jul 2024 15:04:55 GMT Subject: Integrated: 8335905: CompoundElement API cleanup In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 21:42:46 GMT, Chen Liang wrote: > `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. This pull request has now been integrated. Changeset: a9f5e76a Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/a9f5e76a65f743be9cd995fbea9c78ff9cef3402 Stats: 84 lines in 34 files changed: 2 ins; 11 del; 71 mod 8335905: CompoundElement API cleanup Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20103 From liach at openjdk.org Sun Jul 14 22:36:17 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 14 Jul 2024 22:36:17 GMT Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant Message-ID: Remove `AnnotationConstantValueEntry` and `AnnotationValue.OfConstant`. This is a relic of the old model from https://github.com/openjdk/jdk-sandbox/commit/bb7e29474ecfcfbd1eb01d237593eb80d062944f. In addition, this is bug-prone: the byte, short, char, and boolean constants use the int entry, and getting the `ConstantDesc` for them will return an `Integer`, which cannot be inversed back into the respective annotation values via `AnnotationValue.of(Object)` factory. ------------- Commit messages: - Redundant since tags - Remove AnnotationValue.OfConstant - Merge branch 'master' of https://github.com/openjdk/jdk into fix/acve - Merge branch 'm3' into fix/acve - Remove AnnotationConstantValueEntry Changes: https://git.openjdk.org/jdk/pull/20176/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20176&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335927 Stats: 391 lines in 19 files changed: 129 ins; 105 del; 157 mod Patch: https://git.openjdk.org/jdk/pull/20176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20176/head:pull/20176 PR: https://git.openjdk.org/jdk/pull/20176 From liach at openjdk.org Mon Jul 15 00:39:00 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 00:39:00 GMT Subject: RFR: 8335938: Review XxxBuilder.original and XxxModel.parent Message-ID: Remove unused `Class/Field/Method/CodeBuilder.original()`, and make `Field/Method/CodeModel.parent()` return present only if it's bound (i.e. not buffered transformed). See the CSR for details. ------------- Commit messages: - 8335938: Review XxxBuilder.original and XxxModel.parent Changes: https://git.openjdk.org/jdk/pull/20177/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335938 Stats: 92 lines in 12 files changed: 0 ins; 80 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20177/head:pull/20177 PR: https://git.openjdk.org/jdk/pull/20177 From aboldtch at openjdk.org Mon Jul 15 00:50:30 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Jul 2024 00:50:30 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: - Remove try_read - Add explicit to single parameter constructors - Remove superfluous access specifier - Remove unused include - Update assert message OMCache::set_monitor - Fix indentation - Remove outdated comment LightweightSynchronizer::exit - Remove logStream include - Remove strange comment - Fix javaThread include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/cccffeda..ebf11542 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=07-08 Stats: 25 lines in 5 files changed: 0 ins; 8 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From aboldtch at openjdk.org Mon Jul 15 00:50:33 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Jul 2024 00:50:33 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 11:09:35 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/oops/instanceKlass.cpp line 1090: > >> 1088: >> 1089: // Step 2 >> 1090: // If we were to use wait() instead of waitUninterruptibly() then > > This is a nice correction (even though, the actual call below is wait_uninterruptibly() ;-) ), but seems totally unrelated. I was thinking it was referring to `ObjectSynchronizer::waitUninterruptibly` added the same commit as the comment b3bf31a0a08da679ec2fd21613243fb17b1135a9 > src/hotspot/share/oops/markWord.cpp line 27: > >> 25: #include "precompiled.hpp" >> 26: #include "oops/markWord.hpp" >> 27: #include "runtime/basicLock.inline.hpp" > > I don't think this include is needed (at least not by the changed code parts, I haven't checked existing code). It is probably included through some other transitive include. However all the metadata functions are now inlined. These are used here. `inline markWord BasicLock::displaced_header() const` and `inline void BasicLock::set_displaced_header(markWord header)` > src/hotspot/share/runtime/arguments.cpp line 1820: > >> 1818: warning("New lightweight locking not supported on this platform"); >> 1819: } >> 1820: if (UseObjectMonitorTable) { > > Uhm, wait a second. That list of platforms covers all existing platforms anyway, so the whole block could be removed? Or is there a deeper meaning here that I don't understand? Zero. Used as as start point for porting to new platforms. > src/hotspot/share/runtime/basicLock.cpp line 37: > >> 35: if (mon != nullptr) { >> 36: mon->print_on(st); >> 37: } > > I am not sure if we wanted to do this, but we know the owner, therefore we could also look-up the OM from the table, and print it. It wouldn't have all that much to do with the BasicLock, though. Yeah maybe it is unwanted. Not sure how we should treat these prints of the frames. My thinking was that there is something in the cache, print it. But maybe just treating it as some internal data, maybe print "monitor { }" or similar is better. > src/hotspot/share/runtime/basicLock.inline.hpp line 45: > >> 43: return reinterpret_cast(get_metadata()); >> 44: #else >> 45: // Other platforms does not make use of the cache yet, > > If it's not used, why does it matter to special case the code here? Because it is not used it there may be uninitialised values there. See https://github.com/openjdk/jdk/pull/20067#discussion_r1671959763 > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 28: > >> 26: >> 27: #include "classfile/vmSymbols.hpp" >> 28: #include "javaThread.inline.hpp" > > This include is incorrect (and my IDE says it's not needed). Correct, is should be `runtime/javaThread.inline.hpp`. Fixed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 31: > >> 29: #include "jfrfiles/jfrEventClasses.hpp" >> 30: #include "logging/log.hpp" >> 31: #include "logging/logStream.hpp" > > Include of logStream.hpp not needed? Yeah we removed all log streams. Removed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 80: > >> 78: >> 79: ConcurrentTable* _table; >> 80: volatile size_t _table_count; > > Looks like a misnomer to me. We only have one table, but we do have N entries/nodes. This is counted when new nodes are allocated or old nodes are freed. Consider renaming this to '_entry_count' or '_node_count'? I'm actually a bit surprised if ConcurrentHashTable doesn't already track this... I think I was thinking of the names as a prefix to refer to the `Count of the table` and `Size of the table`. And not the `Number of tables`. But I can see the confusion. `ConcurrentHashTable` tracks no statistics except for JFR which added some counters directly into the implementation. All statistics are for the users to manage, even if there are helpers for gather these statistics. The current implementation is based on what we do for the StringTable and SymbolTable > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 88: > >> 86: >> 87: public: >> 88: Lookup(oop obj) : _obj(obj) {} > > Make explicit? Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 97: > >> 95: >> 96: bool equals(ObjectMonitor** value) { >> 97: // The entry is going to be removed soon. > > What does this comment mean? Not sure where it came from. Removed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 112: > >> 110: >> 111: public: >> 112: LookupMonitor(ObjectMonitor* monitor) : _monitor(monitor) {} > > Make explicit? Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 159: > >> 157: static size_t min_log_size() { >> 158: // ~= log(AvgMonitorsPerThreadEstimate default) >> 159: return 10; > > Uh wait - are we assuming that threads hold 1024 monitors *on average* ? Isn't this a bit excessive? I would have thought maybe 8 monitors/thread. Yes there are workloads that are bonkers. Or maybe the comment/flag name does not say what I think it says. > > Or why not use AvgMonitorsPerThreadEstimate directly? Maybe that is resonable. I believe I had that at some point but it had to deal with how to handle extreme values of `AvgMonitorsPerThreadEstimate` as well as what to do when `AvgMonitorsPerThreadEstimate` was disabled `=0`. One 4 / 8 KB allocation seems harmless. But this was very arbitrary. This will probably be changed when/if the resizing of the table becomes more synchronised with deflation, allowing for shrinking the table. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 349: > >> 347: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); >> 348: >> 349: if (try_read) { > > All the callers seem to pass try_read = true. Why do we have the branch at all? I'll clean this up. From experiments if was never better to use `insert_get` over a `get; insert_get`, even if we tried to be cleaver on when we skipped the initial get. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401: > >> 399: >> 400: if (inserted) { >> 401: // Hopefully the performance counters are allocated on distinct > > It doesn't look like the counters are on distinct cache lines (see objectMonitor.hpp, lines 212ff). If this is a concern, file a bug to investigate it later? The comment here is a bit misplaced, IMO. It originates from https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.cpp#L1543 I think we just kept it and did not think more about it. Not sure what it is referring to. Maybe @dcubed-ojdk knows more, they originated from him (9 years old comment). > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 477: > >> 475: if (obj->mark_acquire().has_monitor()) { >> 476: if (_length > 0 && _contended_oops[_length-1] == obj) { >> 477: // assert(VM_Version::supports_recursive_lightweight_locking(), "must be"); > > Uncomment or remove assert? Yeah not sure why it was ever uncommented. To me it seems like that the assert should be invariant. But will investigate. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 554: > >> 552: bool _no_safepoint; >> 553: union { >> 554: struct {} _dummy; > > Uhh ... Why does this need to be wrapped in a union and struct? A poor man's optional. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 563: > >> 561: assert(locking_thread == current || locking_thread->is_obj_deopt_suspend(), "locking_thread may not run concurrently"); >> 562: if (_no_safepoint) { >> 563: ::new (&_nsv) NoSafepointVerifier(); > > I'm thinking that it might be easier and cleaner to just re-do what the NoSafepointVerifier does? It just calls thread->inc/dec > _no_safepoint_count(). I wanted to avoid having to add `NoSafepointVerifier` implementation details in the synchroniser code. I guess `ContinuationWrapper` already does this. Simply creating a `NoSafepointVerifier` when you expect no safepoint is more obvious to me, shows the intent better. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 748: > >> 746: } >> 747: >> 748: // Fast-locking does not use the 'lock' argument. > > I believe the comment is outdated. Removed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 969: > >> 967: >> 968: for (;;) { >> 969: // Fetch the monitor from the table > > Wrong intendation. Fixed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1157: > >> 1155: // enter can block for safepoints; clear the unhandled object oop >> 1156: PauseNoSafepointVerifier pnsv(&nsv); >> 1157: object = nullptr; > > What is the point of that statement? object is not an out-arg (afaict), and not used subsequently. `CHECK_UNHANDLED_OOPS` + `-XX:+CheckUnhandledOops` https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/oops/oopsHierarchy.hpp#L53-L55 > src/hotspot/share/runtime/lightweightSynchronizer.hpp line 68: > >> 66: static void exit(oop object, JavaThread* current); >> 67: >> 68: static ObjectMonitor* inflate_into_object_header(Thread* current, JavaThread* inflating_thread, oop object, const ObjectSynchronizer::InflateCause cause); > > My IDE flags this with a warning 'Parameter 'cause' is const-qualified in the function declaration; const-qualification of parameters only has an effect in function definitions' *shrugs* Yeah. The only effect is has is that you cannot reassign the variable. It was the style taken from [synchronizer.hpp](https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.hpp) where all `InflateCause` parameters are const. > src/hotspot/share/runtime/lockStack.inline.hpp line 232: > >> 230: oop obj = monitor->object_peek(); >> 231: assert(obj != nullptr, "must be alive"); >> 232: assert(monitor == LightweightSynchronizer::get_monitor_from_table(JavaThread::current(), obj), "must be exist in table"); > > "must be exist in table" -> "must exist in table" Done. > src/hotspot/share/runtime/objectMonitor.cpp line 56: > >> 54: #include "runtime/safepointMechanism.inline.hpp" >> 55: #include "runtime/sharedRuntime.hpp" >> 56: #include "runtime/synchronizer.hpp" > > This include is not used. Removed. > src/hotspot/share/runtime/objectMonitor.hpp line 193: > >> 191: ObjectWaiter* volatile _WaitSet; // LL of threads wait()ing on the monitor >> 192: volatile int _waiters; // number of waiting threads >> 193: private: > > You can now also remove the 'private:' here Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240569 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240591 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240598 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240629 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240633 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240644 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240655 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240709 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240664 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240684 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240695 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240712 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240735 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240747 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240787 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240807 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240936 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241002 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241011 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241037 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241082 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241093 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241121 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241145 From liach at openjdk.org Mon Jul 15 01:51:16 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 01:51:16 GMT Subject: RFR: 8335922: Incorrect stable usage of LambdaForm$Name.index Message-ID: The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. ------------- Commit messages: - 8335922: Incorrect stable usage of LambdaForm$Name.index Changes: https://git.openjdk.org/jdk/pull/20178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335922 Stats: 21 lines in 2 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/20178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20178/head:pull/20178 PR: https://git.openjdk.org/jdk/pull/20178 From duke at openjdk.org Mon Jul 15 02:14:29 2024 From: duke at openjdk.org (lingjun-cg) Date: Mon, 15 Jul 2024 02:14:29 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v20] In-Reply-To: References: Message-ID: <-EHsTdeytuK6CP4DyELyHHjgUIR3THZzp4gN67_IlrU=.deaa242d-6411-449e-ac92-cacc77ed1ef5@github.com> > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op lingjun-cg has updated the pull request incrementally with two additional commits since the last revision: - 8333396: Use StringBuilder internally for java.text.Format.* formatting - 8333396: Use StringBuilder internally for java.text.Format.* formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19513/files - new: https://git.openjdk.org/jdk/pull/19513/files/6573e413..ee46eea3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=18-19 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513 From duke at openjdk.org Mon Jul 15 02:30:54 2024 From: duke at openjdk.org (lingjun-cg) Date: Mon, 15 Jul 2024 02:30:54 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21] In-Reply-To: References: Message-ID: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: 8333396: Use StringBuilder internally for java.text.Format.* formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19513/files - new: https://git.openjdk.org/jdk/pull/19513/files/ee46eea3..350085bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19513&range=19-20 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19513/head:pull/19513 PR: https://git.openjdk.org/jdk/pull/19513 From jkratochvil at openjdk.org Mon Jul 15 02:35:57 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Jul 2024 02:35:57 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Thu, 11 Jul 2024 10:39:23 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: >> >> - Fix the gtest >> - fix compilation warning >> - fix the gtest >> - less refactorizations >> - remove not a real backward compat. >> - whitespace >> - less refactorizations >> - reduce refactorizations >> - Fix caching >> - Merge branch 'master' into master-cgroup >> - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 > > test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp line 1: > >> 1: /* > > Why are those test changes needed? As before there was for V1: CgroupV1Controller* ctrl = new CgroupV1Controller( (char*)testCases[i]->root_path, (char*)testCases[i]->mount_path, true /* read-only mount */); ctrl->set_subsystem_path((char*)testCases[i]->cgroup_path); vs. for V2: CgroupV2Controller* ctrl = new CgroupV2Controller( (char*)testCases[i]->mount_path, (char*)testCases[i]->cgroup_path, true /* read-only mount */); Which was error prone as both parameters were `char *` with different meaning. Now it is all unified with the same parameters order, for V1: CgroupV1Controller* ctrl = new CgroupV1Controller( (char*)testCases[i]->root_path, (char*)testCases[i]->mount_path, true /* read-only mount */); ctrl->set_subsystem_path((char*)testCases[i]->cgroup_path); and similarly V2: CgroupV2Controller* ctrl = new CgroupV2Controller( (char*)testCases[i]->root_path, (char*)testCases[i]->mount_path, true /* read-only mount */); ctrl->set_subsystem_path((char*)testCases[i]->cgroup_path); That `set_subsystem_path` should be probably a part of the ctor but that is for a later refactorization. Besides that for example `larger_than_max` should be a path but it did not start with a slash ('/') which did not matter as `TestController` did override+skip `subsystem_path()` underneath but then the whole testfile did not test much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1677267509 From jkratochvil at openjdk.org Mon Jul 15 03:54:00 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Jul 2024 03:54:00 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Thu, 11 Jul 2024 12:47:38 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: >> >> - Fix the gtest >> - fix compilation warning >> - fix the gtest >> - less refactorizations >> - remove not a real backward compat. >> - whitespace >> - less refactorizations >> - reduce refactorizations >> - Fix caching >> - Merge branch 'master' into master-cgroup >> - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 > > src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 836: > >> 834: >> 835: void CgroupController::set_path(const char *cgroup_path) { >> 836: __attribute__((unused)) bool _cgroup_path; // Do not use the member variable. > > This seems an unusual pattern for Hotspot. So what is a better solution? `#define`? `__attribute__((unused))` is used in `src/hotspot/os_cpu/linux_riscv/atomic_linux_riscv.hpp` (although in a different way). > test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 1: > >> 1: /* > > I think a more generic solution would be to use https://bugs.openjdk.org/browse/JDK-8333446 for testing (requires only systemd vs. this requiring libcg). A hierarchy setup of two limits should be possible with it too, though I'm doubtful that's needed. This was already discussed before there are fortunately still systems not plagued by `systemd`, OpenJDK on these systems is commercially supported so the testsuite should work there to prevent regressions. Otherwise false testsuite failures like [JDK-8335882](https://bugs.openjdk.org/browse/JDK-8335882) and possible future real regressions can happen on Alpine Linux. In fact there is no fix of [JDK-8335882](https://bugs.openjdk.org/browse/JDK-8335882) - the test is now just skipped. Alpine Linux has `libcgroup-dev-3.1.0-r0` and there is no `systemd`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1677289440 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1677288589 From jkratochvil at openjdk.org Mon Jul 15 04:02:00 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Jul 2024 04:02:00 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Thu, 11 Jul 2024 12:49:24 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: >> >> - Fix the gtest >> - fix compilation warning >> - fix the gtest >> - less refactorizations >> - remove not a real backward compat. >> - whitespace >> - less refactorizations >> - reduce refactorizations >> - Fix caching >> - Merge branch 'master' into master-cgroup >> - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 > > src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 910: > >> 908: memory_swap_limit_min = memory_swap_limit; >> 909: best_level = dir_count; >> 910: } > > There is no point in doing memory and memory and swap. Both are controlled by the same controller. So there is no chance that the paths would differ. The code finds the lowest level which has any limit set (=is not `max`). If both `memory.max` and `memory.swap.max` are `max` in the leaf it goes to the parent level. But I see you do not want to calculate what Linux kernel does but you rather assume descending memory limits. So from this your change this function should find only the lowest level with existing controller. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1677291679 From liach at openjdk.org Mon Jul 15 04:10:20 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 04:10:20 GMT Subject: RFR: 8336267: Method and Constructor signature parsing can be shared on the root object Message-ID: A straightforward optimization, to share the signature parsing of method, constructor, and field between the root and the copied objects, like how method handle accessors are shared. ------------- Commit messages: - 8336267: Method and Constructor signature parsing can be shared on the root object Changes: https://git.openjdk.org/jdk/pull/20179/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336267 Stats: 31 lines in 3 files changed: 20 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20179.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20179/head:pull/20179 PR: https://git.openjdk.org/jdk/pull/20179 From ysuenaga at openjdk.org Mon Jul 15 04:12:56 2024 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 15 Jul 2024 04:12:56 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided In-Reply-To: References: Message-ID: <0kgJRNtXshGieoX3zd_0bQVV6I_Pwmr7ytfdBrlI-4Q=.cea14512-29b2-463f-8d42-329af9eccb43@github.com> On Sun, 14 Jul 2024 14:38:39 GMT, Jaikiran Pai wrote: > Hello @YaSuenag, I haven't had a chance to build your change locally and try it myself, but I suspect this change isn't enough to address the issue. Does this change allow for: > > ``` > jlink ... --add-options --add-exports java.base/jdk.internal.misc=ALL-UNNAMED > ``` It would not work. `--add-exports java.base/jdk.internal.misc=ALL-UNNAMED` should be an one option for `--add-options`, so it should be quoted. `"--add-exports java.base/jdk.internal.misc=ALL-UNNAMED"` would NOT be worked, but `--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED` would be worked because option parsar is different between `java` and jlink'ed app. In `java`, `--add-options` would be parsed in `src/java.base/share/native/libjli/java.c`, but in jlink'ed app, it would be parsed in `src/hotspot/hotspot/share/runtime/arguments.cpp` because command line options are pick-upped from `vmoptions` in `modules` file. Then only `--add-exports=` would be handled in HotSpot - so you cannot specify `--add-exports [module]` for jlink'ed app. You have to specify `--add-exports=[module]`. > Additionally, do the current tests pass with your proposed change? I tested this patch with `test/jdk/tools/jlink` jtreg tests, and all of tests were passed on my Linux x64 of course. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19987#issuecomment-2227669198 From asotona at openjdk.org Mon Jul 15 05:44:55 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 15 Jul 2024 05:44:55 GMT Subject: Integrated: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero In-Reply-To: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> References: <9VXHJJBHnQFxSHMyi2ypo4p4MnDiLLVTrA7-1p0N3Hs=.0f35a132-5f36-482c-b202-027a15358d98@github.com> Message-ID: On Mon, 8 Jul 2024 13:09:50 GMT, Adam Sotona wrote: > Class-File API constant pool implementation requires non-zero entry hash code. > Unfortunately current implementation computes zero hash code for specific CP entries. > > This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation and assures all pool entries have non-zero hash. A regression test of the actual zero-hash `IntegerEntry` has been added. > > All pre-computed hash codes in `BoundAttribute::standardAttribute` are updated. > > The patch has no performance effect measurable by any of the actual Class-File API benchmarks. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 3f2636d9 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/3f2636d9b71f5270c83d17dcf5d18cf907978475 Stats: 57 lines in 4 files changed: 7 ins; 7 del; 43 mod 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/20074 From asotona at openjdk.org Mon Jul 15 05:46:52 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 15 Jul 2024 05:46:52 GMT Subject: RFR: 8335642: Hide Transform implementation for Class-File API [v3] In-Reply-To: References: Message-ID: On Sun, 14 Jul 2024 13:49:09 GMT, Chen Liang wrote: >> Removes ClassFile API transformation implementation details accidentally leaked to public API. Users don't have access to classes necessary to correctly implement these transform resolutions. In addition, removed improper `canWriteDirect` and made `ClassFileBuilder::transform` chain returns. >> >> Replaces #19928. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/hide-transform > - return tag required > - 8335642: Hide Transform implementation for Class-File API Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20102#pullrequestreview-2176891171 From jkratochvil at openjdk.org Mon Jul 15 05:56:12 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Jul 2024 05:56:12 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Thu, 11 Jul 2024 06:54:27 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Fix by Severin Gehwolf. >> Testcase by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: > > - Fix the gtest > - fix compilation warning > - fix the gtest > - less refactorizations > - remove not a real backward compat. > - whitespace > - less refactorizations > - reduce refactorizations > - Fix caching > - Merge branch 'master' into master-cgroup > - ... and 93 more: https://git.openjdk.org/jdk/compare/537d20af...060e7688 That's a great patch, thanks. I have used your fix and added my testcase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2227744424 From jkratochvil at openjdk.org Mon Jul 15 05:56:12 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Jul 2024 05:56:12 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v13] In-Reply-To: References: Message-ID: <_cqht9evIsrJfFxu2mG8XnTnRMFzN9aAeQrtCldb5D0=.0a9ee9a4-1e4f-4a48-8b85-65640e4195be@github.com> > The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request incrementally with 10 additional commits since the last revision: - Merge branch 'master-jdk-8322420_cgroup_hierarchy_walk_init-test' into master-cgroup - +test - Merge branch 'master' into master-jdk-8322420_cgroup_hierarchy_walk_init - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init - 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected - Remove the Jan's patch - Ignore "max" leafs - Remove ctors inheritance according to the Hotspot style - Remove the Java part ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17198/files - new: https://git.openjdk.org/jdk/pull/17198/files/060e7688..da84a278 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=11-12 Stats: 876 lines in 19 files changed: 532 ins; 273 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From asotona at openjdk.org Mon Jul 15 05:58:22 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 15 Jul 2024 05:58:22 GMT Subject: [jdk23] RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Message-ID: <-FiPfQt5c5RK0jLYskHjXCnuYSbdadUKBCHsxa_q3ok=.a8bd96e8-b82f-4d6e-b618-2a35a15a5c7b@github.com> 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero ------------- Commit messages: - Backport 3f2636d9b71f5270c83d17dcf5d18cf907978475 Changes: https://git.openjdk.org/jdk/pull/20180/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335820 Stats: 57 lines in 4 files changed: 7 ins; 7 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/20180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20180/head:pull/20180 PR: https://git.openjdk.org/jdk/pull/20180 From jkratochvil at openjdk.org Mon Jul 15 07:02:11 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Jul 2024 07:02:11 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v14] In-Reply-To: References: Message-ID: <_hcyal491UTTWXj9TeVmrn7yv-nOqkdoC7WKhiSj64k=.1b5c5e06-e467-4dc9-bc6f-34c7ae573777@github.com> > The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: Fix a needless whitespace change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17198/files - new: https://git.openjdk.org/jdk/pull/17198/files/da84a278..82db527b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From jkratochvil at openjdk.org Mon Jul 15 07:02:11 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Jul 2024 07:02:11 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v13] In-Reply-To: <_cqht9evIsrJfFxu2mG8XnTnRMFzN9aAeQrtCldb5D0=.0a9ee9a4-1e4f-4a48-8b85-65640e4195be@github.com> References: <_cqht9evIsrJfFxu2mG8XnTnRMFzN9aAeQrtCldb5D0=.0a9ee9a4-1e4f-4a48-8b85-65640e4195be@github.com> Message-ID: <6TpWTyIGYd6UftYUdRUPqJxNrr5BAhP_ioIUuuVNgvI=.0dd92c41-efff-47b9-bbb0-6c70f220a8c6@github.com> On Mon, 15 Jul 2024 05:56:12 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Fix by Severin Gehwolf. >> Testcase by Jan Kratochvil. > > Jan Kratochvil has updated the pull request incrementally with 10 additional commits since the last revision: > > - Merge branch 'master-jdk-8322420_cgroup_hierarchy_walk_init-test' into master-cgroup > - +test > - Merge branch 'master' into master-jdk-8322420_cgroup_hierarchy_walk_init > - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init > - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init > - 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected > - Remove the Jan's patch > - Ignore "max" leafs > - Remove ctors inheritance according to the Hotspot style > - Remove the Java part src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp line 120: > 118: > 119: public: > 120: CgroupV2Subsystem(CgroupV2MemoryController * memory, Suggestion: CgroupV2Subsystem(CgroupV2MemoryController* memory, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1677385022 From iris at openjdk.org Mon Jul 15 07:28:51 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 15 Jul 2024 07:28:51 GMT Subject: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: <1VyHfXGxyqs_YyjxHcdm7u8Qtnv4g7RJXVtgIyCk9vk=.5aa8945a-ac5b-41b8-a8fa-b41ad8d9d30a@github.com> On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and erroneous links in the doc files. Confirmed identical to original PR. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20166#pullrequestreview-2177021556 From rgiulietti at openjdk.org Mon Jul 15 07:46:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 15 Jul 2024 07:46:54 GMT Subject: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v5] In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 22:44:31 GMT, Joe Darcy wrote: >> Misc small doc updates and addition of `@Overrides` annotations. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Sample precision-based conversion. > - Merge branch 'master' into JDK-8333768 > - Include "-" to HTML minus update. > - Merge branch 'master' into JDK-8333768 > - Respond to review feedback. > - Merge branch 'master' into JDK-8333768 > - Merge branch 'master' into JDK-8333768 > - JDK-8333768: Minor doc updates to java.lang.{Float, Double} Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19590#pullrequestreview-2177049990 From jpai at openjdk.org Mon Jul 15 07:54:50 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 07:54:50 GMT Subject: [jdk23] RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero In-Reply-To: <-FiPfQt5c5RK0jLYskHjXCnuYSbdadUKBCHsxa_q3ok=.a8bd96e8-b82f-4d6e-b618-2a35a15a5c7b@github.com> References: <-FiPfQt5c5RK0jLYskHjXCnuYSbdadUKBCHsxa_q3ok=.a8bd96e8-b82f-4d6e-b618-2a35a15a5c7b@github.com> Message-ID: On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote: > 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero This is a clean backport of a P3 bug. Looks good to me for JDK 23. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20180#pullrequestreview-2177064232 From dnsimon at openjdk.org Mon Jul 15 08:30:51 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 15 Jul 2024 08:30:51 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods src/hotspot/share/prims/scopedMemoryAccess.cpp line 179: > 177: // > 178: // The safepoint at which we're stopped may be in between the liveness check > 179: // and actual memory access, but is itself 'outside' of @Scoped code what is `@Scoped code`? I don't see that annotation mentioned here: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ScopedValue.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677474756 From dnsimon at openjdk.org Mon Jul 15 08:43:53 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 15 Jul 2024 08:43:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods src/hotspot/share/jvmci/jvmciRuntime.cpp line 2186: > 2184: nm->set_has_wide_vectors(has_wide_vector); > 2185: nm->set_has_monitors(has_monitors); > 2186: nm->set_has_scoped_access(true); // conservative What does "conservative" imply here? That is, what performance penalty will be incurred for Graal compiled code until it completely supports this "scoped access" bit? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677490130 From uschindler at openjdk.org Mon Jul 15 08:43:54 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 08:43:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 08:28:16 GMT, Doug Simon wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> track has_scoped_access for compiled methods > > src/hotspot/share/prims/scopedMemoryAccess.cpp line 179: > >> 177: // >> 178: // The safepoint at which we're stopped may be in between the liveness check >> 179: // and actual memory access, but is itself 'outside' of @Scoped code > > what is `@Scoped code`? I don't see that annotation mentioned here: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ScopedValue.html This is the whole magic around the shared arena. It is not public API and internal to Hotspot/VM: - https://github.com/openjdk/jdk/blob/a96de6d8d273d75a6500e10ed06faab9955f893b/src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template#L117-L119 - https://github.com/openjdk/jdk/blob/a96de6d8d273d75a6500e10ed06faab9955f893b/src/hotspot/share/prims/scopedMemoryAccess.cpp#L143-L149 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677486942 From alanb at openjdk.org Mon Jul 15 08:43:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 08:43:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 08:38:59 GMT, Uwe Schindler wrote: >> src/hotspot/share/prims/scopedMemoryAccess.cpp line 179: >> >>> 177: // >>> 178: // The safepoint at which we're stopped may be in between the liveness check >>> 179: // and actual memory access, but is itself 'outside' of @Scoped code >> >> what is `@Scoped code`? I don't see that annotation mentioned here: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ScopedValue.html > > This is the whole magic around the shared arena. It is not public API and internal to Hotspot/VM: > - https://github.com/openjdk/jdk/blob/a96de6d8d273d75a6500e10ed06faab9955f893b/src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template#L117-L119 > - https://github.com/openjdk/jdk/blob/a96de6d8d273d75a6500e10ed06faab9955f893b/src/hotspot/share/prims/scopedMemoryAccess.cpp#L143-L149 > what is `@Scoped code`? I don't see that annotation mentioned here: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ScopedValue.html This is nothing to do with scoped values, instead this is an annotation declared in jdk.internal.misc.ScopedMemoryAccess that is known to the VM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677489415 From uschindler at openjdk.org Mon Jul 15 08:53:52 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 08:53:52 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 08:41:01 GMT, Alan Bateman wrote: >> This is the whole magic around the shared arena. It is not public API and internal to Hotspot/VM: >> - https://github.com/openjdk/jdk/blob/a96de6d8d273d75a6500e10ed06faab9955f893b/src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template#L117-L119 >> - https://github.com/openjdk/jdk/blob/a96de6d8d273d75a6500e10ed06faab9955f893b/src/hotspot/share/prims/scopedMemoryAccess.cpp#L143-L149 > >> what is `@Scoped code`? I don't see that annotation mentioned here: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/ScopedValue.html > > This is nothing to do with scoped values, instead this is an annotation declared in jdk.internal.misc.ScopedMemoryAccess that is known to the VM. Basically if the VM is inside a `@Scoped` method and it starts a thread-local handshake, it will deoptimize top-most frame of all those threads so they can do the "isAlive" check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677501161 From mcimadamore at openjdk.org Mon Jul 15 08:56:54 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 08:56:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Sun, 14 Jul 2024 11:01:58 GMT, Uwe Schindler wrote: > I have one problem with the benchmark: I think it is not measuring the whole setup in a way that is our workload: The basic problem is that we don't want to deoptimize threads which are not related to MemorySegments. So basically, the throughput of those threads should not be affected. For threads currently in a memory-segment read it should have a bit of effect, but it should recover fast. IMHO there is a bit of confusion in this discussion. When we say that a shared arena close operation is slow, we might mean one of two things: 1. calling the `close()` method itself is slow (this is what the benchmark effectively measures) 2. throughput of unrelated threads is affected (I think this is what Lucene is seeing) Addressing (2) than (1) (in the sense that, if you sign up for a shared arena close, you know it's going to be deterministic, but expensive, as the javadoc itself admits). For this reason, I'm unsure about some of the "delaying tactics" I see mentioned here: if we delay the underlying "free"/"unmap" operation, this is only going to affect (1). You still need some global operation (e.g. handshake) to make sure all threads agree on the segment state. Moving the cost of the free/unmap from one place to another is not really going to do much for (2). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228002760 From mcimadamore at openjdk.org Mon Jul 15 09:00:52 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 09:00:52 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: <1x3PmjfjQXR2h3k8UlLT0N9_yvLbNw_cn3O7NRLDt_U=.68c48202-af31-40ed-836b-ecafd051113f@github.com> On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > track has_scoped_access for compiled methods test/micro/org/openjdk/bench/java/lang/foreign/ConcurrentClose.java line 34: > 32: import static java.lang.foreign.ValueLayout.*; > 33: > 34: @BenchmarkMode(Mode.AverageTime) Doesn't the existing bench `MemorySessionClose` already covers this? That benchmark has three stress modes, and one of them spawns many unrelated threads (but there is only one thread doing a close). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677508532 From uschindler at openjdk.org Mon Jul 15 09:00:53 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 09:00:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <1x3PmjfjQXR2h3k8UlLT0N9_yvLbNw_cn3O7NRLDt_U=.68c48202-af31-40ed-836b-ecafd051113f@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> <1x3PmjfjQXR2h3k8UlLT0N9_yvLbNw_cn3O7NRLDt_U=.68c48202-af31-40ed-836b-ecafd051113f@github.com> Message-ID: On Mon, 15 Jul 2024 08:57:08 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> track has_scoped_access for compiled methods > > test/micro/org/openjdk/bench/java/lang/foreign/ConcurrentClose.java line 34: > >> 32: import static java.lang.foreign.ValueLayout.*; >> 33: >> 34: @BenchmarkMode(Mode.AverageTime) > > Doesn't the existing bench `MemorySessionClose` already covers this? That benchmark has three stress modes, and one of them spawns many unrelated threads (but there is only one thread doing a close). It should also run threads not doing any scoped accesses to verify that other threads are not affected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677509975 From uschindler at openjdk.org Mon Jul 15 09:04:54 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 09:04:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 08:54:11 GMT, Maurizio Cimadamore wrote: > > I have one problem with the benchmark: I think it is not measuring the whole setup in a way that is our workload: The basic problem is that we don't want to deoptimize threads which are not related to MemorySegments. So basically, the throughput of those threads should not be affected. For threads currently in a memory-segment read it should have a bit of effect, but it should recover fast. > > IMHO there is a bit of confusion in this discussion. When we say that a shared arena close operation is slow, we might mean one of two things: > > 1. calling the `close()` method itself is slow (this is what the benchmark effectively measures) > 2. throughput of unrelated threads is affected (I think this is what Lucene is seeing) > > Addressing (2) than (1) (in the sense that, if you sign up for a shared arena close, you know it's going to be deterministic, but expensive, as the javadoc itself admits). I fully agree, we mixed two different approaches. The problem is that the benchmark measures both, 1 and 2 per thread. To see an effect of this change, the benchmark should have 3 types of threads: One only closing arenas, another set that consumes scoped memory and a third group doing totally unrelated stuff. > For this reason, I'm unsure about some of the "delaying tactics" I see mentioned here: if we delay the underlying "free"/"unmap" operation, this is only going to affect (1). You still need some global operation (e.g. handshake) to make sure all threads agree on the segment state. Moving the cost of the free/unmap from one place to another is not really going to do much for (2). This is indeed unrelated. It is just an idea I also thorught of. In Apache Lucene we are mostly interested to close the shared arena as soon as possible. We don't need to make sure it is closed after the "close" call finished (we don't care), but we can't wait until GC closes the arena possibly after hours or even days. The reason for the latter is that the Arena is a small, long-living instance and GC does not want to free it, as there is no pressure. So basically for us it would be best to trigger the close and then do other stuff. Of course we can do that in a separate thread (this is my idea how to improve the closes in lucene). The only problem is that Lucene does not have own threadpools, so this would be responsibility of the caller to possibly close our indexes in a separate thread (and a single one only). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228018619 From asotona at openjdk.org Mon Jul 15 09:06:53 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 15 Jul 2024 09:06:53 GMT Subject: [jdk23] RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero In-Reply-To: <-FiPfQt5c5RK0jLYskHjXCnuYSbdadUKBCHsxa_q3ok=.a8bd96e8-b82f-4d6e-b618-2a35a15a5c7b@github.com> References: <-FiPfQt5c5RK0jLYskHjXCnuYSbdadUKBCHsxa_q3ok=.a8bd96e8-b82f-4d6e-b618-2a35a15a5c7b@github.com> Message-ID: On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote: > 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20180#issuecomment-2228021104 From asotona at openjdk.org Mon Jul 15 09:06:54 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 15 Jul 2024 09:06:54 GMT Subject: [jdk23] Integrated: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero In-Reply-To: <-FiPfQt5c5RK0jLYskHjXCnuYSbdadUKBCHsxa_q3ok=.a8bd96e8-b82f-4d6e-b618-2a35a15a5c7b@github.com> References: <-FiPfQt5c5RK0jLYskHjXCnuYSbdadUKBCHsxa_q3ok=.a8bd96e8-b82f-4d6e-b618-2a35a15a5c7b@github.com> Message-ID: On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote: > 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero This pull request has now been integrated. Changeset: 52cd9bb5 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/52cd9bb5345b1dd80293426f4386d408361279e2 Stats: 57 lines in 4 files changed: 7 ins; 7 del; 43 mod 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Reviewed-by: jpai Backport-of: 3f2636d9b71f5270c83d17dcf5d18cf907978475 ------------- PR: https://git.openjdk.org/jdk/pull/20180 From mcimadamore at openjdk.org Mon Jul 15 09:14:53 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 09:14:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 09:02:29 GMT, Uwe Schindler wrote: > One only closing arenas, another set that consumes scoped memory and a third group doing totally unrelated stuff. Exactly. My general feeling is that the cost of handshaking a thread dominates everything else, so doing improvements around e.g. avoiding unnecessary deoptimization (as in this PR) is not going to help much, even for threads doing unrelated stuff, but I'd be happy to be proven wrong. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228035799 From uschindler at openjdk.org Mon Jul 15 09:21:53 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 09:21:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: <7_MKD2O70VqPmWUn5_TcL3AZ-yT8iB6uv7zk8s9xIDQ=.57d7a025-d31c-4f32-a55c-c919490218e3@github.com> References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> <7_MKD2O70VqPmWUn5_TcL3AZ-yT8iB6uv7zk8s9xIDQ=.57d7a025-d31c-4f32-a55c-c919490218e3@github.com> Message-ID: On Mon, 15 Jul 2024 09:17:31 GMT, Maurizio Cimadamore wrote: >>> One only closing arenas, another set that consumes scoped memory and a third group doing totally unrelated stuff. >> >> Exactly. My general feeling is that the cost of handshaking a thread dominates everything else, so doing improvements around e.g. avoiding unnecessary deoptimization (as in this PR) is not going to help much, even for threads doing unrelated stuff, but I'd be happy to be proven wrong. > >> avoiding unnecessary deoptimization (as in this PR) is not going to help much, > > What would definitively help is to somehow reduce the number of threads to handshake when calling close - e.g. have an arena that is shared but only to a *group* of thread. We can do that easily using structured concurrency. But for unstructured code there's not a lot that can be done, as there's no way for the runtime to guess which threads can access segments created by a given arena. @mcimadamore: FYI, at the moment we are working on grouping mmapped files together (by their index segment file pattern) and use the same arena for multiple index files. Because those are closed together we can use a refcounted aproach. All files of a group (the index segment name) share the same arena and this one is closed after last file in group is closed: https://github.com/apache/lucene/pull/13570 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228049242 From mcimadamore at openjdk.org Mon Jul 15 09:21:53 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 09:21:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: <7_MKD2O70VqPmWUn5_TcL3AZ-yT8iB6uv7zk8s9xIDQ=.57d7a025-d31c-4f32-a55c-c919490218e3@github.com> On Mon, 15 Jul 2024 09:11:53 GMT, Maurizio Cimadamore wrote: > avoiding unnecessary deoptimization (as in this PR) is not going to help much, What would definitively help is to somehow reduce the number of threads to handshake when calling close - e.g. have an arena that is shared but only to a *group* of thread. We can do that easily using structured concurrency. But for unstructured code there's not a lot that can be done, as there's no way for the runtime to guess which threads can access segments created by a given arena. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228046170 From jpai at openjdk.org Mon Jul 15 09:34:51 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 09:34:51 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v3] In-Reply-To: References: Message-ID: On Sun, 16 Jun 2024 06:36:00 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Chen's suggestion - improve code comment Please keep open, I'm running some experiments for the proposed alternative and I'll update this PR shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19675#issuecomment-2228073341 From jpai at openjdk.org Mon Jul 15 10:05:06 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 10:05:06 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: Message-ID: <1LpE3PouwnkAjmDiKs0y6eUsM6NrH-YbesXHLPFZcUs=.c38e1f6e-0d1c-4390-b575-733f051ea920@github.com> On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Bump @since from 23 to 24. > - Merge branch 'master' into JDK-8322256 > - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. > - Simplify code by eliminating an impossible case. > - Field name change and Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Clarify exceptions: sometimes ZipException, sometimes EOFException. > - Merge branch 'master' into JDK-8322256 > - ... and 2 more: https://git.openjdk.org/jdk/compare/75dc2f85...f845a75b Hello Archie, sorry it has taken long to review this PR. The proposal here is to have `java.util.zip.GZIPInputStream` specify (and improve) how it deals with concatenated GZIP stream(s) and also allow for applications instantiating `GZIPInputStream` to decide whether or not the underlying `InputStream` passed to the `GZIPInputStream` instance is expected to contain a concatenated GZIP stream(s). I'll include here the text that I had sent in a private communication to Archie: I think this comes down to introducing a new optional boolean parameter to the constructor of GZIPInputStream. The boolean when "true" will attempt to read a potential additional GZIP stream after the previous GZIP stream's trailer has been read. In that case we need to handle 2 cases - one where we successfully find the header of the next (concatenated) GZIP stream and the other where we don't find a valid GZIP stream header. In the first case where we do find a header successfully, then we continue reading the stream as usual and return the uncompressed data from the "read()" call. In the case where we fail to find a valid header and yet there were bytes past the previous GZIP stream, then I think the GZIPInputStream.read() should throw an IOException, since that stream no longer represents a GZIP stream (remember, we are talking about this only when the GZIPInputStream was constructed with the new boolean parameter = true). Coming to the case where the GZIPInputStream was constructed using boolean = false - In this case when we reach and read the trailer of a GZIP stream, if there is no more bytes, then we consider this a completed GZIP stream and return the uncompressed data. If there is any more bytes past the GZIP stream's trailer, then I think we should throw a IOException (since we aren't expecting any concatenated GZIP stream). As for the default value of this optional boolean parameter, I think it should default to "true" implying it will read any concatenated GZIP streams. That would match the current implementation of GZIPInputStream.read() which has the ability to read (valid) GZIP concatenated input stream. I think this would then allow us to keep the implementation simple as well as allow the calling application to have control over whether or not the passed should be considered as having a concatenated GZIP stream. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2228129529 From jpai at openjdk.org Mon Jul 15 10:08:56 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 10:08:56 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: Message-ID: <5XLyS-nRJakdnvUky0vcEQnzIqz9O9SE-ZDhEePqGXY=.6e047b48-999d-4eca-b1cb-ed1f88d57b2c@github.com> On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Bump @since from 23 to 24. > - Merge branch 'master' into JDK-8322256 > - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. > - Simplify code by eliminating an impossible case. > - Field name change and Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Clarify exceptions: sometimes ZipException, sometimes EOFException. > - Merge branch 'master' into JDK-8322256 > - ... and 2 more: https://git.openjdk.org/jdk/compare/75dc2f85...f845a75b src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 153: > 151: */ > 152: public GZIPInputStream(InputStream in, int size, > 153: boolean allowConcatenation, boolean ignoreExtraBytes) throws IOException { I haven't reviewed the javadoc changes. I will do that separately once we settle down on the API and implementation changes. As for this new constructor, I think the only new parameter we should introduce is whether or not the underlying input stream `in` is expected/allowed to have concatenated GZIP stream(s). So I think we should remove the "ignoreExtraBytes" new parameters from this constructor and. Additionally, I think the `allowConcatenation` should instead be named `allowConcatenatedGZIPStream`: public GZIPInputStream(InputStream in, int size, boolean allowConcatenatedGZIPStream) throws IOException { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1677592647 From jvernee at openjdk.org Mon Jul 15 10:28:52 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 10:28:52 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: <1MbFi_08NlZRB0wF-sBB_JnNzHr4DjDdOa6hkGmXjjY=.ba6c7bcb-88d9-4fb6-b817-2b2527934931@github.com> On Mon, 15 Jul 2024 08:41:38 GMT, Doug Simon wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> track has_scoped_access for compiled methods > > src/hotspot/share/jvmci/jvmciRuntime.cpp line 2186: > >> 2184: nm->set_has_wide_vectors(has_wide_vector); >> 2185: nm->set_has_monitors(has_monitors); >> 2186: nm->set_has_scoped_access(true); // conservative > > What does "conservative" imply here? That is, what performance penalty will be incurred for Graal compiled code until it completely supports this "scoped access" bit? It means we will always deoptimize a top-most frame of any thread, when closing a shared arena, and it is compiled by Graal. (This is a one-off deoptimization though. The compiled code is not thrown away). It essentially matches the current behavior before this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1677613801 From jvernee at openjdk.org Mon Jul 15 10:52:53 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 10:52:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 09:02:29 GMT, Uwe Schindler wrote: > Of course we can do that in a separate thread (this is my idea how to improve the closes in lucene). This is what I was thinking of as well. `close()` on a shared arena can be called by any thread, so it would be possible to have an executor service with 1-n threads that is dedicated to closing memory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228215031 From shade at openjdk.org Mon Jul 15 11:15:50 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Jul 2024 11:15:50 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index In-Reply-To: References: Message-ID: <-yVtp8uMuk7pyksgPPBZDjDpx8IgSzyrG_KAU29T5yQ=.f42573b5-4dda-4a4e-8f86-ed2bdfef1a0d@github.com> On Mon, 15 Jul 2024 01:45:57 GMT, Chen Liang wrote: > The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. Is there are benefit from just doing `0` as unused, and `1..256` as payload values? I.e. doing `+1` and `-1` instead of inverting? I suspect that would be more straight-forward, and probably better for generated code quality, when immediates are not fully-blown negative immediates? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2228253565 From jvernee at openjdk.org Mon Jul 15 11:33:30 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 11:33:30 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.conf... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: improve benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20158/files - new: https://git.openjdk.org/jdk/pull/20158/files/d1266b53..6d0b9b57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=01-02 Stats: 28 lines in 1 file changed: 14 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/20158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20158/head:pull/20158 PR: https://git.openjdk.org/jdk/pull/20158 From forax at openjdk.org Mon Jul 15 11:33:30 2024 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 15 Jul 2024 11:33:30 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 10:50:34 GMT, Jorn Vernee wrote: > This is what I was thinking of as well. close() on a shared arena can be called by any thread, so it would be possible to have an executor service with 1-n threads that is dedicated to closing memory. This delays both the closing of the Arena and the freeing of the segments, so bugs may be not discovered if the arena is accessed in between the time the thread pool is notified and the time the close() is effectively called. And you loose the structured part of the API, you can not use a try-with-resources anymore. I think that part can be fixed using a wrapper on top of Arena.ofShared(). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228280373 From jvernee at openjdk.org Mon Jul 15 11:49:53 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 11:49:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > improve benchmark I've update the benchmark to run with 3 separate threads: 1 thread that is just creating and closing shared arenas in a loop, 1 that is accessing memory using the FFM API, and 1 that is accessing a `byte[]`. Current: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 50.093 ? 6.200 us/op ConcurrentClose.sharedClose:closing avgt 10 46.269 ? 0.786 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 98.072 ? 19.061 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 5.938 ? 0.058 us/op I do see a pretty big difference on the memory segment accessing thread when I remove deoptimization altogether: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 22.664 ? 0.409 us/op ConcurrentClose.sharedClose:closing avgt 10 45.351 ? 1.554 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 16.671 ? 0.251 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 5.969 ? 0.089 us/op When I remove the `has_scoped_access()` check before the deopt, I expect the `otherAccess` thread to be affected, but the effect isn't nearly as big as with the FFM thread. I think this is likely due to the `otherAccess` benchmark being less sensitive to optimization (i.e. it already runs fairly fast in the interpreter). I also tried using `MethodHandles::arrayElementGetter` for the access, but the numbers I got were pretty much the same: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 52.745 ? 1.071 us/op ConcurrentClose.sharedClose:closing avgt 10 46.670 ? 0.453 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 102.663 ? 3.430 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 8.901 ? 0.109 us/op I think, to really test the effect of the `has_scoped_access` check, we need to look at a more realistic scenario. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228311368 From mcimadamore at openjdk.org Mon Jul 15 12:02:51 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 12:02:51 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 11:47:43 GMT, Jorn Vernee wrote: > I've update the benchmark to run with 3 separate threads: 1 thread that is just creating and closing shared arenas in a loop, 1 that is accessing memory using the FFM API, and 1 that is accessing a `byte[]`. > > Current: > > ``` > Benchmark Mode Cnt Score Error Units > ConcurrentClose.sharedClose avgt 10 50.093 ? 6.200 us/op > ConcurrentClose.sharedClose:closing avgt 10 46.269 ? 0.786 us/op > ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 98.072 ? 19.061 us/op > ConcurrentClose.sharedClose:otherAccess avgt 10 5.938 ? 0.058 us/op > ``` > > I do see a pretty big difference on the memory segment accessing thread when I remove deoptimization altogether: > > ``` > Benchmark Mode Cnt Score Error Units > ConcurrentClose.sharedClose avgt 10 22.664 ? 0.409 us/op > ConcurrentClose.sharedClose:closing avgt 10 45.351 ? 1.554 us/op > ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 16.671 ? 0.251 us/op > ConcurrentClose.sharedClose:otherAccess avgt 10 5.969 ? 0.089 us/op > ``` > > When I remove the `has_scoped_access()` check before the deopt, I expect the `otherAccess` thread to be affected, but the effect isn't nearly as big as with the FFM thread. I think this is likely due to the `otherAccess` benchmark being less sensitive to optimization (i.e. it already runs fairly fast in the interpreter). I also tried using `MethodHandles::arrayElementGetter` for the access, but the numbers I got were pretty much the same: > > ``` > Benchmark Mode Cnt Score Error Units > ConcurrentClose.sharedClose avgt 10 52.745 ? 1.071 us/op > ConcurrentClose.sharedClose:closing avgt 10 46.670 ? 0.453 us/op > ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 102.663 ? 3.430 us/op > ConcurrentClose.sharedClose:otherAccess avgt 10 8.901 ? 0.109 us/op > ``` > > I think, to really test the effect of the `has_scoped_access` check, we need to look at a more realistic scenario. Interesting benchmark. What is the baseline here? E.g. can we also compare against same benchmark that is using a confined arena to do the closing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228335857 From mcimadamore at openjdk.org Mon Jul 15 12:12:53 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 12:12:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 12:00:31 GMT, Maurizio Cimadamore wrote: > When I remove the `has_scoped_access()` check before the deopt, I expect the `otherAccess` thread to be affected, but the effect isn't nearly as big as with the FFM thread. I think this is likely due to the `otherAccess` benchmark being less sensitive to optimization (i.e. it already runs fairly fast in the interpreter). I also tried using `MethodHandles::arrayElementGetter` for the access, but the numbers I got were pretty much the same: To put this into perspective, once the underlying bug with reachability fences is addressed, then we should see the numbers for this benchmark align with the ones where you removed deopt completely (as we won't deopt threads that don't have the target arena in their oopmap) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228353326 From liach at openjdk.org Mon Jul 15 12:14:56 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 12:14:56 GMT Subject: RFR: 8335642: Hide Transform implementation for Class-File API [v3] In-Reply-To: References: Message-ID: On Sun, 14 Jul 2024 13:49:09 GMT, Chen Liang wrote: >> Removes ClassFile API transformation implementation details accidentally leaked to public API. Users don't have access to classes necessary to correctly implement these transform resolutions. In addition, removed improper `canWriteDirect` and made `ClassFileBuilder::transform` chain returns. >> >> Replaces #19928. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/hide-transform > - return tag required > - 8335642: Hide Transform implementation for Class-File API Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20102#issuecomment-2228353316 From liach at openjdk.org Mon Jul 15 12:14:57 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 12:14:57 GMT Subject: Integrated: 8335642: Hide Transform implementation for Class-File API In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 18:47:35 GMT, Chen Liang wrote: > Removes ClassFile API transformation implementation details accidentally leaked to public API. Users don't have access to classes necessary to correctly implement these transform resolutions. In addition, removed improper `canWriteDirect` and made `ClassFileBuilder::transform` chain returns. > > Replaces #19928. This pull request has now been integrated. Changeset: a253e0ff Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/a253e0ff4b88541d01596b0e73ede4b96a258fca Stats: 164 lines in 9 files changed: 28 ins; 98 del; 38 mod 8335642: Hide Transform implementation for Class-File API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20102 From mcimadamore at openjdk.org Mon Jul 15 12:17:51 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 12:17:51 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 12:10:02 GMT, Maurizio Cimadamore wrote: > I also tried using `MethodHandles::arrayElementGetter` for the access, but the numbers I got were pretty much the same: This is quite strange, as the code involved should be quite similar to those with memory segments (e.g. you go through a method handle pointing to some helper class). I would have said this would have provided a fairly good comparison. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228359381 From mcimadamore at openjdk.org Mon Jul 15 12:17:52 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 12:17:52 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 12:13:23 GMT, Maurizio Cimadamore wrote: > > I also tried using `MethodHandles::arrayElementGetter` for the access, but the numbers I got were pretty much the same: > > This is quite strange, as the code involved should be quite similar to those with memory segments (e.g. you go through a method handle pointing to some helper class). I would have said this would have provided a fairly good comparison. Ah! I had `arrayElementVarHandle` in mind - maybe you can try that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228361950 From liach at openjdk.org Mon Jul 15 12:31:53 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 12:31:53 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 01:45:57 GMT, Chen Liang wrote: > The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. Indeed, for some reason I thought the range of short is -256 to 255 instead of -65536 to 65535 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2228389586 From jvernee at openjdk.org Mon Jul 15 12:36:53 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 12:36:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > improve benchmark This is the baseline if I change `closing` to use a confined arena: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 8.089 ? 0.006 us/op ConcurrentClose.sharedClose:closing avgt 10 0.001 ? 0.001 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 20.046 ? 0.019 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 4.220 ? 0.002 us/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228401517 From jvernee at openjdk.org Mon Jul 15 12:49:56 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 12:49:56 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 12:14:52 GMT, Maurizio Cimadamore wrote: > Ah! I had `arrayElementVarHandle` in mind - maybe you can try that? Even with `arrayElementVarHandle` it's about the same ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228425705 From mcimadamore at openjdk.org Mon Jul 15 13:01:52 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:01:52 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: <_PDgnriMr5GoRUoTpxJnhZjIqEcjdF2kscNx94ScPlc=.b035d8ac-e218-46ed-86d9-a08368c63dc5@github.com> On Mon, 15 Jul 2024 12:34:37 GMT, Jorn Vernee wrote: > This is the baseline if I change `closing` to use a confined arena: > > ``` > Benchmark Mode Cnt Score Error Units > ConcurrentClose.sharedClose avgt 10 8.089 ? 0.006 us/op > ConcurrentClose.sharedClose:closing avgt 10 0.001 ? 0.001 us/op > ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 20.046 ? 0.019 us/op > ConcurrentClose.sharedClose:otherAccess avgt 10 4.220 ? 0.002 us/op > ``` This is promising. Effectively, once all the issues surrounding reachability fences will be addressed, we should be able to achieve numbers similar to above even in the case of shared close. The only thing being slower in that case would be the closing thread itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228448722 From mcimadamore at openjdk.org Mon Jul 15 13:11:52 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:11:52 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> On Mon, 15 Jul 2024 12:47:30 GMT, Jorn Vernee wrote: > Even with `arrayElementVarHandle` it's about the same This is very odd, and I don't have a good explanation as to why that is the case. What does the baseline (confined arena) look like for `arrayElementVarHandle` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228469162 From jpai at openjdk.org Mon Jul 15 13:14:56 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 13:14:56 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: <5XLyS-nRJakdnvUky0vcEQnzIqz9O9SE-ZDhEePqGXY=.6e047b48-999d-4eca-b1cb-ed1f88d57b2c@github.com> References: <5XLyS-nRJakdnvUky0vcEQnzIqz9O9SE-ZDhEePqGXY=.6e047b48-999d-4eca-b1cb-ed1f88d57b2c@github.com> Message-ID: On Mon, 15 Jul 2024 10:06:20 GMT, Jaikiran Pai wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Bump @since from 23 to 24. >> - Merge branch 'master' into JDK-8322256 >> - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. >> - Simplify code by eliminating an impossible case. >> - Field name change and Javadoc wording tweaks. >> - Merge branch 'master' into JDK-8322256 >> - Javadoc wording tweaks. >> - Merge branch 'master' into JDK-8322256 >> - Clarify exceptions: sometimes ZipException, sometimes EOFException. >> - Merge branch 'master' into JDK-8322256 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/75dc2f85...f845a75b > > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 153: > >> 151: */ >> 152: public GZIPInputStream(InputStream in, int size, >> 153: boolean allowConcatenation, boolean ignoreExtraBytes) throws IOException { > > I haven't reviewed the javadoc changes. I will do that separately once we settle down on the API and implementation changes. > As for this new constructor, I think the only new parameter we should introduce is whether or not the underlying input stream `in` is expected/allowed to have concatenated GZIP stream(s). So I think we should remove the "ignoreExtraBytes" new parameters from this constructor and. Additionally, I think the `allowConcatenation` should instead be named `allowConcatenatedGZIPStream`: > > > public GZIPInputStream(InputStream in, int size, boolean allowConcatenatedGZIPStream) throws IOException { Just to provide a more concrete input, here's a very minimal tested version of what I had in mind: --- a/src/java.base/share/classes/java/util/zip/GZIPInputStream.java +++ b/src/java.base/share/classes/java/util/zip/GZIPInputStream.java @@ -55,6 +55,8 @@ public class GZIPInputStream extends InflaterInputStream { private boolean closed = false; + private final boolean allowConcatenatedGZIPStream; + /** * Check to make sure that this stream has not been closed */ @@ -76,14 +78,7 @@ private void ensureOpen() throws IOException { * @throws IllegalArgumentException if {@code size <= 0} */ public GZIPInputStream(InputStream in, int size) throws IOException { - super(in, createInflater(in, size), size); - usesDefaultInflater = true; - try { - readHeader(in); - } catch (IOException ioe) { - this.inf.end(); - throw ioe; - } + this(in, size, true); } /* @@ -111,7 +106,28 @@ private static Inflater createInflater(InputStream in, int size) { * @throws IOException if an I/O error has occurred */ public GZIPInputStream(InputStream in) throws IOException { - this(in, 512); + this(in, 512, true); + } + + /** + * WIP + * @param in the input stream + * @param size the input buffer size + * @param allowConcatenatedGZIPStream true if the input stream is allowed to contain + * concatenated GZIP streams. false otherwise + * @throws IOException if an I/O error has occurred + */ + public GZIPInputStream(InputStream in, int size, boolean allowConcatenatedGZIPStream) + throws IOException { + super(in, createInflater(in, size), size); + this.allowConcatenatedGZIPStream = allowConcatenatedGZIPStream; + usesDefaultInflater = true; + try { + readHeader(in); + } catch (IOException ioe) { + this.inf.end(); + throw ioe; + } } /** @@ -150,10 +166,45 @@ public int read(byte[] buf, int off, int len) throws IOException { } int n = super.read(buf, off, len); if (n == -1) { - if (readTrailer()) + // reading of deflated data is now complete, we now read the GZIP stream trailer + readTrailer(); + if (!allowConcatenatedGZIPStream) { eos = true; - else + } else { + // This GZIPInputStream instance was created to allow potential + // concatenated GZIP stream, so we now try and read the next + // GZIP stream header, if any. + + // use any un-inflated remaining bytes from the stream + InputStream headerIS = in; + int remainingUnInflated = inf.getRemaining(); + if (remainingUnInflated > 0) { + headerIS = new SequenceInputStream( + new ByteArrayInputStream(this.buf, this.len - remainingUnInflated, + remainingUnInflated), + new FilterInputStream(in) { + public void close() throws IOException {} + }); + } + int numHeaderBytes; + try { + numHeaderBytes = readHeader(headerIS); // next GZIP stream header, if any + } catch (EOFException _) { + // TODO: somehow verify that this failed when reading the + // first byte of the header? + eos = true; + return n; // -1 + } + // reset the inflater to read the deflated content of the next GZIP stream + inf.reset(); + // adjust the input to the inflater correctly past the GZIP stream header + if (remainingUnInflated > numHeaderBytes) { + inf.setInput(this.buf, this.len - remainingUnInflated + numHeaderBytes, + remainingUnInflated - numHeaderBytes); + } + // read the next GZIP stream's deflated data return this.read(buf, off, len); + } } else { crc.update(buf, off, n); } @@ -242,12 +293,12 @@ private int readHeader(InputStream this_in) throws IOException { * reached, false if there are more (concatenated gzip * data set) */ - private boolean readTrailer() throws IOException { + private void readTrailer() throws IOException { InputStream in = this.in; - int n = inf.getRemaining(); - if (n > 0) { + int remainingUnInflated = inf.getRemaining(); + if (remainingUnInflated > 0) { in = new SequenceInputStream( - new ByteArrayInputStream(buf, len - n, n), + new ByteArrayInputStream(buf, len - remainingUnInflated, remainingUnInflated), new FilterInputStream(in) { public void close() throws IOException {} }); @@ -255,20 +306,15 @@ public void close() throws IOException {} // Uses left-to-right evaluation order if ((readUInt(in) != crc.getValue()) || // rfc1952; ISIZE is the input size modulo 2^32 - (readUInt(in) != (inf.getBytesWritten() & 0xffffffffL))) + (readUInt(in) != (inf.getBytesWritten() & 0xffffffffL))) { throw new ZipException("Corrupt GZIP trailer"); - - // try concatenated case - int m = 8; // this.trailer - try { - m += readHeader(in); // next.header - } catch (IOException ze) { - return true; // ignore any malformed, do nothing } + int numTrailerBytes = 8; inf.reset(); - if (n > m) - inf.setInput(buf, len - n + m, n - m); - return false; + if (remainingUnInflated > numTrailerBytes) { + inf.setInput(buf, len - remainingUnInflated + numTrailerBytes, + remainingUnInflated - numTrailerBytes); + } } /* It still has one or two unanswered questions that I haven't fully thought of, but I thought this diff might be useful while discussing these changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1677807848 From mcimadamore at openjdk.org Mon Jul 15 13:24:20 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:24:20 GMT Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v9] In-Reply-To: References: Message-ID: > This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. > > Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. Maurizio Cimadamore 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 12 additional commits since the last revision: - Merge branch 'master' into restricted_jni - Address review comments - Add note on --illegal-native-access default value in the launcher help - Address review comment - Refine warning text for JNI method binding - Address review comments Improve warning for JNI methods, similar to what's described in JEP 472 Beef up tests - Address review comments - Fix another typo - Fix typo - Add more comments - ... and 2 more: https://git.openjdk.org/jdk/compare/2ced23fe...ff51ac6a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19213/files - new: https://git.openjdk.org/jdk/pull/19213/files/789bdf48..ff51ac6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=07-08 Stats: 168976 lines in 3271 files changed: 114666 ins; 38249 del; 16061 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213 From mcimadamore at openjdk.org Mon Jul 15 13:24:20 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:24:20 GMT Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8] In-Reply-To: References: Message-ID: <1f6cPvfYhyTzqeYoeA6uQi2WULB_Bq49AhF_RoEVWDQ=.9577a65e-b626-43fd-ab03-09783b978d94@github.com> On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. >> >> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2228489298 From duke at openjdk.org Mon Jul 15 13:28:54 2024 From: duke at openjdk.org (ExE Boss) Date: Mon, 15 Jul 2024 13:28:54 GMT Subject: RFR: 8334714: Class-File API leaves preview In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona wrote: > Class-File API is leaving preview. > This is a removal of all `@PreviewFeature` annotations from Class-File API. > It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. > > Please review. > > Thanks, > Adam Note?that `Utf8Entry::equalsString` has?inconsistent behaviour when?called with?a?`null`?value, which?I?ve?reported as?[JI?9077307], and?should probably be?fixed before this?API leaves?preview. [JI?9077307]: https://bugs.openjdk.org/browse/JI-9077307 "JI?9077307: Inconsistent?NPE?behaviour of?`Utf8Entry::equalsString`" ------------- PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2228504207 From shade at openjdk.org Mon Jul 15 13:42:51 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Jul 2024 13:42:51 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 12:28:51 GMT, Chen Liang wrote: > Indeed, for some reason I thought the range of short is -256 to 255 instead of -65536 to 65535 Yeah, I thought something like this was going on; it would be a smart way to leverage that negative side in two-complement form is one value larger. But, `byte` is `-128...127`, and `short` is `-32768..32767`. So current thing would not even work if it did not support `256` as the value :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2228531319 From jvernee at openjdk.org Mon Jul 15 13:52:53 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 13:52:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> References: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> Message-ID: <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> On Mon, 15 Jul 2024 13:09:21 GMT, Maurizio Cimadamore wrote: > > Even with `arrayElementVarHandle` it's about the same > > This is very odd, and I don't have a good explanation as to why that is the case. What does the baseline (confined arena) look like for `arrayElementVarHandle` ? Pretty much exactly the same ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228555214 From shade at openjdk.org Mon Jul 15 13:53:55 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Jul 2024 13:53:55 GMT Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4] In-Reply-To: References: Message-ID: <6khJcAuYMB20n-qZpLj9McxbTvPCmo1vsMat7OoOEsU=.71980287-1048-4574-95a7-6ab2745f30c8@github.com> On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote: >> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless cloning of Object[0] instances. This cloning is intended to prevent callers from changing array contents, but many `CopyOnWriteArrayList`s are allocated to size zero, or are otherwise maintained empty, so cloning is unnecessary. >> >> Results from the included JMH benchmark: >> Before: >> >> Benchmark Mode Cnt Score Error Units >> CopyOnWriteArrayListBenchmark.clear avgt 5 74.487 ? 1.793 ns/op >> CopyOnWriteArrayListBenchmark.clearEmpty avgt 5 27.918 ? 0.759 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceArray avgt 5 16.656 ? 0.375 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty avgt 5 15.415 ? 0.489 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceCollection avgt 5 21.608 ? 0.363 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty avgt 5 15.374 ? 0.260 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceDefault avgt 5 15.688 ? 0.350 ns/op >> CopyOnWriteArrayListBenchmark.readInstance avgt 10 2625.125 ? 71.802 ns/op >> CopyOnWriteArrayListBenchmark.readInstanceEmpty avgt 10 2607.447 ? 46.400 ns/op >> >> >> After: >> >> Benchmark Mode Cnt Score Error Units >> CopyOnWriteArrayListBenchmark.clear avgt 5 75.365 ? 2.092 ns/op >> CopyOnWriteArrayListBenchmark.clearEmpty avgt 5 20.803 ? 0.539 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceArray avgt 5 16.808 ? 0.582 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceArrayEmpty avgt 5 12.980 ? 0.418 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceCollection avgt 5 21.627 ? 0.173 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceCollectionEmpty avgt 5 12.864 ? 0.408 ns/op >> CopyOnWriteArrayListBenchmark.createInstanceDefault avgt 5 12.931 ? 0.255 ns/op >> CopyOnWriteArrayListBenchmark.readInstance avgt 10 2615.500 ? 30.771 ns/op >> CopyOnWriteArrayListBenchmark.readInstanceEmpty avgt 10 2583.892 ? 62.086 ns/op > > jengebr has updated the pull request incrementally with one additional commit since the last revision: > > Expanding coverage of remove() Still good. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19527#pullrequestreview-2177783717 From mcimadamore at openjdk.org Mon Jul 15 14:04:52 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 14:04:52 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> References: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> Message-ID: On Mon, 15 Jul 2024 13:49:57 GMT, Jorn Vernee wrote: > > > Even with `arrayElementVarHandle` it's about the same > > > > > > This is very odd, and I don't have a good explanation as to why that is the case. What does the baseline (confined arena) look like for `arrayElementVarHandle` ? > > Pretty much exactly the same So, that means that `arrayElementVarHandle` is ~4x faster than memory segment? Isn't that a bit odd? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228582926 From liach at openjdk.org Mon Jul 15 14:09:22 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 14:09:22 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2] In-Reply-To: References: Message-ID: > The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: We have sufficient space in short, use +1 offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20178/files - new: https://git.openjdk.org/jdk/pull/20178/files/7d111ba3..0743c5f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20178/head:pull/20178 PR: https://git.openjdk.org/jdk/pull/20178 From jpai at openjdk.org Mon Jul 15 14:28:37 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 14:28:37 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory [v8] In-Reply-To: References: Message-ID: > Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? > > The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. > > As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. > > The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). > > The commit also includes a jtreg testcase which verifies the usage of this new option. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - merge latest from master branch - merge latest from master branch - merge latest from master branch - cleanup testExtractNoDestDirWithPFlag() test - merge latest from master branch - merge latest from master branch - convert the new test to junit - merge latest from master branch - Lance's review - include tests for --extract long form option - cleanup after each test - ... and 8 more: https://git.openjdk.org/jdk/compare/a253e0ff...ece49f9f ------------- Changes: https://git.openjdk.org/jdk/pull/2752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=07 Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752 PR: https://git.openjdk.org/jdk/pull/2752 From duke at openjdk.org Mon Jul 15 14:28:55 2024 From: duke at openjdk.org (jengebr) Date: Mon, 15 Jul 2024 14:28:55 GMT Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 12:52:46 GMT, Alan Bateman wrote: >> @AlanBateman -- could you please take a look? Thanks. > >> @AlanBateman -- could you please take a look? Thanks. > > There was a lot of heap analysis done a few years ago that shined a light on the number of empty collections in a typical heap. I don't recall seeing COWAL in any of the data but it seems plausible that there are cases where there are a lot of empty COWAL instances in the heap. > > Main thing for a change like this to make sure it doesn't hurt other cases and check if there are overridable methods used in the existing + updated implementations that might get reported as a behavior change by something that extends and overrides some methods. I don't see anything so I think it's okay. > > One thing that surprises me is the change to remove(Object) to handle the case where the last remaining element is removed. Does that help the application that prompted this change? Part of me wonders if remove(int) needs to do the same as someone will show up sometime to ask. @AlanBateman can you please confirm remove() is updated as intended, and approve if ready? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19527#issuecomment-2228637385 From liach at openjdk.org Mon Jul 15 15:02:52 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:02:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2] In-Reply-To: References: Message-ID: <6Xq5LGI0ly3mNHYIkYT4zNYugEv_2ILfMKMoSxtMeXo=.c18136c6-cfee-4abf-b403-6d23254efd2f@github.com> On Mon, 15 Jul 2024 14:09:22 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > We have sufficient space in short, use +1 offset Now I have switched to +1 offset. Looks cleaner? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2228713539 From uschindler at openjdk.org Mon Jul 15 15:08:54 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 15:08:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > improve benchmark Thins looks all promising! Together with making sure that Apache Solr and Elasticsearch/Opensearch close indexes one-by-one in a separate thread (with the PR https://github.com/apache/lucene/pull/13570 in place, too), the issues should be fixed. What is the issue with memory fences? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228726262 From liach at openjdk.org Mon Jul 15 15:16:23 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:16:23 GMT Subject: RFR: 8335938: Review XxxBuilder.original and XxxModel.parent [v2] In-Reply-To: References: Message-ID: > Remove unused `Class/Field/Method/CodeBuilder.original()`, and make `Field/Method/CodeModel.parent()` return present only if it's bound (i.e. not buffered transformed). See the CSR for details. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/builder-original - 8335938: Review XxxBuilder.original and XxxModel.parent ------------- Changes: https://git.openjdk.org/jdk/pull/20177/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20177&range=01 Stats: 93 lines in 12 files changed: 1 ins; 81 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20177/head:pull/20177 PR: https://git.openjdk.org/jdk/pull/20177 From jvernee at openjdk.org Mon Jul 15 15:24:54 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 15:24:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 11:29:49 GMT, R?mi Forax wrote: > > This is what I was thinking of as well. close() on a shared arena can be called by any thread, so it would be possible to have an executor service with 1-n threads that is dedicated to closing memory. > > This delays both the closing of the Arena and the freeing of the segments, so bugs may be not discovered if the arena is accessed in between the time the thread pool is notified and the time the close() is effectively called. Closing the arena is what requires the handshake, which is where the majority of the cost is. I don't see the point in closing synchronously, but then freeing the memory asynchronously, since the latter is relatively cheap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228756598 From uschindler at openjdk.org Mon Jul 15 15:24:54 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 15:24:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2] In-Reply-To: References: <0j4dLtE61HH3gE0ptR-LufJuIOvKFgLJbSDAeXY3Ii4=.ced967f1-bbd1-4add-8484-88a84aabb5f3@github.com> Message-ID: On Mon, 15 Jul 2024 15:18:20 GMT, Jorn Vernee wrote: > > > This is what I was thinking of as well. close() on a shared arena can be called by any thread, so it would be possible to have an executor service with 1-n threads that is dedicated to closing memory. > > > > > > This delays both the closing of the Arena and the freeing of the segments, so bugs may be not discovered if the arena is accessed in between the time the thread pool is notified and the time the close() is effectively called. > > Closing the arena is what requires the handshake, which is where the majority of the cost is. I don't see the point in closing synchronously, but then freeing the memory asynchronously, since the latter is relatively cheap. I think the idea is to trigger the handshake async and then close after the handshake (in a callback when hadshake finishs). This is only a problem if you for example want to delete a mmapped file on Windows. This won't work as long as the memory is mmapped, but in all other cases. So there should be the option to allow async close() [if client supports it], but the defaulkt should be synchronized. I think this is what @forax suggested. But anyways: Using a separate extra thread is a good idea. I proposed this for Apache Solr and Elasticsearch people are checking their code at moment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228760782 From syan at openjdk.org Mon Jul 15 15:31:56 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Jul 2024 15:31:56 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > make variable TOOL_VM_OPTIONS to private Does this PR need 2rd reviewer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2228780859 From shade at openjdk.org Mon Jul 15 15:32:52 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Jul 2024 15:32:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 14:09:22 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > We have sufficient space in short, use +1 offset Looks reasonable to me, with nits. src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1400: > 1398: if (offsetIndex != i + 1) { > 1399: if (offsetIndex != 0) return false; > 1400: offsetIndex = (short) (i + 1); Can we pull `(short) (i + 1);` into a local variable, given that we need it on all paths? src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 778: > 776: var newParameters = new TreeMap(new Comparator<>() { > 777: public int compare(Name n1, Name n2) { > 778: return n1.index() - n2.index(); We don't have to call the method here and do the translation to "proper" index here, or do we? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20178#pullrequestreview-2177881698 PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1677980731 PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1677926814 From prappo at openjdk.org Mon Jul 15 15:43:57 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 15 Jul 2024 15:43:57 GMT Subject: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and erroneous links in the doc files. Marked as reviewed by prappo (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20166#pullrequestreview-2178067600 From liach at openjdk.org Mon Jul 15 15:43:57 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:43:57 GMT Subject: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: <-eepL8P7oP0ACH4HDom_tnyjqcdy8MBfh9UrghsuXQM=.1f46a7a7-6fd2-4ce1-8a6a-a9cb33e8cec3@github.com> On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and erroneous links in the doc files. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20166#issuecomment-2228806864 From liach at openjdk.org Mon Jul 15 15:43:58 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:43:58 GMT Subject: [jdk23] Integrated: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and erroneous links in the doc files. This pull request has now been integrated. Changeset: 908d1e92 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/908d1e92fcc4a23a6634ab2c20109df83238110b Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod 8336259: Wrong link to stylesheet.css in JavaDoc API documentation Reviewed-by: iris, prappo Backport-of: 5bc86f332986e3fffc1363f569029bb73a706064 ------------- PR: https://git.openjdk.org/jdk/pull/20166 From liach at openjdk.org Mon Jul 15 15:50:51 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:50:51 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 14:29:29 GMT, Aleksey Shipilev wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> We have sufficient space in short, use +1 offset > > src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 778: > >> 776: var newParameters = new TreeMap(new Comparator<>() { >> 777: public int compare(Name n1, Name n2) { >> 778: return n1.index() - n2.index(); > > We don't have to call the method here and do the translation to "proper" index here, or do we? Using `n1.offsetIndex - n2.offsetIndex` feels weird in an encapsulation POV. I will mark `offsetIndex` private to better indicate this being an implementation detail not to be relied on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1678050485 From syan at openjdk.org Mon Jul 15 15:54:52 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Jul 2024 15:54:52 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 07:04:33 GMT, Jaikiran Pai wrote: > What you propose in this PR looks fine to me and matches some other tests which do a similar thing. Maybe we should do the same thing in some other tests in this directory, to keep them consistent. For now though, I think what you have here is fine and I don't expect you to update these other places. I have created a jbs issue [JDK-8336405](https://bugs.openjdk.org/browse/JDK-8336405) to record this task. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2228836814 From liach at openjdk.org Mon Jul 15 15:57:30 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:57:30 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3] In-Reply-To: References: Message-ID: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> > The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Encapsulate offsetIndex, share computation result ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20178/files - new: https://git.openjdk.org/jdk/pull/20178/files/0743c5f9..db805834 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20178/head:pull/20178 PR: https://git.openjdk.org/jdk/pull/20178 From jpai at openjdk.org Mon Jul 15 16:05:52 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 16:05:52 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 15:29:03 GMT, SendaoYan wrote: > Does this PR need 2rd reviewer. core-libs area doesn't mandate 2 reviews. The current PR is a test infrastructure change and doesn't impact the functionality of the test. The change has been tested in our CI and appears to work fine without introducing any regressions. Plus the PR has been open for more than 24 hours. So I think it is OK to issue a "integrate" whenever you are ready. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2228859627 From shade at openjdk.org Mon Jul 15 16:12:52 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Jul 2024 16:12:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3] In-Reply-To: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> References: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> Message-ID: On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Encapsulate offsetIndex, share computation result Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20178#pullrequestreview-2178142525 From shade at openjdk.org Mon Jul 15 16:12:52 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Jul 2024 16:12:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 15:47:50 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 778: >> >>> 776: var newParameters = new TreeMap(new Comparator<>() { >>> 777: public int compare(Name n1, Name n2) { >>> 778: return n1.index() - n2.index(); >> >> We don't have to call the method here and do the translation to "proper" index here, or do we? > > Using `n1.offsetIndex - n2.offsetIndex` feels weird in an encapsulation POV. I will mark `offsetIndex` private to better indicate this being an implementation detail not to be relied on. All right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1678078244 From jvernee at openjdk.org Mon Jul 15 16:22:52 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 15 Jul 2024 16:22:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3] In-Reply-To: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> References: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> Message-ID: On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Encapsulate offsetIndex, share computation result The changes look good to me, but I wonder if we ever actually benefit from these fields being stable, since we always skip LF interpretation in practice. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20178#pullrequestreview-2178164865 From alanb at openjdk.org Mon Jul 15 16:28:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 16:28:07 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates Message-ID: Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. Implementation: - Robustness improvements to not throw OOME when unparking a virtual thread. - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) - VirtualThread changes to reduce contention on timer queues when doing timed-park Tests: - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java - New test for ThreadMXBean.getLockedMonitor with synchronized native methods - Reimplement of JVMTI VThreadEvent test to improve reliability - Rename some tests to get consistent naming - Diagnostic output in several stress tests to help trace progress in the event of a timeout Testing: tier1-6 ------------- Commit messages: - Drop JLA updates for this update - Merge - Merge - Update copyright headers - Initial commit Changes: https://git.openjdk.org/jdk/pull/20143/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20143&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336254 Stats: 4116 lines in 42 files changed: 2528 ins; 1150 del; 438 mod Patch: https://git.openjdk.org/jdk/pull/20143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20143/head:pull/20143 PR: https://git.openjdk.org/jdk/pull/20143 From mcimadamore at openjdk.org Mon Jul 15 16:34:00 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 16:34:00 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> Message-ID: On Mon, 15 Jul 2024 14:02:27 GMT, Maurizio Cimadamore wrote: > So, that means that `arrayElementVarHandle` is ~4x faster than memory segment? Isn't that a bit odd? I did some more analyis of the benchmark. I first eliminated the closing thread, and started with two simple benchmarks: @Benchmark public int memorySegmentAccess() { int sum = 0; for (int i = 0; i < segment.byteSize(); i++) { sum += segment.get(JAVA_BYTE, i); } return sum; } and @Benchmark public int otherAccess() { int sum = 0; for (int i = 0; i < array.length; i++) { sum += (byte)BYTE_HANDLE.get(array, i); } return sum; } where the setup code is as follows: static final int SIZE = 10_000; MemorySegment segment; byte[] array; static final VarHandle BYTE_HANDLE = MethodHandles.arrayElementVarHandle(byte[].class); @Setup public void setup() { array = new byte[SIZE]; segment = MemorySegment.ofArray(array); } With this, I obtained the following results: Benchmark Mode Cnt Score Error Units ConcurrentClose.memorySegmentAccess avgt 10 13.879 ? 0.478 us/op ConcurrentClose.otherAccess avgt 10 2.256 ? 0.017 us/op Ugh. It seems like C2 "blows up" at the third iteration: # Run progress: 0.00% complete, ETA 00:05:00 # Fork: 1 of 1 # Warmup Iteration 1: 6.712 us/op # Warmup Iteration 2: 5.756 us/op # Warmup Iteration 3: 13.267 us/op # Warmup Iteration 4: 13.267 us/op # Warmup Iteration 5: 13.274 us/op This might be a bug/regression. But, let's move on. I then tweaked the induction variable of the memory segment loop to be `long`, not `int` and I got: Benchmark Mode Cnt Score Error Units ConcurrentClose.memorySegmentAccess avgt 10 2.764 ? 0.016 us/op ConcurrentClose.otherAccess avgt 10 2.240 ? 0.016 us/op Far more respectable! And now we have a good baseline, since both workloads take amount the same time, so we can use them to draw interesting comparisons. So, let's add back a thread that does a shared arena close: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 12.001 ? 0.061 us/op ConcurrentClose.sharedClose:closing avgt 10 19.281 ? 0.323 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 9.802 ? 0.314 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 6.921 ? 0.151 us/op This is with vanilla JDK. If I apply the changes in this PR, I get this: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 10.837 ? 0.241 us/op ConcurrentClose.sharedClose:closing avgt 10 20.337 ? 1.674 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 8.672 ? 0.993 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 3.501 ? 0.162 us/op This is good. Note how `otherAccess` improved almost 2x, as the code is no longer redundantly de-optimized. Now, we know that, even for memory segment access, we can avoid redundant deopt once JDK-8290892 is fixed. To simulate that, I've dropped the lines which apply the conservative deoptimization in `scopedMemoryAccess.cpp` and ran the bench again: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 8.957 ? 0.089 us/op ConcurrentClose.sharedClose:closing avgt 10 18.898 ? 0.338 us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 4.403 ? 0.054 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 3.571 ? 0.042 us/op Ok, now both accessor threads seem faster. If I swap the shared arena close with a confined arena close I get this: Benchmark Mode Cnt Score Error Units ConcurrentClose.sharedClose avgt 10 1.760 ? 0.008 us/op ConcurrentClose.sharedClose:closing avgt 10 ? 10?? us/op ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 2.912 ? 0.016 us/op ConcurrentClose.sharedClose:otherAccess avgt 10 2.367 ? 0.009 us/op Summing up: * there is some issue involving segment access with `int` induction variable which we should investigate separately * this PR significantly improves performance of threads that are not touching memory segments, even under heavy shared arena close loads * performance of unrelated memory segment access is still affected by concurrent shared arena close. This is due to conservative deoptimization which will be removed once JDK-8290892 is fixed * when all fixes will be applied, the performance of the accessing threads gets quite close to ideal, but not 100% there. The loss seems in the acceptable range - given that this benchmark is closing shared arenas in a loop, arguably the worst possible case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228916752 From alanb at openjdk.org Mon Jul 15 16:35:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 16:35:55 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote: > We cannot pass GNU style options like --enable-preview to jlink --add-option. It is hard to use for complex application. JDK-8303884 was created to track a much larger re-examination of the jlink option parameter. I think the issue will need more thought before deciding whether to put in a short term fix as proposed here (the main concern is the side effect on plugins). ------------- PR Comment: https://git.openjdk.org/jdk/pull/19987#issuecomment-2228922268 From kbarrett at openjdk.org Mon Jul 15 16:36:57 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 Jul 2024 16:36:57 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 05:34:24 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > USe os::snprintf in HotSpot Changes requested by kbarrett (Reviewer). src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: > 30: #include /* for _MAx_PATH */ > 31: > 32: typedef unsigned long long UNSIGNED_JLONG; This change has nothing to do with _sprintf. Not sure why it's being made here. src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 54: > 52: > 53: typedef unsigned int juint; > 54: typedef unsigned long long julong; Similarly, his change has nothing to do with _sprintf. ------------- PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2178184310 PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1678105753 PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1678106243 From uschindler at openjdk.org Mon Jul 15 16:37:53 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 16:37:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> Message-ID: On Mon, 15 Jul 2024 16:30:11 GMT, Maurizio Cimadamore wrote: >>> > > Even with `arrayElementVarHandle` it's about the same >>> > >>> > >>> > This is very odd, and I don't have a good explanation as to why that is the case. What does the baseline (confined arena) look like for `arrayElementVarHandle` ? >>> >>> Pretty much exactly the same >> >> So, that means that `arrayElementVarHandle` is ~4x faster than memory segment? Isn't that a bit odd? > >> So, that means that `arrayElementVarHandle` is ~4x faster than memory segment? Isn't that a bit odd? > > I did some more analyis of the benchmark. I first eliminated the closing thread, and started with two simple benchmarks: > > > @Benchmark > public int memorySegmentAccess() { > int sum = 0; > for (int i = 0; i < segment.byteSize(); i++) { > sum += segment.get(JAVA_BYTE, i); > } > return sum; > } > > > and > > > @Benchmark > public int otherAccess() { > int sum = 0; > for (int i = 0; i < array.length; i++) { > sum += (byte)BYTE_HANDLE.get(array, i); > } > return sum; > } > > > where the setup code is as follows: > > > static final int SIZE = 10_000; > > MemorySegment segment; > byte[] array; > > static final VarHandle BYTE_HANDLE = MethodHandles.arrayElementVarHandle(byte[].class); > > @Setup > public void setup() { > array = new byte[SIZE]; > segment = MemorySegment.ofArray(array); > } > > > With this, I obtained the following results: > > > Benchmark Mode Cnt Score Error Units > ConcurrentClose.memorySegmentAccess avgt 10 13.879 ? 0.478 us/op > ConcurrentClose.otherAccess avgt 10 2.256 ? 0.017 us/op > > > Ugh. It seems like C2 "blows up" at the third iteration: > > > # Run progress: 0.00% complete, ETA 00:05:00 > # Fork: 1 of 1 > # Warmup Iteration 1: 6.712 us/op > # Warmup Iteration 2: 5.756 us/op > # Warmup Iteration 3: 13.267 us/op > # Warmup Iteration 4: 13.267 us/op > # Warmup Iteration 5: 13.274 us/op > > > This might be a bug/regression. But, let's move on. I then tweaked the induction variable of the memory segment loop to be `long`, not `int` and I got: > > > Benchmark Mode Cnt Score Error Units > ConcurrentClose.memorySegmentAccess avgt 10 2.764 ? 0.016 us/op > ConcurrentClose.otherAccess avgt 10 2.240 ? 0.016 us/op > > > Far more respectable! And now we have a good baseline, since both workloads take amount the same time, so we can use them to draw interesting comparisons. So, let's add back a thread that does a shared arena close: > > > Benchmark Mode Cnt Score Error Units > ConcurrentClose.sharedClose avgt 10 12.001 ? 0.061 us/op > ConcurrentClose.sharedClose:closing avgt 10 19.281 ? 0.323 us/op > ConcurrentClose.sharedClose:memorySegmentAccess avgt 10 9.802 ? 0.314 us/op > ConcurrentClose.sharedClose:otherAccess avgt 1... Thanks @mcimadamore, this sound great! I am so happy that we at least reduced the overhead for non-memory segment threads. This will also be the case for Lucene/Solr because we do not read from segments all the time, we also have other code sometimes executed between reads from memory segments :-) So +1 to merge this and hopefully backport it at least to 21? This would be great, but as it is not a bug not strictly necessary. We should open issues for the int problem and work on JDK-8290892. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228926251 From liach at openjdk.org Mon Jul 15 16:43:51 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 16:43:51 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3] In-Reply-To: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> References: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> Message-ID: On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Encapsulate offsetIndex, share computation result Hmm, I don't think index is that closely tied to LF interpretation; it's only used to find the output values from a `Name`. After another more general look, I think we might just turn the `index` field final: all its other fields are already final, and the lazy setting of `index` is just a trivial attempt to avoid reallocation if the index is not initialized, and such an approach will actually be harmful once we have value objects from valhalla. Should I make it `final` instead, so we can prepare `Name` for the Valhalla value class migration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2228942425 From mcimadamore at openjdk.org Mon Jul 15 16:44:54 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 16:44:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> Message-ID: On Mon, 15 Jul 2024 16:35:26 GMT, Uwe Schindler wrote: > So +1 to merge this and hopefully backport it at least to 21? Backport to 21 is difficult, given the handshake code there is different (and, FFM is preview there). But, might be more possible for 22. I have notified Roland re. the `int` problem, will update once I know more about the nature of this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228939812 From uschindler at openjdk.org Mon Jul 15 16:44:56 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 15 Jul 2024 16:44:56 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> Message-ID: <1lPwGcVzUtreIzS-ieJpTrtRyHM9PElbHN31NqFCDNI=.c44ff158-4c82-4dc3-9166-01393330db40@github.com> On Mon, 15 Jul 2024 16:40:06 GMT, Maurizio Cimadamore wrote: > > So +1 to merge this and hopefully backport it at least to 21? > > Backport to 21 is difficult, given the handshake code there is different (and, FFM is preview there). But, might be more possible for 22. I have notified Roland re. the `int` problem, will update once I know more about the nature of this issue. Ah I remember: the tristate! All fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228943554 From forax at openjdk.org Mon Jul 15 17:02:55 2024 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 15 Jul 2024 17:02:55 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > improve benchmark Even if the int vs long issue is fixed for this case, i think we should recommand to call `withInvokeExactBehavior()` after creating any VarHandle so all the auto-conversions are treated as runtime errors. This is what i do with my students (when using compareAndSet) and it makes this kind of perf issue easy to find and easy to fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228979913 From mcimadamore at openjdk.org Mon Jul 15 17:09:53 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 17:09:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: Message-ID: <0a3-qVymtC5HI4wh8FQiNeebnG_-8Ax1seA80JhCQLY=.c24d9e87-b34f-45c7-aa7c-e63e294249d4@github.com> On Mon, 15 Jul 2024 17:00:24 GMT, R?mi Forax wrote: > Even if the int vs long issue is fixed for this case, i think we should recommand to call `withInvokeExactBehavior()` after creating any VarHandle so all the auto-conversions are treated as runtime errors. > > This is what i do with my students (when using compareAndSet) and it makes this kind of perf issue easy to find and easy to fix. Note that this has nothing to do with implicit conversion, as the memory segment var handle is called by our implementation, with the correct type (a long). This is likely an issue with bound check elimination with "long loops". ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228992252 From acobbs at openjdk.org Mon Jul 15 18:09:52 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 15 Jul 2024 18:09:52 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: <5XLyS-nRJakdnvUky0vcEQnzIqz9O9SE-ZDhEePqGXY=.6e047b48-999d-4eca-b1cb-ed1f88d57b2c@github.com> Message-ID: On Mon, 15 Jul 2024 13:12:41 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 153: >> >>> 151: */ >>> 152: public GZIPInputStream(InputStream in, int size, >>> 153: boolean allowConcatenation, boolean ignoreExtraBytes) throws IOException { >> >> I haven't reviewed the javadoc changes. I will do that separately once we settle down on the API and implementation changes. >> As for this new constructor, I think the only new parameter we should introduce is whether or not the underlying input stream `in` is expected/allowed to have concatenated GZIP stream(s). So I think we should remove the "ignoreExtraBytes" new parameters from this constructor and. Additionally, I think the `allowConcatenation` should instead be named `allowConcatenatedGZIPStream`: >> >> >> public GZIPInputStream(InputStream in, int size, boolean allowConcatenatedGZIPStream) throws IOException { > > Just to provide a more concrete input, here's a very minimal tested version of what I had in mind: > > > --- a/src/java.base/share/classes/java/util/zip/GZIPInputStream.java > +++ b/src/java.base/share/classes/java/util/zip/GZIPInputStream.java > @@ -55,6 +55,8 @@ public class GZIPInputStream extends InflaterInputStream { > > private boolean closed = false; > > + private final boolean allowConcatenatedGZIPStream; > + > /** > * Check to make sure that this stream has not been closed > */ > @@ -76,14 +78,7 @@ private void ensureOpen() throws IOException { > * @throws IllegalArgumentException if {@code size <= 0} > */ > public GZIPInputStream(InputStream in, int size) throws IOException { > - super(in, createInflater(in, size), size); > - usesDefaultInflater = true; > - try { > - readHeader(in); > - } catch (IOException ioe) { > - this.inf.end(); > - throw ioe; > - } > + this(in, size, true); > } > > /* > @@ -111,7 +106,28 @@ private static Inflater createInflater(InputStream in, int size) { > * @throws IOException if an I/O error has occurred > */ > public GZIPInputStream(InputStream in) throws IOException { > - this(in, 512); > + this(in, 512, true); > + } > + > + /** > + * WIP > + * @param in the input stream > + * @param size the input buffer size > + * @param allowConcatenatedGZIPStream true if the input stream is allowed to contain > + * concatenated GZIP streams. false otherwise > + * @throws IOException if an I/O error has occurred > + */ > + public GZIPInputStream(InputStream in, int size, boolean allowConcatenatedGZIPStream) > + throws IOException { > + super(in, createInflater(in, size), size); > + this.allowConcatenatedGZIPStream = allowConcatenatedGZIPStream; > + usesDefaultInflater = true; > + try { > + readHeader(in); > + } catch (IOException ioe) { > + this.inf.end(); > + throw ioe; > + } > } > > /** > @@ -150,10 +166,45 @@ public int read(byte[] buf, int off, int len) throws IOException { > } > int n = super.read(buf, off, len); > if (n == -1) { > - if (readTrailer()) > + // reading of deflated data is now complete, we now read the GZIP stream trailer > + readTrailer(); > + if (!allowConcatenatedGZIPStream) { > eos = true; > - else > + ... Hi @jaikiran, > I think the only new parameter we should introduce is whether or not the underlying input stream in is expected/allowed to have concatenated GZIP stream(s). I disagree with you here. Based on what I think the goal is here, we need two separate flags. Here's my thinking, please see if this makes sense to you... The overall problem being addressed here is that this class does not give the user precise control of how the input is to be decoded. In particular, it fails in two ways: * It doesn't give the user the ability to stop reading (precisely) after the first GZIP stream * It doesn't give the user the ability to detect (some) erroneous inputs after the first GZIP stream Detecting erronous input is just a basic capability that any "decoder" should have. For example, we would never accept a class file reader that failed to detect and report unknown bytecode. While this class does correctly detect invalid GZIP data frames that appear at the start of the overall input, or in the middle of a compressed GZIP stream, in trying to be "smart" by automatically handling concatenated GZIP streams, it ends up failing to detect corruption where extra bytes are added to the end of the input. Instead, it will randomly do one of the following: * Completely ignore the corruption, or * Throw an exception, or * Misinterpret the extra bytes as the valid start of a concatenated GZIP input stream, and then... * Return zero or more bytes that were never actually written, and then... * Completely ignore the corruption, or * Throw an exception That behavior is totally bogus! So what is the goal here? The first goal is that we should exactly preserve the current behavior so as to not break anything out there. The second goal is to allow the user to specify that they want to read and decode an _exact whole number_ of concatenated GZIP input streams (either 1 or N), or else get an exception - period. Do you not agree? If you agree on that goal, from what I can tell, it doesn't seem possible to achieve it, while also maintaining backward compatibility, without having two flags. Your patch is an example - it may fail to detect and report trailing garbage when in `allowConcatenatedGZIPStream` mode (noted by your comment "TODO: somehow verify that this failed when reading the first byte of the header?") ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1678212410 From jlu at openjdk.org Mon Jul 15 19:35:58 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Jul 2024 19:35:58 GMT Subject: [jdk23] Integrated: 8334653: ISO 4217 Amendment 177 Update In-Reply-To: References: Message-ID: <7nE7WdYxdFEr29sKhM5Non0AGc5hqhDhD51sDf8Ki-k=.11d012a1-115e-4d1b-9c9b-30d937b9c346@github.com> On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch. > > This change incorporates the ISO 4217 Amendment 177 Update. This pull request has now been integrated. Changeset: 5162e1a3 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/5162e1a31c1ec7e35211f3fa91416ac79c8c9a93 Stats: 23 lines in 6 files changed: 3 ins; 0 del; 20 mod 8334653: ISO 4217 Amendment 177 Update Reviewed-by: naoto, iris Backport-of: 86b0cf259fb3cbe3a1973151148e5d36c6a99d91 ------------- PR: https://git.openjdk.org/jdk/pull/20126 From duke at openjdk.org Mon Jul 15 19:58:23 2024 From: duke at openjdk.org (fabioromano1) Date: Mon, 15 Jul 2024 19:58:23 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimized shift-and-add operations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/9248fbd9..dae88369 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=26-27 Stats: 90 lines in 1 file changed: 52 ins; 37 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From liach at openjdk.org Mon Jul 15 22:56:23 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 22:56:23 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v4] In-Reply-To: References: Message-ID: > The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. Chen Liang has updated the pull request incrementally with four additional commits since the last revision: - Make LambdaForm.Name index final - Revert "8335922: Incorrect stable usage of LambdaForm$Name.index" This reverts commit 7d111ba3655c4c282399a4793e2cf5d91618432f. - Revert "We have sufficient space in short, use +1 offset" This reverts commit 0743c5f924fa07ea13f8545604f870091fa8d23a. - Revert "Encapsulate offsetIndex, share computation result" This reverts commit db805834d7117e5752bebcbd671afa6c85ff2cf0. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20178/files - new: https://git.openjdk.org/jdk/pull/20178/files/db805834..771755b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=02-03 Stats: 65 lines in 2 files changed: 4 ins; 30 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/20178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20178/head:pull/20178 PR: https://git.openjdk.org/jdk/pull/20178 From liach at openjdk.org Mon Jul 15 22:56:23 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 22:56:23 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3] In-Reply-To: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> References: <5j1AkwqTwgk4Q95tj6mZWQ2pGao8YagmewRey0vduXk=.6fe1deb1-024c-4625-a0d0-218ed615fbc1@github.com> Message-ID: On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Encapsulate offsetIndex, share computation result I have reimplemented this patch to implement the "make `index` field final" approach, which is much cleaner and friendlier to valhalla. tier 1-3 tests pass. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2229569211 From duke at openjdk.org Tue Jul 16 00:41:52 2024 From: duke at openjdk.org (ExE Boss) Date: Tue, 16 Jul 2024 00:41:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v4] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 22:56:23 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. > > Chen Liang has updated the pull request incrementally with four additional commits since the last revision: > > - Make LambdaForm.Name index final > - Revert "8335922: Incorrect stable usage of LambdaForm$Name.index" > > This reverts commit 7d111ba3655c4c282399a4793e2cf5d91618432f. > - Revert "We have sufficient space in short, use +1 offset" > > This reverts commit 0743c5f924fa07ea13f8545604f870091fa8d23a. > - Revert "Encapsulate offsetIndex, share computation result" > > This reverts commit db805834d7117e5752bebcbd671afa6c85ff2cf0. src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388: > 1386: Name withIndex(int i) { > 1387: return new Name(i, type, function, arguments, constraint); > 1388: } Maybe?also do?what `Name?::withConstraint?(Object)`?does? Suggestion: Name withIndex(int i) { if (i == this.index) return this; return new Name(i, type, function, arguments, constraint); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1678596068 From duke at openjdk.org Tue Jul 16 01:06:03 2024 From: duke at openjdk.org (duke) Date: Tue, 16 Jul 2024 01:06:03 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: <4atMSUsUAYJFfqaQP97FmYRm1mG4mToh5_nV_k84gcQ=.48ff5901-f192-4529-9b27-b04f830079d6@github.com> On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > make variable TOOL_VM_OPTIONS to private @sendaoYan Your change (at version 8941823953055dce95532df0a836259220256f75) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2229778332 From syan at openjdk.org Tue Jul 16 01:06:02 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 16 Jul 2024 01:06:02 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 16:02:49 GMT, Jaikiran Pai wrote: > > Does this PR need 2rd reviewer. > > core-libs area doesn't mandate 2 reviews. The current PR is a test infrastructure change and doesn't impact the functionality of the test. The change has been tested in our CI and appears to work fine without introducing any regressions. Plus the PR has been open for more than 24 hours. So I think it is OK to issue a "integrate" whenever you are ready. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2229776964 From syan at openjdk.org Tue Jul 16 01:46:04 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 16 Jul 2024 01:46:04 GMT Subject: Integrated: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote: > Hi all, > Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. > I think it's necessory to receive jvm options from jtreg. > Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. This pull request has now been integrated. Changeset: 8feabc84 Author: SendaoYan Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/8feabc849ba2f617c8c6dbb2ec5074297beb6437 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/19669 From syan at openjdk.org Tue Jul 16 02:01:56 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 16 Jul 2024 02:01:56 GMT Subject: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has been verified, only change the testacase, the risk is low. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > make variable TOOL_VM_OPTIONS to private Thanks for the sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2229858244 From liach at openjdk.org Tue Jul 16 03:10:29 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 03:10:29 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5] In-Reply-To: References: Message-ID: > The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20178/files - new: https://git.openjdk.org/jdk/pull/20178/files/771755b1..9846703a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20178&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20178/head:pull/20178 PR: https://git.openjdk.org/jdk/pull/20178 From liach at openjdk.org Tue Jul 16 03:10:30 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 03:10:30 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v4] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 00:39:19 GMT, ExE Boss wrote: >> Chen Liang has updated the pull request incrementally with four additional commits since the last revision: >> >> - Make LambdaForm.Name index final >> - Revert "8335922: Incorrect stable usage of LambdaForm$Name.index" >> >> This reverts commit 7d111ba3655c4c282399a4793e2cf5d91618432f. >> - Revert "We have sufficient space in short, use +1 offset" >> >> This reverts commit 0743c5f924fa07ea13f8545604f870091fa8d23a. >> - Revert "Encapsulate offsetIndex, share computation result" >> >> This reverts commit db805834d7117e5752bebcbd671afa6c85ff2cf0. > > src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388: > >> 1386: Name withIndex(int i) { >> 1387: return new Name(i, type, function, arguments, constraint); >> 1388: } > > Maybe?also do?what `Name?::withConstraint?(Object)`?does? > Suggestion: > > Name withIndex(int i) { > if (i == this.index) return this; > return new Name(i, type, function, arguments, constraint); > } Sure, initIndex and newIndex reuses same index object too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1678694062 From liach at openjdk.org Tue Jul 16 03:50:17 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 03:50:17 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable Message-ID: Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable. ------------- Commit messages: - Inline some common ctor + method fields to executable Changes: https://git.openjdk.org/jdk/pull/20188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336275 Stats: 451 lines in 11 files changed: 77 ins; 238 del; 136 mod Patch: https://git.openjdk.org/jdk/pull/20188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20188/head:pull/20188 PR: https://git.openjdk.org/jdk/pull/20188 From duke at openjdk.org Tue Jul 16 05:35:02 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 16 Jul 2024 05:35:02 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:58:23 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Optimized shift-and-add operations src/java.base/share/classes/java/math/MutableBigInteger.java line 945: > 943: } else { > 944: leftShift(n << 5); > 945: add(addend); This method could be further optimized by implementing the shift and sum together directly here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1678780472 From dholmes at openjdk.org Tue Jul 16 06:00:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Jul 2024 06:00:51 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 src/java.base/share/classes/java/lang/VirtualThread.java line 273: > 271: // current thread is a ForkJoinWorkerThread so the task will be pushed > 272: // to the local queue. For other schedulers, it avoids deadlock that > 273: // would arise due to platform and virtual threads contenting for a s/contenting/contending/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1678800192 From jwaters at openjdk.org Tue Jul 16 08:54:54 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 16 Jul 2024 08:54:54 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 16:30:02 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> USe os::snprintf in HotSpot > > src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: > >> 30: #include /* for _MAx_PATH */ >> 31: >> 32: typedef unsigned long long UNSIGNED_JLONG; > > This change has nothing to do with _sprintf. Not sure why it's being made here. It was a small change, so I thought I could make it out of convenience. I'll switch it out to a separate changeset ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1679012119 From jwaters at openjdk.org Tue Jul 16 08:59:20 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 16 Jul 2024 08:59:20 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert Standard Integer type rewrite ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20153/files - new: https://git.openjdk.org/jdk/pull/20153/files/1bd6bc09..a0477b8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From kbarrett at openjdk.org Tue Jul 16 11:49:54 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Jul 2024 11:49:54 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2180004090 From kbarrett at openjdk.org Tue Jul 16 11:49:55 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Jul 2024 11:49:55 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:52:01 GMT, Julian Waters wrote: >> src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: >> >>> 30: #include /* for _MAx_PATH */ >>> 31: >>> 32: typedef unsigned long long UNSIGNED_JLONG; >> >> This change has nothing to do with _sprintf. Not sure why it's being made here. > > It was a small change, so I thought I could make it out of convenience. I'll switch it out to a separate changeset There are lots of uses of those type names. If they are going to be cleaned up, I'd prefer that get done as as separate task, so I don't need to think about whether it's okay to do so while in the context of this change. I don't know if __int64 == long long (probably is), but I'm pretty sure I remember seeing a comment on some use of __int32 suggesting it was not the same as what someone expected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1679248371 From djelinski at openjdk.org Tue Jul 16 12:27:51 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 16 Jul 2024 12:27:51 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2180081756 From rkennke at openjdk.org Tue Jul 16 12:46:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 16 Jul 2024 12:46:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include Another review pass by me. It looks to me like the cache lookup can be improved, see comments below. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 323: > 321: ldr(t1, Address(t3_t)); > 322: cmp(obj, t1); > 323: br(Assembler::EQ, monitor_found); I think the loop could be optimized a bit, if we start with the (cache_address) - 1 in t3, then increment t3 at the start of the loop, and let the success-case fall-through and only branch back to loop-start or to failure-path. Something like: bind(loop); increment(t3_t, in_bytes(OMCache::oop_to_oop_difference())); ldr(t1, Address(t3_t)); cbnz(t1, loop); cmp(obj, t1); br(Assembler::NE, loop); // Success Advantage would be that we have no forward-branch in the fast/expected case. CPU static branch prediction tends to not like that. I'm not sure if if makes a difference, though. Also, if you do that, then the unrolled loop also needs corresponding adjustment. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674: > 672: > 673: // Search for obj in cache. > 674: bind(loop); Same loop transformation would be possible here. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 776: > 774: movl(top, Address(thread, JavaThread::lock_stack_top_offset())); > 775: > 776: if (!UseObjectMonitorTable) { Why is the mark loaded here in the !UOMT case, but later in the +UOMT case? ------------- PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2179942149 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679210139 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679313050 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679315158 From rkennke at openjdk.org Tue Jul 16 12:46:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 16 Jul 2024 12:46:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com> References: <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com> Message-ID: On Tue, 16 Jul 2024 12:37:43 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 776: > >> 774: movl(top, Address(thread, JavaThread::lock_stack_top_offset())); >> 775: >> 776: if (!UseObjectMonitorTable) { > > Why is the mark loaded here in the !UOMT case, but later in the +UOMT case? Ah I see, it is because we don't have enough registers. Right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679316824 From alanb at openjdk.org Tue Jul 16 13:02:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Jul 2024 13:02:54 GMT Subject: RFR: 8334394: Race condition in Class::protectionDomain [v2] In-Reply-To: References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> Message-ID: On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote: >> Make sure `pd` is always the same object when `getProtectionDomain0` is null. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > explain why the test is related to the fix Marked as reviewed by alanb (Reviewer). test/jdk/java/lang/Class/ProtectionDomainRace.java line 61: > 59: private static volatile Throwable failed = null; > 60: public static void main(String[] args) throws Throwable { > 61: var ac = (PrivilegedAction) () -> null; Did you mean to name the PrivilegedAction "ac"? It might be more readable to change this line to `PrivilegedAction pa = () -> null;`. ------------- PR Review: https://git.openjdk.org/jdk/pull/19752#pullrequestreview-2180164683 PR Review Comment: https://git.openjdk.org/jdk/pull/19752#discussion_r1679348512 From alanb at openjdk.org Tue Jul 16 13:32:50 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Jul 2024 13:32:50 GMT Subject: RFR: 8261400: Reflection member filtering registration might be flawed In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote: > 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways to steal this instance, bypassing the filtered getter. JEP 471 has the roadmap for sun.misc.Unsafe, which is to wind it down over time. Relaxing the filter to allow Unsafe::getUnsafe be called may send the wrong message so I don't think it should be changed by this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20058#issuecomment-2230898187 From alanb at openjdk.org Tue Jul 16 13:38:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Jul 2024 13:38:54 GMT Subject: RFR: 8261400: Reflection member filtering registration might be flawed In-Reply-To: References: Message-ID: <7Q9nt0JerdmFkKo3uDZfGxEaCHRBlER3My_WZdLLUE8=.709212ff-70a2-4c9f-94d0-ebdb08252f2e@github.com> On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote: > Please review this patch that address the reflection member filtering flaws. > > 1. Remove a pointless bootstrap check to ensure no filter is accidentally bypassed due to class-loading order. > 2. Clarify the scenarios for filtering, and the correct filter actions for each scenario. > 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways to steal this instance, bypassing the filtered getter. The `jdk.internal.misc.Unsafe`'s filter was already removed in JDK-8161129, so this filter is meaningless. src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 56: > 54: > 55: static { > 56: // 3 filter scenarios: Using "3" is a bit confusing here because the next line starts with "1.". So maybe change it to "Three" or drop completely as I don't think they are too helpful. src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 58: > 56: // 3 filter scenarios: > 57: // 1. Classes loaded before Reflection, may (System) or may not > 58: // (ConstantPool) be initialized before main call: below This comment is confusing. I assume you want to say that these classes may or may not be loaded before the application main method. It may be simpler to just drop the proposed comments as they beg too many questions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20058#discussion_r1679407923 PR Review Comment: https://git.openjdk.org/jdk/pull/20058#discussion_r1679412547 From liach at openjdk.org Tue Jul 16 14:26:51 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 14:26:51 GMT Subject: RFR: 8261400: Reflection member filtering registration might be flawed In-Reply-To: <7Q9nt0JerdmFkKo3uDZfGxEaCHRBlER3My_WZdLLUE8=.709212ff-70a2-4c9f-94d0-ebdb08252f2e@github.com> References: <7Q9nt0JerdmFkKo3uDZfGxEaCHRBlER3My_WZdLLUE8=.709212ff-70a2-4c9f-94d0-ebdb08252f2e@github.com> Message-ID: On Tue, 16 Jul 2024 13:35:50 GMT, Alan Bateman wrote: >> Please review this patch that address the reflection member filtering flaws. >> >> 1. Remove a pointless bootstrap check to ensure no filter is accidentally bypassed due to class-loading order. >> 2. Clarify the scenarios for filtering, and the correct filter actions for each scenario. >> 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways to steal this instance, bypassing the filtered getter. The `jdk.internal.misc.Unsafe`'s filter was already removed in JDK-8161129, so this filter is meaningless. > > src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 58: > >> 56: // 3 filter scenarios: >> 57: // 1. Classes loaded before Reflection, may (System) or may not >> 58: // (ConstantPool) be initialized before main call: below > > This comment is confusing. I assume you want to say that these classes may or may not be loaded before the application main method. It may be simpler to just drop the proposed comments as they beg too many questions. Let's put these 4 points in time: class A load, A init, Reflection init, main run. (If an event is after "main run", it may be completely optional) There can be these arrangements: 1. A load, Reflection init, main run; subcases include: a. A load, A init, Reflection init, main run (System) b. A load, Reflection init, A init, main run (none known yet) c. A load, Reflection init, main run, A init (ConstantPool) Handling: register in Reflection static block 2. Reflection init, A load, A init, main run (MethodHandles.Lookup) Handling: register in their own static block 3. Reflection init, main run, A init; subcases incldue: a. Reflection init, A load, main run, A init (none known yet) b. Reflection init, main run, A load, A init (sun.misc.Unsafe) Handling: Quite hard, easily causing extra class loading How should I phrase my comments? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20058#discussion_r1679515927 From jvernee at openjdk.org Tue Jul 16 14:46:13 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 14:46:13 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4] In-Reply-To: References: Message-ID: > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.conf... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: JVMCI support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20158/files - new: https://git.openjdk.org/jdk/pull/20158/files/6d0b9b57..62849aa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=02-03 Stats: 31 lines in 9 files changed: 29 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20158/head:pull/20158 PR: https://git.openjdk.org/jdk/pull/20158 From jvernee at openjdk.org Tue Jul 16 15:02:53 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 15:02:53 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:46:13 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > JVMCI support Added JVMCI/Graal support, courtesy of @c-refice ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2231133607 From dnsimon at openjdk.org Tue Jul 16 15:02:54 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 16 Jul 2024 15:02:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:46:13 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > JVMCI support src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java line 62: > 60: > 61: /** > 62: * Returns true if this method has a {@code Scoped} annotation. Can you please make this a qualified name: `jdk.internal.misc.ScopedMemoryAccess.Scoped`. That makes it easier for someone not familiar with the code base to find. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1679575238 From jvernee at openjdk.org Tue Jul 16 15:12:15 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 15:12:15 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v5] In-Reply-To: References: Message-ID: > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.conf... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: clarify javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20158/files - new: https://git.openjdk.org/jdk/pull/20158/files/62849aa8..cd5f290e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20158/head:pull/20158 PR: https://git.openjdk.org/jdk/pull/20158 From jvernee at openjdk.org Tue Jul 16 15:12:15 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 15:12:15 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 15:00:04 GMT, Doug Simon wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> JVMCI support > > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java line 62: > >> 60: >> 61: /** >> 62: * Returns true if this method has a {@code Scoped} annotation. > > Can you please make this a qualified name: `jdk.internal.misc.ScopedMemoryAccess.Scoped`. > That makes it easier for someone not familiar with the code base to find. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20158#discussion_r1679589138 From naoto at openjdk.org Tue Jul 16 16:38:20 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 16 Jul 2024 16:38:20 GMT Subject: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance Message-ID: Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/20199/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336300 Stats: 16 lines in 2 files changed: 0 ins; 14 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20199/head:pull/20199 PR: https://git.openjdk.org/jdk/pull/20199 From naoto at openjdk.org Tue Jul 16 16:54:09 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 16 Jul 2024 16:54:09 GMT Subject: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2] In-Reply-To: References: Message-ID: > Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary `this` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20199/files - new: https://git.openjdk.org/jdk/pull/20199/files/13dc1e74..4795076c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20199/head:pull/20199 PR: https://git.openjdk.org/jdk/pull/20199 From joehw at openjdk.org Tue Jul 16 16:57:53 2024 From: joehw at openjdk.org (Joe Wang) Date: Tue, 16 Jul 2024 16:57:53 GMT Subject: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2] In-Reply-To: References: Message-ID: <4qtMD7cJup7BYwPCjz3gPK0STyj6a5wDiYEDb0uG7pA=.31f30467-5e01-4ff2-a043-17db3604b179@github.com> On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary `this` Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2180814858 From iris at openjdk.org Tue Jul 16 17:06:51 2024 From: iris at openjdk.org (Iris Clark) Date: Tue, 16 Jul 2024 17:06:51 GMT Subject: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary `this` Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2180834740 From jlu at openjdk.org Tue Jul 16 17:09:55 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 16 Jul 2024 17:09:55 GMT Subject: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary `this` Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2180841390 From liach at openjdk.org Tue Jul 16 18:08:07 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 18:08:07 GMT Subject: RFR: 8162500: Receiver annotations of inner classes of local classes not found at runtime Message-ID: In annotated types, local and inner class types should be annotated as "top-level" types. For example, in the test here public static Class getLocalsMember() { class Local { class Member { @Annot(2635) Member(@Annot(2732) Local Local.this) {} } } return Local.Member.class; } The `Local` occurrences cannot be qualified with the enclosing class type, even if the local class may be compiled to capture the enclosing class. However, core reflection had a bug where it looks for an enclosing class instead of a declaring class; this meant that for said `Local`, core reflection was treating the outer class as the top-level in type annotations, while the top level should be the local class instead. This patch fixes this bug. ------------- Commit messages: - 8162500: Receiver annotations of inner classes of local classes not found at runtime Changes: https://git.openjdk.org/jdk/pull/20200/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20200&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8162500 Stats: 16 lines in 2 files changed: 11 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20200.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20200/head:pull/20200 PR: https://git.openjdk.org/jdk/pull/20200 From jvernee at openjdk.org Tue Jul 16 18:09:20 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 18:09:20 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v6] In-Reply-To: References: Message-ID: > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.conf... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Revert JVMCI changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20158/files - new: https://git.openjdk.org/jdk/pull/20158/files/cd5f290e..138fba42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=04-05 Stats: 31 lines in 9 files changed: 0 ins; 29 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20158/head:pull/20158 PR: https://git.openjdk.org/jdk/pull/20158 From jvernee at openjdk.org Tue Jul 16 18:09:21 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 18:09:21 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v5] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 15:12:15 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > clarify javadoc As discussed offline, JVMCI/Graal changes will be handled by a followup PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2231508565 From rriggs at openjdk.org Tue Jul 16 18:36:53 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Jul 2024 18:36:53 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote: > Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed. > > To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization. > > It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them. > > With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities. > cc: @AlanBateman Is there a high level description of how these methods would be used? There seems to be a lot of generation of code that duplicates what OIS/OOS already do and that seems unnecessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2231558990 From jvernee at openjdk.org Tue Jul 16 19:50:00 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 19:50:00 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388: > 1386: Name withIndex(int i) { > 1387: if (i == this.index) return this; > 1388: return new Name(i, type, function, arguments, constraint); Don't we still need to clone the arguments here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1679978905 From liach at openjdk.org Tue Jul 16 20:01:52 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 20:01:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 19:39:16 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > > src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388: > >> 1386: Name withIndex(int i) { >> 1387: if (i == this.index) return this; >> 1388: return new Name(i, type, function, arguments, constraint); > > Don't we still need to clone the arguments here? The argument array is `@Stable`, meaning it is already an immutable list. Individual arguments are already immutable. Therefore the original cloning was redundant as there were no content changes to the arguments array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1680000020 From jvernee at openjdk.org Tue Jul 16 20:17:52 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 20:17:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20178#pullrequestreview-2181226974 From jvernee at openjdk.org Tue Jul 16 20:17:53 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 16 Jul 2024 20:17:53 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 19:59:41 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388: >> >>> 1386: Name withIndex(int i) { >>> 1387: if (i == this.index) return this; >>> 1388: return new Name(i, type, function, arguments, constraint); >> >> Don't we still need to clone the arguments here? > > The argument array is `@Stable`, meaning it is already an immutable list. Individual arguments are already immutable. Therefore the original cloning was redundant as there were no content changes to the arguments array. `@Stable` is not quite the same as immutable, but I'm assuming that no code is initializing the array _after_ creating a `Name` with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20178#discussion_r1680015033 From dholmes at openjdk.org Tue Jul 16 21:57:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Jul 2024 21:57:51 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable In-Reply-To: References: Message-ID: <8cVBN_0pZKGqYGrjKoXi3Rda7wzJJHFU3uui8PSdUFI=.1d65c77a-db23-4278-9ab3-16608b19f0aa@github.com> On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote: > Move fields common to Method and Field to executable s/Field/Constructor I was a bit confused about executable fields for a moment. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20188#issuecomment-2231889229 From dholmes at openjdk.org Tue Jul 16 22:27:52 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Jul 2024 22:27:52 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote: > Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable. Hotspot changes look good. Core-libs do too but I will leave that for libs folk to approve src/java.base/share/classes/java/lang/reflect/Executable.java line 54: > 52: public abstract sealed class Executable extends AccessibleObject > 53: implements Member, GenericDeclaration permits Constructor, Method { > 54: // fields injected by hotspot If a field is listed here then it is NOT injected by hotspot. src/java.base/share/classes/java/lang/reflect/Method.java line 73: > 71: */ > 72: public final class Method extends Executable { > 73: // fields injected by hotspot Again not injected ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20188#pullrequestreview-2181384669 PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1680112370 PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1680113161 From liach at openjdk.org Tue Jul 16 22:43:51 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 22:43:51 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 22:00:49 GMT, David Holmes wrote: >> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable. > > src/java.base/share/classes/java/lang/reflect/Executable.java line 54: > >> 52: public abstract sealed class Executable extends AccessibleObject >> 53: implements Member, GenericDeclaration permits Constructor, Method { >> 54: // fields injected by hotspot > > If a field is listed here then it is NOT injected by hotspot. What would be the terminology for a final field that's set by hotspot, against the regular java constrcutor rules? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1680139439 From liach at openjdk.org Tue Jul 16 23:55:18 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 23:55:18 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API Message-ID: `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) Removal details: - `LocalVariable/LocalVariableType.writeTo` - `WritableElement` - In `BufWriter`: - `writeList(List)` - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` - `writeBytes(BufWriter other)` - `ClassReader.compare`: Avoid reading from `BufWriter` Future implementation cleanup out of scope of this patch: - Annotation writing can be upgraded and move away from `Util.Writable` - The writing of CP indices and attributes can move to their dedicated methods - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition ------------- Commit messages: - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage - Fix up usages of Util.write - Hide writeTo from all class file elements Changes: https://git.openjdk.org/jdk/pull/20205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335939 Stats: 456 lines in 48 files changed: 98 ins; 197 del; 161 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From liach at openjdk.org Wed Jul 17 00:09:51 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 00:09:51 GMT Subject: RFR: 8334714: Class-File API leaves preview In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 13:26:39 GMT, ExE Boss wrote: >> Class-File API is leaving preview. >> This is a removal of all `@PreviewFeature` annotations from Class-File API. >> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. >> >> Please review. >> >> Thanks, >> Adam > > Note?that `Utf8Entry::equalsString` has?inconsistent behaviour when?called with?a?`null`?value, which?I?ve?reported as?[JI?9077307], and?should probably be?fixed before this?API leaves?preview. > > [JI?9077307]: https://bugs.openjdk.org/browse/JI-9077307 "JI?9077307: Inconsistent?NPE?behaviour of?`Utf8Entry::equalsString`" @ExE-Boss Your report has been promoted to https://bugs.openjdk.org/browse/JDK-8336430 and will be addressed in a separate patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2232040064 From liach at openjdk.org Wed Jul 17 02:51:51 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 02:51:51 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 13:39:02 GMT, Aleksey Shipilev wrote: >> Indeed, for some reason I thought the range of short is -256 to 255 instead of -65536 to 65535 > >> Indeed, for some reason I thought the range of short is -256 to 255 instead of -65536 to 65535 > > Yeah, I thought something like this was going on; it would be a smart way to leverage that negative side in two-complement form is one value larger. But, `byte` is `-128...127`, and `short` is `-32768..32767`. So current thing would not even work if it did not support `256` as the value :) @shipilev Would you re-review this patch, or are you no longer interested now that `@Stable` is removed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2232246296 From liach at openjdk.org Wed Jul 17 03:03:23 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 03:03:23 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable [v2] In-Reply-To: References: Message-ID: > Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Redundant transient; Update the comments to be more accurate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20188/files - new: https://git.openjdk.org/jdk/pull/20188/files/dbe59a5f..184e8a4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20188&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20188&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20188/head:pull/20188 PR: https://git.openjdk.org/jdk/pull/20188 From liach at openjdk.org Wed Jul 17 03:03:23 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 03:03:23 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 22:41:40 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/reflect/Executable.java line 54: >> >>> 52: public abstract sealed class Executable extends AccessibleObject >>> 53: implements Member, GenericDeclaration permits Constructor, Method { >>> 54: // fields injected by hotspot >> >> If a field is listed here then it is NOT injected by hotspot. > > What would be the terminology for a final field that's set by hotspot, against the regular java constrcutor rules? I have chosen the wording "all final fields are used by the VM" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1680341545 From dholmes at openjdk.org Wed Jul 17 05:18:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 05:18:51 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 03:03:23 GMT, Chen Liang wrote: >> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Redundant transient; Update the comments to be more accurate Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20188#pullrequestreview-2181897055 From dholmes at openjdk.org Wed Jul 17 05:18:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 05:18:51 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 02:57:51 GMT, Chen Liang wrote: >> What would be the terminology for a final field that's set by hotspot, against the regular java constrcutor rules? > > I have chosen the wording "all final fields are used by the VM" I don't know of any specific terminology - we typically just add a comment saying the field is set and/or read by the VM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1680417581 From dholmes at openjdk.org Wed Jul 17 05:21:52 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 05:21:52 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Okay for HotSpot, jdk.hotspot.agent, jdk.jdwp.agent and jdk.management. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2181900237 From dholmes at openjdk.org Wed Jul 17 06:37:57 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:37:57 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/basicLock.hpp line 44: > 42: // a sentinel zero value indicating a recursive stack-lock. > 43: // * For LM_LIGHTWEIGHT > 44: // Used as a cache the ObjectMonitor* used when locking. Must either The first sentence doesn't read correctly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680492976 From dholmes at openjdk.org Wed Jul 17 06:42:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:42:53 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/basicLock.hpp line 46: > 44: // Used as a cache the ObjectMonitor* used when locking. Must either > 45: // be nullptr or the ObjectMonitor* used when locking. > 46: volatile uintptr_t _metadata; The displaced header/markword terminology was very well known to people, whereas "metadata" is really abstract - people will always need to go and find out what it actually refers to. Could we not define a union here to support the legacy and lightweight modes more explicitly and keep the existing terminology for the setters/getters for the code that uses it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680496495 From dholmes at openjdk.org Wed Jul 17 06:42:54 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:42:54 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> References: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> Message-ID: On Wed, 17 Jul 2024 06:39:14 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/share/runtime/basicLock.hpp line 46: > >> 44: // Used as a cache the ObjectMonitor* used when locking. Must either >> 45: // be nullptr or the ObjectMonitor* used when locking. >> 46: volatile uintptr_t _metadata; > > The displaced header/markword terminology was very well known to people, whereas "metadata" is really abstract - people will always need to go and find out what it actually refers to. Could we not define a union here to support the legacy and lightweight modes more explicitly and keep the existing terminology for the setters/getters for the code that uses it? I should have read ahead. I see you do keep the setters/getters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680497748 From dholmes at openjdk.org Wed Jul 17 06:46:00 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:46:00 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/deoptimization.cpp line 1641: > 1639: assert(fr.is_deoptimized_frame(), "frame must be scheduled for deoptimization"); > 1640: if (LockingMode == LM_LEGACY) { > 1641: mon_info->lock()->set_displaced_header(markWord::unused_mark()); In the existing code how is this restricted to the LM_LEGACY case?? It appears to be unconditional which suggests you are changing the non-UOMT LM_LIGHTWEIGHT logic. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680500696 From dholmes at openjdk.org Wed Jul 17 06:50:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:50:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <1FImJurji3MUi1rauLpFYqETg45LmnlxLrRijzXBukg=.7125982a-3507-4711-922e-2c7c9706d87c@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/lightweightSynchronizer.cpp line 60: > 58: > 59: // ConcurrentHashTable storing links from objects to ObjectMonitors > 60: class ObjectMonitorWorld : public CHeapObj { OMWorld describes the project not the hashtable, this should be called ObjectMonitorTable or some such. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62: > 60: class ObjectMonitorWorld : public CHeapObj { > 61: struct Config { > 62: using Value = ObjectMonitor*; Does this alias really help? We don't state the type that many times and it looks odd to end up with a mix of `Value` and `ObjectMonitor*` in the same code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680508685 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680508801 From dholmes at openjdk.org Wed Jul 17 07:02:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 07:02:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102: > 100: assert(*value != nullptr, "must be"); > 101: return (*value)->object_is_cleared(); > 102: } The `is_dead` functions seem oddly placed given they do not relate to the object stored in the wrapper. Why are they here? And what is the difference between `object_is_cleared` and `object_is_dead` (as used by `LookupMonitor`) ? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105: > 103: }; > 104: > 105: class LookupMonitor : public StackObj { I'm not understanding why we need this little wrapper class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680526331 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680526868 From asotona at openjdk.org Wed Jul 17 08:07:52 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 Jul 2024 08:07:52 GMT Subject: RFR: 8335938: Review XxxBuilder.original and XxxModel.parent [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 15:16:23 GMT, Chen Liang wrote: >> Remove unused `Class/Field/Method/CodeBuilder.original()`, and make `Field/Method/CodeModel.parent()` return present only if it's bound (i.e. not buffered transformed). See the CSR for details. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/builder-original > - 8335938: Review XxxBuilder.original and XxxModel.parent Looks good to me, thanks. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20177#pullrequestreview-2182208563 From aturbanov at openjdk.org Wed Jul 17 08:24:51 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 17 Jul 2024 08:24:51 GMT Subject: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2] In-Reply-To: References: Message-ID: <2QoiYJeBYC8IIiCi6dGa6ETO0Tugx6IxjtmbHQQK4J4=.ae899c7d-1485-4e91-b1f9-b5e0342b5b01@github.com> On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary `this` Marked as reviewed by aturbanov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20199#pullrequestreview-2182245319 From asotona at openjdk.org Wed Jul 17 08:35:52 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 Jul 2024 08:35:52 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 287: > 285: public static void writeAnnotation(BufWriterImpl buf, Annotation annotation) { > 286: // handles annotations and type annotations > 287: // TODO annotation cleanup later Do you have any specific annotation cleanup in mind? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20205#discussion_r1680657521 From asotona at openjdk.org Wed Jul 17 08:43:52 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 Jul 2024 08:43:52 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Great job! ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20205#pullrequestreview-2182288974 From asotona at openjdk.org Wed Jul 17 08:59:07 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 Jul 2024 08:59:07 GMT Subject: RFR: 8334714: Class-File API leaves preview [v2] In-Reply-To: References: Message-ID: > Class-File API is leaving preview. > This is a removal of all `@PreviewFeature` annotations from Class-File API. > It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into JDK-8334714-final - bumped @since tag - 8334714: Class-File API leaves preview ------------- Changes: https://git.openjdk.org/jdk/pull/19826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=01 Stats: 715 lines in 166 files changed: 0 ins; 477 del; 238 mod Patch: https://git.openjdk.org/jdk/pull/19826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826 PR: https://git.openjdk.org/jdk/pull/19826 From galder at openjdk.org Wed Jul 17 09:20:51 2024 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Wed, 17 Jul 2024 09:20:51 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Wed, 10 Jul 2024 14:24:05 GMT, Jasmine Karthikeyan wrote: > The C2 changes look nice! I just added one comment here about style. It would also be good to add some IR tests checking that the intrinsic is creating `MaxL`/`MinL` nodes before macro expansion, and a microbenchmark to compare results. Thanks for the review. +1 to the IR tests, I'll work on those. Re: microbenchmark - what do you have exactly in mind? For vectorization performance there is `ReductionPerf` though it's not a microbenchmark per se. Do you want a microbenchmark for the performance of vectorized max/min long? For non-vectorization performance there is `MathBench`. I would not expect performance differences in `MathBench` because the backend is still the same and this change really benefits vectorization. I've run the min/max long tests on darwin/aarch64 and linux/x64 and indeed I see no difference: linux/x64 Benchmark (seed) Mode Cnt Score Error Units MathBench.maxLong 0 thrpt 8 1464197.164 ? 27044.205 ops/ms # base MathBench.minLong 0 thrpt 8 1469917.328 ? 25397.401 ops/ms # base MathBench.maxLong 0 thrpt 8 1469615.250 ? 17950.429 ops/ms # patched MathBench.minLong 0 thrpt 8 1456290.514 ? 44455.727 ops/ms # patched darwin/aarch64 Benchmark (seed) Mode Cnt Score Error Units MathBench.maxLong 0 thrpt 8 1739341.447 ? 210983.444 ops/ms # base MathBench.minLong 0 thrpt 8 1659547.649 ? 260554.159 ops/ms # base MathBench.maxLong 0 thrpt 8 1660449.074 ? 254534.725 ops/ms # patched MathBench.minLong 0 thrpt 8 1729728.021 ? 16327.575 ops/ms # patched ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2232836799 From liach at openjdk.org Wed Jul 17 11:36:51 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 11:36:51 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 08:33:27 GMT, Adam Sotona wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 287: > >> 285: public static void writeAnnotation(BufWriterImpl buf, Annotation annotation) { >> 286: // handles annotations and type annotations >> 287: // TODO annotation cleanup later > > Do you have any specific annotation cleanup in mind? I am thinking of removing the Writable Hierarchy from annotations, and these static methods will handle writing with like a switch (on char, can't use pattern match in bootstrap) instead ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20205#discussion_r1680896744 From rgiulietti at openjdk.org Wed Jul 17 13:23:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 13:23:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:58:23 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Optimized shift-and-add operations src/java.base/share/classes/java/math/MutableBigInteger.java line 1978: > 1976: * is either correct, or rounded up by one if the value is too high > 1977: * and too close to the next perfect square. > 1978: */ Contrary to my previous believe and own experiments, I now think this code is incorrect. Let `long t = 3037000503L` and `long x = t * t`. The code computes `long s == 3037000502L`, an underestimate of the correct square root `t` by 1. Underestimates are neither detected nor corrected. Of course, the corresponding remainder `long r = x - s * s`, namely `r = 6074001005L`, is just barely too large as it does _not_ meet `r <= 2 * s`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681033100 From chegar at openjdk.org Wed Jul 17 13:26:57 2024 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 17 Jul 2024 13:26:57 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v6] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 18:09:20 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Revert JVMCI changes Thanks for the discussion and changes in this PR - it's super helpful ( in what we can do to workaround ), as well as a great improvement for the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2233313234 From chegar at openjdk.org Wed Jul 17 13:26:58 2024 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 17 Jul 2024 13:26:58 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: <_PDgnriMr5GoRUoTpxJnhZjIqEcjdF2kscNx94ScPlc=.b035d8ac-e218-46ed-86d9-a08368c63dc5@github.com> References: <_PDgnriMr5GoRUoTpxJnhZjIqEcjdF2kscNx94ScPlc=.b035d8ac-e218-46ed-86d9-a08368c63dc5@github.com> Message-ID: On Mon, 15 Jul 2024 12:59:27 GMT, Maurizio Cimadamore wrote: > Effectively, once all the issues surrounding reachability fences will be addressed, we should be able to achieve numbers similar to above even in the case of shared close. Is there an issue where I can follow this? [ EDIT: oh! it's [JDK-8290892](https://bugs.openjdk.org/browse/JDK-8290892) ] ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2233317727 From shade at openjdk.org Wed Jul 17 13:47:52 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 13:47:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 13:39:02 GMT, Aleksey Shipilev wrote: >> Indeed, for some reason I thought the range of short is -256 to 255 instead of -65536 to 65535 > >> Indeed, for some reason I thought the range of short is -256 to 255 instead of -65536 to 65535 > > Yeah, I thought something like this was going on; it would be a smart way to leverage that negative side in two-complement form is one value larger. But, `byte` is `-128...127`, and `short` is `-32768..32767`. So current thing would not even work if it did not support `256` as the value :) > @shipilev Would you re-review this patch, or are you no longer interested now that `@Stable` is removed? I am not sure I understand the performance implications for this change. I can see the optimization for avoiding `Name` reallocation when we can rewrite the `index` is from original JSR 292 work that introduced LFs. Maybe that optimization is actually not worth it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2233366471 From szaldana at openjdk.org Wed Jul 17 13:52:05 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 17 Jul 2024 13:52:05 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Message-ID: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Hi all, This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. This PR addresses the following diagnostic commands: - [x] Compiler.perfmap - [x] GC.heap_dump - [x] System.dump_map - [x] Thread.dump_to_file - [x] VM.cds Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, filename (Optional) Name of the file to which the flight recording data is written when the recording is stopped. If no filename is given, a filename is generated from the PID and the current date and is placed in the directory where the process was started. The filename may also be a directory in which case, the filename is generated from the PID and the current date in the specified directory. (STRING, no default value) Note: If a filename is given, '%p' in the filename will be replaced by the PID, and '%t' will be replaced by the time in 'yyyy_MM_dd_HH_mm_ss' format. Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. Testing: - [x] Added test case passes. - [x] Modified existing VM.cds tests to also check for `%p` filenames. Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). Cheers, Sonia ------------- Commit messages: - 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Changes: https://git.openjdk.org/jdk/pull/20198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334492 Stats: 130 lines in 5 files changed: 116 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From duke at openjdk.org Wed Jul 17 13:52:57 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 13:52:57 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 13:15:17 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimized shift-and-add operations > > src/java.base/share/classes/java/math/MutableBigInteger.java line 1978: > >> 1976: * is either correct, or rounded up by one if the value is too high >> 1977: * and too close to the next perfect square. >> 1978: */ > > Contrary to my previous believe and own experiments, I now think this code is incorrect. > > Let `long t = 3037000503L` and `long x = t * t`. The code computes `long s == 3037000502L`, an underestimate of the correct square root `t` by 1. Underestimates are neither detected nor corrected. > Of course, the corresponding remainder `long r = x - s * s`, namely `r = 6074001005L`, is just barely too large as it does _not_ meet `r <= 2 * s`. In fact, if you run this code: `long limit = 1L << 32; for (long n = 0; n < limit; n++) { long x = n * n; if (n != (long) Math.sqrt(x >= 0 ? x : x + 0x1p64)) { System.out.println(n); } }` now you find a lot of counterexamples. The question is: why, until recently, if I did run the same code I could not find a counterexample? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681091360 From duke at openjdk.org Wed Jul 17 13:59:57 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 13:59:57 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: Message-ID: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> On Wed, 17 Jul 2024 13:48:59 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1978: >> >>> 1976: * is either correct, or rounded up by one if the value is too high >>> 1977: * and too close to the next perfect square. >>> 1978: */ >> >> Contrary to my previous believe and own experiments, I now think this code is incorrect. >> >> Let `long t = 3037000503L` and `long x = t * t`. The code computes `long s == 3037000502L`, an underestimate of the correct square root `t` by 1. Underestimates are neither detected nor corrected. >> Of course, the corresponding remainder `long r = x - s * s`, namely `r = 6074001005L`, is just barely too large as it does _not_ meet `r <= 2 * s`. > > In fact, if you run this code: > `long limit = 1L << 32; > for (long n = 0; n < limit; n++) { > long x = n * n; > if (n != (long) Math.sqrt(x >= 0 ? x : x + 0x1p64)) { > System.out.println(n); > } > }` > > now you find a lot of counterexamples. The question is: why, until recently, if I did run the same code I could not find a counterexample? I hope these errors are not due to an implementation change in the virtual machine instructions... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681105179 From rgiulietti at openjdk.org Wed Jul 17 13:59:57 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 13:59:57 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> Message-ID: On Wed, 17 Jul 2024 13:57:06 GMT, fabioromano1 wrote: >> In fact, if you run this code: >> `long limit = 1L << 32; >> for (long n = 0; n < limit; n++) { >> long x = n * n; >> if (n != (long) Math.sqrt(x >= 0 ? x : x + 0x1p64)) { >> System.out.println(n); >> } >> }` >> >> now you find a lot of counterexamples. The question is: why, until recently, if I did run the same code I could not find a counterexample? > > I hope these errors are not due to an implementation change in the virtual machine instructions... There are no counterexamples for perfect squares if you write `long s = (long) Math.rint(Math.sqrt(x >= 0 ? x : x + 0x1p64));`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681105600 From szaldana at openjdk.org Wed Jul 17 14:02:31 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 17 Jul 2024 14:02:31 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v2] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Updating copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/ee46dab5..eea54f6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From jvernee at openjdk.org Wed Jul 17 14:12:52 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 17 Jul 2024 14:12:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index In-Reply-To: References: Message-ID: <5LNvh3ne44qnDuRQ64-ZXIIcXI9H2UPRE_DGtpOup5U=.71b1665a-f9e8-4d2f-ad11-f6ae2e7044d3@github.com> On Wed, 17 Jul 2024 13:44:58 GMT, Aleksey Shipilev wrote: > > @shipilev Would you re-review this patch, or are you no longer interested now that `@Stable` is removed? > > I am not sure I understand the performance implications for this change. I can see the optimization for avoiding `Name` reallocation when we can rewrite the `index` is from original JSR 292 work that introduced LFs. Maybe that optimization is actually not worth it. The old code made it possible to lazily initialize a `Name`'s index without creating a new `Name` instance. Another way to get there would be to explicitly specify the index when a `Name` is created. When I started thinking about that yesterday, I thought maybe clients of `LambdaForm` shouldn't be in charge of creating `Name`s in the first place, and instead this should be handled by some `LambdaForm`-builder like utility, which can immediately fill in the right index. AFAICS, the only possible optimization that this would block is the sharing of `Name` instance with the same index in different `LambdaForms` (though, not sure if that's even done right now). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2233426807 From duke at openjdk.org Wed Jul 17 14:13:55 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 14:13:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> Message-ID: On Wed, 17 Jul 2024 13:57:20 GMT, Raffaello Giulietti wrote: >> I hope these errors are not due to an implementation change in the virtual machine instructions... > > There are no counterexamples for perfect squares if you write `long s = (long) Math.rint(Math.sqrt(x >= 0 ? x : x + 0x1p64));`. @rgiulietti Is it normal that the same code did not find counterexamples until recently, and now it finds them? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681131458 From liach at openjdk.org Wed Jul 17 14:17:52 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 14:17:52 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5] In-Reply-To: References: Message-ID: <_uPim4bjMbe8yg2PP5iDLK05moTJ9xA1MqlJaAKRKdI=.d209c82c-85d4-470b-b1aa-905c516ff41e@github.com> On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Another interesting aspect is the management of Name's index is purely up to LambdaForm itself: users who supply Names never have to set the index, but they know the indices will be valid once they get the Names from LF. I still think we can change it final so that we can just migrate it to be value classes, and by then whether we reallocate Name shouldn't matter any more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2233436802 From rgiulietti at openjdk.org Wed Jul 17 14:20:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 14:20:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> Message-ID: <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> On Wed, 17 Jul 2024 14:11:20 GMT, fabioromano1 wrote: >> There are no counterexamples for perfect squares if you write `long s = (long) Math.rint(Math.sqrt(x >= 0 ? x : x + 0x1p64));`. > > @rgiulietti Is it normal that the same code did not find counterexamples until recently, and now it finds them? I tried on older release, they all agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681142046 From stuefe at openjdk.org Wed Jul 17 14:24:54 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Jul 2024 14:24:54 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v2] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> On Wed, 17 Jul 2024 14:02:31 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updating copyright headers First cursory review. That is a useful feature - In all cases: please, in case of an error, don't THROW, don't do `warning`. Instead, just print to the `output()` of the DCmd. You want an error to appear to the user of the dcmd - so, to stdout or stderr of the jcmd process issuing the command. Not an exception in the target JVM process, nor a warning in the target JVM stderr stream - Can you give us a variant of `Arguments::copy_expand_pid` that receives a zero-terminated const char* as input so that we can avoid having to pass in the length of the input each time? - when passing in output buffers to functions, try to use sizeof(buffer) instead of repeating the buffer size. Then, one can change the size of the buffer array without having to modify using calls (but aware: pitfall, sizeof(char[]) vs sizeof(char*)) src/hotspot/share/code/codeCache.cpp line 1796: > 1794: // Perf expects to find the map file at /tmp/perf-.map > 1795: // if the file name is not specified. > 1796: char fname[JVM_MAXPATHLEN]; Good to see this gone, the old code implicitly relied on: max pid len -2147483647 = 11 chars, + length of "/tmp/perf-.map" not overflowing 32, which cuts a bit close to the bone. src/hotspot/share/code/codeCache.cpp line 1800: > 1798: jio_snprintf(fname, sizeof(fname), "/tmp/perf-%d.map", > 1799: os::current_process_id()); > 1800: } Arguably one could just do constexpr char[] filename_default = "/tmp/perf-%p.map"; Arguments::copy_expand_pid(filename == nullptr ? filename_default : filename, .....); src/hotspot/share/services/diagnosticCommand.cpp line 525: > 523: stringStream msg; > 524: msg.print("Invalid file path name specified: %s", _filename.value()); > 525: THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), msg.base()); Why throw? Why not just print an error message to the output() stream and return? src/hotspot/share/services/diagnosticCommand.cpp line 1059: > 1057: fileh = java_lang_String::create_from_str(fname, CHECK); > 1058: } else { > 1059: warning("Invalid file path name specified, fall back to default name"); `warning` prints a warning to the stdout of the JVM process. You don't want that; you want a warning to the issuer of the dcmd, which is another - possibly even remote - process. Write errors to `output()`, instead. src/hotspot/share/services/diagnosticCommand.cpp line 1138: > 1136: stringStream msg; > 1137: msg.print("Invalid file path name specified: %s", _filepath.value()); > 1138: THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), msg.base()); write to output() and return instead of throwing ------------- PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2183023385 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681109673 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681115247 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681118969 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681124783 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681125914 From stuefe at openjdk.org Wed Jul 17 14:24:54 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Jul 2024 14:24:54 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v2] In-Reply-To: <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> Message-ID: On Wed, 17 Jul 2024 14:02:01 GMT, Thomas Stuefe wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating copyright headers > > src/hotspot/share/code/codeCache.cpp line 1800: > >> 1798: jio_snprintf(fname, sizeof(fname), "/tmp/perf-%d.map", >> 1799: os::current_process_id()); >> 1800: } > > Arguably one could just do > > constexpr char[] filename_default = "/tmp/perf-%p.map"; > Arguments::copy_expand_pid(filename == nullptr ? filename_default : filename, .....); This pattern can be followed in all cases where we have default filenames ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681149193 From duke at openjdk.org Wed Jul 17 14:32:55 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 14:32:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> Message-ID: On Wed, 17 Jul 2024 14:17:48 GMT, Raffaello Giulietti wrote: >> @rgiulietti Is it normal that the same code did not find counterexamples until recently, and now it finds them? > > I tried on older release, they all agree. @rgiulietti This is so strange... anyway, I tried also `long x = n * n`, `long s = (long) Math.ceil(Math.sqrt(x >= 0 ? x : x + 0x1p64))` with the test `s < n`, which I think it's more mathematically natural, and also this never fails for perfect squares. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681162885 From rgiulietti at openjdk.org Wed Jul 17 15:10:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 15:10:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> Message-ID: On Wed, 17 Jul 2024 14:30:33 GMT, fabioromano1 wrote: >> I tried on older release, they all agree. > > @rgiulietti This is so strange... anyway, I tried also `long x = n * n`, `long s = Math.round(Math.sqrt(x >= 0 ? x : x + 0x1p64))` with the test `s < n`, which I think it's more mathematically natural, and also this never fails for perfect squares. Also, this avoids a test if (Long.compareUnsigned(x, s * s - 1) <= 0) { // benign over- and underflows s--; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681230093 From rgiulietti at openjdk.org Wed Jul 17 15:13:56 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 15:13:56 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> Message-ID: On Wed, 17 Jul 2024 15:08:22 GMT, Raffaello Giulietti wrote: >> @rgiulietti This is so strange... anyway, I tried also `long x = n * n`, `long s = Math.round(Math.sqrt(x >= 0 ? x : x + 0x1p64))` with the test `s < n`, which I think it's more mathematically natural, and also this never fails for perfect squares. > > Also, this avoids a test > > if (Long.compareUnsigned(x, s * s - 1) <= 0) { // benign over- and underflows > s--; > } Sorry, disregard the above as it doesn't work for x = 0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681234957 From jvernee at openjdk.org Wed Jul 17 15:19:18 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 17 Jul 2024 15:19:18 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v7] In-Reply-To: References: Message-ID: > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.conf... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: benchmark review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20158/files - new: https://git.openjdk.org/jdk/pull/20158/files/138fba42..2019289b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20158&range=05-06 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20158/head:pull/20158 PR: https://git.openjdk.org/jdk/pull/20158 From duke at openjdk.org Wed Jul 17 15:20:15 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 15:20:15 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v29] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Correct square root computation of long values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/dae88369..32b08f9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=27-28 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Wed Jul 17 15:20:15 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 15:20:15 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> Message-ID: <6ZhVpp5bHsOgEgV7VhHIlkXLnOxY2OEQfvpqld4nC2E=.5b0d21e6-89a4-4583-98df-7322deb0ea9b@github.com> On Wed, 17 Jul 2024 15:11:36 GMT, Raffaello Giulietti wrote: >> Also, this avoids a test >> >> if (Long.compareUnsigned(x, s * s - 1) <= 0) { // benign over- and underflows >> s--; >> } > > Sorry, disregard the above as it doesn't work for x = 0. > Also, this avoids a test > > ``` > if (Long.compareUnsigned(x, s * s - 1) <= 0) { // benign over- and underflows > s--; > } > ``` Yes, but... if `s == 0`, then `x == 0`, so `Long.compareUnsigned(x, s * s - 1) <= 0` and `s` is decremented... incorrectly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681241965 From duke at openjdk.org Wed Jul 17 15:33:39 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 15:33:39 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: More accurate comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/32b08f9d..a23cdef3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=28-29 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From mcimadamore at openjdk.org Wed Jul 17 15:43:54 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 17 Jul 2024 15:43:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v7] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 15:19:18 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > benchmark review comments Changes in scopedMemoryAccess and benchmark look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20158#pullrequestreview-2183305234 From duke at openjdk.org Wed Jul 17 16:01:55 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 16:01:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> Message-ID: On Wed, 17 Jul 2024 15:11:36 GMT, Raffaello Giulietti wrote: >> Also, this avoids a test >> >> if (Long.compareUnsigned(x, s * s - 1) <= 0) { // benign over- and underflows >> s--; >> } > > Sorry, disregard the above as it doesn't work for x = 0. @rgiulietti Probably I used a too older release to try the incorrect code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681312282 From liach at openjdk.org Wed Jul 17 16:17:51 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 16:17:51 GMT Subject: RFR: 8336275: Move common Method and Constructor fields to Executable [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 03:03:23 GMT, Chen Liang wrote: >> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable. >> >> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Redundant transient; Update the comments to be more accurate Just noted that I removed some abstract flags from `Executable` methods, which requires a CSR archive entry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20188#issuecomment-2233696779 From rgiulietti at openjdk.org Wed Jul 17 16:18:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 16:18:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> Message-ID: <_nj7-0pS6pCEhtM0xxTkeMc5fLyEZVTfhl3GysH9PSY=.4e3a10e3-f44d-4b64-9bb9-5f9f1df8b9d2@github.com> On Wed, 17 Jul 2024 15:59:30 GMT, fabioromano1 wrote: >> Sorry, disregard the above as it doesn't work for x = 0. > > @rgiulietti Probably I used a too older release to try the incorrect code Can try with the old release and the incorrect code again? If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681337242 From rgiulietti at openjdk.org Wed Jul 17 16:18:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 16:18:55 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: <_nj7-0pS6pCEhtM0xxTkeMc5fLyEZVTfhl3GysH9PSY=.4e3a10e3-f44d-4b64-9bb9-5f9f1df8b9d2@github.com> References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> <_nj7-0pS6pCEhtM0xxTkeMc5fLyEZVTfhl3GysH9PSY=.4e3a10e3-f44d-4b64-9bb9-5f9f1df8b9d2@github.com> Message-ID: On Wed, 17 Jul 2024 16:15:47 GMT, Raffaello Giulietti wrote: >> @rgiulietti Probably I used a too older release to try the incorrect code > > Can try with the old release and the incorrect code again? > If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. Can try with the old release and the incorrect code again? If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681337746 From naoto at openjdk.org Wed Jul 17 16:27:55 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Jul 2024 16:27:55 GMT Subject: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary `this` Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20199#issuecomment-2233712534 From naoto at openjdk.org Wed Jul 17 16:27:56 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Jul 2024 16:27:56 GMT Subject: Integrated: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 16:33:02 GMT, Naoto Sato wrote: > Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. This pull request has now been integrated. Changeset: 10186ff4 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/10186ff48fe67aeb83c028b47f6b7e5105513cf3 Stats: 17 lines in 2 files changed: 0 ins; 14 del; 3 mod 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance Reviewed-by: joehw, iris, jlu, aturbanov ------------- PR: https://git.openjdk.org/jdk/pull/20199 From duke at openjdk.org Wed Jul 17 16:32:56 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 16:32:56 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> <_nj7-0pS6pCEhtM0xxTkeMc5fLyEZVTfhl3GysH9PSY=.4e3a10e3-f44d-4b64-9bb9-5f9f1df8b9d2@github.com> Message-ID: On Wed, 17 Jul 2024 16:16:12 GMT, Raffaello Giulietti wrote: >> Can try with the old release and the incorrect code again? >> If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. > > Can try with the old release and the incorrect code again? > If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. @rgiulietti If I remember correctly, I had tested the code in a bit of a hurry on an online compiler, that of W3Schools, but more probably I could have made a mistake writing the test code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681353885 From duke at openjdk.org Wed Jul 17 16:41:54 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Jul 2024 16:41:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> <_nj7-0pS6pCEhtM0xxTkeMc5fLyEZVTfhl3GysH9PSY=.4e3a10e3-f44d-4b64-9bb9-5f9f1df8b9d2@github.com> Message-ID: On Wed, 17 Jul 2024 16:16:12 GMT, Raffaello Giulietti wrote: >> Can try with the old release and the incorrect code again? >> If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. > > Can try with the old release and the incorrect code again? > If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. @rgiulietti The strangest thing is that we were both convinced that we had correctly tested the code on all values, without finding counterexamples... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681365907 From rgiulietti at openjdk.org Wed Jul 17 16:46:58 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Jul 2024 16:46:58 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v28] In-Reply-To: References: <9LL6e-rGW3WI4AUqlhPLWAOvC_B1HbDm1pvglNB_vCA=.0e03a88b-323b-4098-a3d7-b52c56c56cbe@github.com> <292O4u6VWoBtrBQHdiPoCDUWvKolhpZfni9qDjXlb1k=.625192af-1ca4-4d52-b17b-5bc860566cfa@github.com> <_nj7-0pS6pCEhtM0xxTkeMc5fLyEZVTfhl3GysH9PSY=.4e3a10e3-f44d-4b64-9bb9-5f9f1df8b9d2@github.com> Message-ID: <5-6B3UInQwP7LtK8iK4cIBFpURlmuCl2s1IuACz7hdw=.14397e19-9a0b-4419-8cec-25c0ca0df600@github.com> On Wed, 17 Jul 2024 16:39:10 GMT, fabioromano1 wrote: >> Can try with the old release and the incorrect code again? >> If the results disagree with newer releases then I'd be interested in which release you were using, as to analyze the generated code and possibly file a bug report for the JIT compiler team. > > @rgiulietti The strangest thing is that we were both convinced that we had correctly tested the code on all values, without finding counterexamples... I was trying with my own code, the one with the additional `Math.rint()` invocation, and didn't notice that the code in the PR was using a `(long)` conversion directly. So my throw-away mini-program was slightly different from yours. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1681371163 From kvn at openjdk.org Wed Jul 17 16:48:54 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 16:48:54 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v7] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 15:19:18 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > benchmark review comments I am fine with compiler and CI changes - it is just marking nmethod as having scoped access. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20158#pullrequestreview-2183464779 From aph at openjdk.org Wed Jul 17 17:17:52 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 17 Jul 2024 17:17:52 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Thu, 11 Jul 2024 23:47:51 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/oops/klass.cpp line 284: >> >>> 282: // which doesn't zero out the memory before calling the constructor. >>> 283: Klass::Klass(KlassKind kind) : _kind(kind), >>> 284: _bitmap(SECONDARY_SUPERS_BITMAP_FULL), >> >> I like the idea, but what are the benefits of initializing `_bitmap` separately from `_secondary_supers`? > > Another observation while browsing the code: `_secondary_supers_bitmap` would be a better name. (Same considerations apply to `_hash_slot`.) This is because the C++ runtime does secondary super cache lookups even before the bitmap has been calculated and the hash table sorted. In this case the bitmap is zero, so teh search thinks there are no secondary supers. Setting _bitmap to SECONDARY_SUPERS_BITMAP_FULL forces a linear search. I guess there might be a better way to do this. Perhaps a comment is needed? I agree about `_secondary_supers_bitmap` name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1681410651 From aph at openjdk.org Wed Jul 17 17:17:53 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 17 Jul 2024 17:17:53 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Fri, 5 Jul 2024 22:37:34 GMT, Vladimir Ivanov wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > src/hotspot/share/oops/klass.cpp line 469: > >> 467: #endif >> 468: >> 469: bitmap = hash_secondary_supers(secondary_supers, /*rewrite=*/true); // rewrites freshly allocated array > > I like that hashing is performed unconditionally now. > > Looks like you can remove `UseSecondarySupersTable`-specific CDS support (in `filemap.cpp`). CDS archive should unconditionally contain hashed tables. Sure. > src/hotspot/share/oops/klass.inline.hpp line 122: > >> 120: return true; >> 121: >> 122: bool result = lookup_secondary_supers_table(k); > > Should `UseSecondarySupersTable` affect `Klass::search_secondary_supers` as well? I think not. It'd complicate C++ runtime for no useful reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1681411088 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1681412747 From duke at openjdk.org Wed Jul 17 17:32:09 2024 From: duke at openjdk.org (Kevin Bourrillion) Date: Wed, 17 Jul 2024 17:32:09 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} In-Reply-To: <13yMIgfcXgfmSbDRsUfOPAdnay2-81vsMKG4xpwMkbs=.a12c7d6a-9147-49c4-bc60-f950805b6391@github.com> References: <13yMIgfcXgfmSbDRsUfOPAdnay2-81vsMKG4xpwMkbs=.a12c7d6a-9147-49c4-bc60-f950805b6391@github.com> Message-ID: On Thu, 11 Jul 2024 00:10:02 GMT, Stuart Marks wrote: >> First pass at adding some quality of implementation discussions around the overridable methods of Object. > > src/java.base/share/classes/java/lang/Object.java line 53: > >> 51: * {@link VirtualMachineError} is possible during the execution of a >> 52: * method, often due to factors outside of the method's direct >> 53: * control. > > "Should not throw any exception or other throwable" is overly broad. However, there is a narrower sense where code that implements these methods "shouldn't" throw anything. I'd suggest focusing on precondition checking. Specifically, no object should ever be in a state such that calling one of these methods results in IllegalStateException or other exception based on the state of the object. In addition, no argument passed to equals() should ever cause IllegalArgumentException, ClassCastException, NullPointerException, or other exception based on the argument. > > (This comment applies to other locations where the "excessive" wording is used.) I would hope to spend as little space on this as possible, perhaps "This method should avoid throwing or propagating any exceptions unless it legitimately _cannot_ adhere to this contract." (or shorter) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1678252098 From liach at openjdk.org Wed Jul 17 18:08:51 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 18:08:51 GMT Subject: RFR: 8334772: Change Class::protectionDomain and signers to explicit fields Message-ID: Please review this change that moves `Class.protectionDomain` and `signers` to explicit fields. Related native methods in `Class` and `AccessController::getProtectionDomain` are converted to pure Java. These fields are still set and used by hotspot. Also fixes the incorrect `protectiondomain_signature` in `vmSymbols`, which is actually an array descriptor. Note that these new fields are not filtered: filtering in early bootstrap requires other unrelated adjustments as we can't even use hashCode on String, and filtering is not proper encapsulation either. ------------- Commit messages: - Tests rely on Class ctor - Move class protectionDomain and signers fields to be explicit Changes: https://git.openjdk.org/jdk/pull/20221/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334772 Stats: 145 lines in 15 files changed: 25 ins; 90 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/20221.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20221/head:pull/20221 PR: https://git.openjdk.org/jdk/pull/20221 From naoto at openjdk.org Wed Jul 17 18:09:57 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Jul 2024 18:09:57 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) Message-ID: Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/20220/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336479 Stats: 109 lines in 2 files changed: 106 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20220/head:pull/20220 PR: https://git.openjdk.org/jdk/pull/20220 From liach at openjdk.org Wed Jul 17 18:09:57 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 18:09:57 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 17:36:29 GMT, Naoto Sato wrote: > Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. src/java.base/share/classes/java/lang/Process.java line 504: > 502: return false; > 503: > 504: return waitForNanos(TimeUnit.NANOSECONDS.convert(duration)); `waitFor` can be overridden by pre-24 subclasses to provide a better implementation while `waitForNanos` couldn't. Is it reasonable for our default implementation to delegate to `waitFor(long, TimeUnit)` that existing user classes have better implementations for? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1681464947 From alanb at openjdk.org Wed Jul 17 18:30:41 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Jul 2024 18:30:41 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 17:36:29 GMT, Naoto Sato wrote: > Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. src/java.base/share/classes/java/lang/Process.java line 481: > 479: * this method returns immediately with the value {@code false}. > 480: * > 481: *

The default implementation of this method polls the {@code exitValue} There was discussion in the CSR on moving this to an `@implSpec`, are you going to do that change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1681550925 From alanb at openjdk.org Wed Jul 17 18:34:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Jul 2024 18:34:36 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 17:51:52 GMT, Chen Liang wrote: > waitFor can be overridden by pre-24 subclasses to provide a better implementation while ... It doesn't really make sense to extend Process, except maybe for mocking or other testing. Process is really for JDK implementations, it's just historical the constructor is public. Just saying that the compatibility concerns with adding methods aren't significant here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1681554852 From alanb at openjdk.org Wed Jul 17 18:38:38 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Jul 2024 18:38:38 GMT Subject: RFR: 8334772: Change Class::protectionDomain and signers to explicit fields In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 17:47:11 GMT, Chen Liang wrote: > Please review this change that moves `Class.protectionDomain` and `signers` to explicit fields. > > Related native methods in `Class` and `AccessController::getProtectionDomain` are converted to pure Java. These fields are still set and used by hotspot. Also fixes the incorrect `protectiondomain_signature` in `vmSymbols`, which is actually an array descriptor. > > Note that these new fields are not filtered: filtering in early bootstrap requires other unrelated adjustments as we can't even use hashCode on String, and filtering is not proper encapsulation either. Offline discussion with Chen and I think the advice is to drop all the changes for ProtectionDomain for now. This area will change significantly as part of the SecurityManager removal work. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 430: > 428: * {@link Class#getProtectionDomain()} > 429: */ > 430: ProtectionDomain protectionDomain(Class c, boolean raw); I don't think we should expose this outside of java.lang. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20221#issuecomment-2233996684 PR Review Comment: https://git.openjdk.org/jdk/pull/20221#discussion_r1681559624 From liach at openjdk.org Wed Jul 17 18:45:38 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 18:45:38 GMT Subject: RFR: 8334772: Change Class::protectionDomain and signers to explicit fields In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 17:47:11 GMT, Chen Liang wrote: > Please review this change that moves `Class.protectionDomain` and `signers` to explicit fields. > > Related native methods in `Class` and `AccessController::getProtectionDomain` are converted to pure Java. These fields are still set and used by hotspot. Also fixes the incorrect `protectiondomain_signature` in `vmSymbols`, which is actually an array descriptor. > > Note that these new fields are not filtered: filtering in early bootstrap requires other unrelated adjustments as we can't even use hashCode on String, and filtering is not proper encapsulation either. The migration of signers will be in a new PR. This patch will be kept so people will know the extra test updates related to migration of protectionDomain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20221#issuecomment-2234008622 From liach at openjdk.org Wed Jul 17 18:45:38 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 18:45:38 GMT Subject: Withdrawn: 8334772: Change Class::protectionDomain and signers to explicit fields In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 17:47:11 GMT, Chen Liang wrote: > Please review this change that moves `Class.protectionDomain` and `signers` to explicit fields. > > Related native methods in `Class` and `AccessController::getProtectionDomain` are converted to pure Java. These fields are still set and used by hotspot. Also fixes the incorrect `protectiondomain_signature` in `vmSymbols`, which is actually an array descriptor. > > Note that these new fields are not filtered: filtering in early bootstrap requires other unrelated adjustments as we can't even use hashCode on String, and filtering is not proper encapsulation either. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20221 From vlivanov at openjdk.org Wed Jul 17 18:48:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 17 Jul 2024 18:48:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Wed, 17 Jul 2024 17:13:49 GMT, Andrew Haley wrote: >> Another observation while browsing the code: `_secondary_supers_bitmap` would be a better name. (Same considerations apply to `_hash_slot`.) > > This is because the C++ runtime does secondary super cache lookups even before the bitmap has been calculated and the hash table sorted. In this case the bitmap is zero, so teh search thinks there are no secondary supers. Setting _bitmap to SECONDARY_SUPERS_BITMAP_FULL forces a linear search. > > I guess there might be a better way to do this. Perhaps a comment is needed? > > I agree about `_secondary_supers_bitmap` name. Now it starts to sound concerning... `Klass::set_secondary_supers()` initializes both `_secondary_supers` and `_bitmap` which implies that `Klass::is_subtype_of()` may be called on not yet initialized Klass. It that's the case, it does look like a bug on its own. How is it expected to work when `_secondary_supers` hasn't been set yet? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1681571806 From shade at openjdk.org Wed Jul 17 18:52:13 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 18:52:13 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v2] In-Reply-To: References: Message-ID: > [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks. > > We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - More precise barriers - Tests work - More touchups - Fixing the conditions, fixing the tests - Crude prototype, still failing the tests ------------- Changes: https://git.openjdk.org/jdk/pull/20139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=01 Stats: 329 lines in 13 files changed: 328 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139 PR: https://git.openjdk.org/jdk/pull/20139 From kbarrett at openjdk.org Wed Jul 17 18:52:13 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 Jul 2024 18:52:13 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: <1Y2PaVuIsawmIC7NnLuk4I7WLDmHC55dAamEe3M_gOM=.12267ab4-ecaf-4cd7-8f80-b1c6cbf57507@github.com> On Fri, 12 Jul 2024 13:19:31 GMT, Aleksey Shipilev wrote: > > The runtime use of the Access API knows how to resolve an unknown oop ref strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength. However, we do not have support for that in the C2 backend. In fact, it does not understand non-strong oop stores at all. > > Aw, nice usability landmine. I thought C2 barrier set would assert on me if it cannot deliver. Apparently not, [...] Reference.refersTo has similar issues. See refersToImpl and refersTo0 in both Reference and PhantomReference. I think you should be able to model on those and the intrinsic implementation for refersTo to get what you want. One additional complication is that Reference.enqueue intentionally calls clear0. If implementing clear similarly to refersTo, then enqueue should be changed to call clearImpl. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2228872926 From kbarrett at openjdk.org Wed Jul 17 18:52:13 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 Jul 2024 18:52:13 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: <1Y2PaVuIsawmIC7NnLuk4I7WLDmHC55dAamEe3M_gOM=.12267ab4-ecaf-4cd7-8f80-b1c6cbf57507@github.com> References: <1Y2PaVuIsawmIC7NnLuk4I7WLDmHC55dAamEe3M_gOM=.12267ab4-ecaf-4cd7-8f80-b1c6cbf57507@github.com> Message-ID: On Mon, 15 Jul 2024 16:09:39 GMT, Kim Barrett wrote: > > Aw, nice usability landmine. I thought C2 barrier set would assert on me if it cannot deliver. Apparently not, [...] > > Reference.refersTo has similar issues. See refersToImpl and refersTo0 in both Reference and PhantomReference. I think you should be able to model on those and the intrinsic implementation for refersTo to get what you want. > > One additional complication is that Reference.enqueue intentionally calls clear0. If implementing clear similarly to refersTo, then enqueue should be changed to call clearImpl. I should have read what I was replying to more carefully, rather than focusing on what was further up in the thread. Looks like you (@shipilev) already spotted the refersTo stuff. But the enqueue => clear0 could have easily been missed, so perhaps not an entirely unneeded suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2231464762 From shade at openjdk.org Wed Jul 17 18:52:13 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 18:52:13 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: <45m_iZZsJLn9OJowCePyhoipmHYfepPVN7GyrTgaaz0=.52fcb527-3318-4eb6-91e6-09b868e9ea32@github.com> On Fri, 12 Jul 2024 13:19:31 GMT, Aleksey Shipilev wrote: >>> > The reason we did not do this before is that this is not a strong reference store. Strong reference stores with a SATB collector will keep the referent alive, which is typically the exact opposite of what a user wants when they clear a Reference. >>> >>> You mean not doing this store just on the Java side? Yes, I agree, it would be awkward. In intrinsic, we are storing with the same decorators that `JVM_ReferenceClear` is using, which should be good with SATB collectors. Perhaps I am misunderstanding the comment. >> >> The runtime use of the Access API knows how to resolve an unknown oop ref strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength. However, we do not have support for that in the C2 backend. In fact, it does not understand non-strong oop stores at all. Because there hasn't really been a use case for it, other than clearing a Reference. That's the precise reason why we do not have a clear intrinsic; it would have to add that infrastructure. > >> The runtime use of the Access API knows how to resolve an unknown oop ref strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength. However, we do not have support for that in the C2 backend. In fact, it does not understand non-strong oop stores at all. > > Aw, nice usability landmine. I thought C2 barrier set would assert on me if it cannot deliver. Apparently not, I see it just does pre-barriers when it is not sure what strongness the store is. Hrmpf. OK, let me see what can be done here. It might be just easier to further specialize `Reference.clear` in subclasses and carry down the actual strongness, like we do with `refersTo0` currently. This would still require C2 backend adjustments to handle `AS_NO_KEEPALIVE` on stores, but at least we would not have to guess about the strongness type in C2 intrinsic. > I should have read what I was replying to more carefully, rather than focusing on what was further up in the thread. Looks like you (@shipilev) already spotted the refersTo stuff. But the enqueue => clear0 could have easily been missed, so perhaps not an entirely unneeded suggestion. Yeah, thanks. The `enqueue => clear0` was indeed easy to miss. Pushed the crude prototype that follows `refersTo` example and drills some new `AS_NO_KEEPALIVE` holes in C2 Access API to cover this intrinsic case. Super untested. IR tests are still failing, I'll take more in-depth look there. (Perhaps it would not be possible to clearly match the absence of pre-barrier in IR tests, we'll see.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2231613218 From shade at openjdk.org Wed Jul 17 18:52:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 18:52:14 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote: > [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks. > > We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Split out the `refersTo` test to https://github.com/openjdk/jdk/pull/20215. Yeah, so this version seems to work well on tests. I am being extra paranoid about only accepting `null` stores, since `AS_NO_KEEPALIVE` means all other barriers like inter-generational post-barriers in G1 should still work. G1 barrier set delegates the stores to `CardTable/ModRefBarrierSet`, which: a) does not know which barriers can be bypassed by `AS_NO_KEEPALIVE`; b) calls back `G1BarrierSet` for prebarrier generation, but already loses the decorators. So the simplest way to deal with this is to handle this special case specially. I think this is insanely sane, given how sharp-edged `AS_NO_KEEPALIVE` is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2233066721 PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2234005550 From vlivanov at openjdk.org Wed Jul 17 18:57:32 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 17 Jul 2024 18:57:32 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Wed, 17 Jul 2024 18:46:11 GMT, Vladimir Ivanov wrote: >> This is because the C++ runtime does secondary super cache lookups even before the bitmap has been calculated and the hash table sorted. In this case the bitmap is zero, so teh search thinks there are no secondary supers. Setting _bitmap to SECONDARY_SUPERS_BITMAP_FULL forces a linear search. >> >> I guess there might be a better way to do this. Perhaps a comment is needed? >> >> I agree about `_secondary_supers_bitmap` name. > > Now it starts to sound concerning... `Klass::set_secondary_supers()` initializes both `_secondary_supers` and `_bitmap` which implies that `Klass::is_subtype_of()` may be called on not yet initialized Klass. It that's the case, it does look like a bug on its own. How is it expected to work when `_secondary_supers` hasn't been set yet? On a second thought the following setter may be the culprit: void Klass::set_secondary_supers(Array* secondaries) { assert(!UseSecondarySupersTable || secondaries == nullptr, ""); set_secondary_supers(secondaries, SECONDARY_SUPERS_BITMAP_EMPTY); } It should be adjusted to set `SECONDARY_SUPERS_BITMAP_FULL` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1681581587 From uschindler at openjdk.org Wed Jul 17 19:03:34 2024 From: uschindler at openjdk.org (Uwe Schindler) Date: Wed, 17 Jul 2024 19:03:34 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v7] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 15:19:18 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > benchmark review comments Marked as reviewed by uschindler (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/20158#pullrequestreview-2183805940 From liach at openjdk.org Wed Jul 17 19:54:00 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 19:54:00 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field Message-ID: `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. ------------- Commit messages: - 8334772: Change Class::signers to an explicit field Changes: https://git.openjdk.org/jdk/pull/20223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334772 Stats: 71 lines in 6 files changed: 7 ins; 53 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20223/head:pull/20223 PR: https://git.openjdk.org/jdk/pull/20223 From duke at openjdk.org Wed Jul 17 20:03:31 2024 From: duke at openjdk.org (ExE Boss) Date: Wed, 17 Jul 2024 20:03:31 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 18:31:32 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/Process.java line 504: >> >>> 502: return false; >>> 503: >>> 504: return waitForNanos(TimeUnit.NANOSECONDS.convert(duration)); >> >> `waitFor` can be overridden by pre-24 subclasses to provide a better implementation while `waitForNanos` couldn't. Is it reasonable for our default implementation to delegate to `waitFor(long, TimeUnit)` that existing user classes have better implementations for? > >> waitFor can be overridden by pre-24 subclasses to provide a better implementation while ... > > It doesn't really make sense to extend Process, except maybe for mocking or other testing. Process is really for JDK implementations, it's just historical the constructor is public. Just saying that the compatibility concerns with adding methods aren't significant here. This?method needs to?be?overridden in?`test/lib/jdk/test/lib/process/ProcessTools.java` to?call `ProcessTools.ProcessImpl::waitForStreams`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1681655114 From vlivanov at openjdk.org Wed Jul 17 20:37:35 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 17 Jul 2024 20:37:35 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v7] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 15:19:18 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. >> >> Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. >> >> In this PR: >> - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. >> - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. >> - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. >> - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. >> >> I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: >> >> >> Benchmark Threads Mode Cnt Score Error Units >> ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op >> ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op >> ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op >> ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op >> ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op >> ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op >> ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op >> ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op >> ConcurrentClose.sharedAccess 1 avgt 10 ... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > benchmark review comments Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20158#pullrequestreview-2183984622 From liach at openjdk.org Wed Jul 17 20:56:53 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 20:56:53 GMT Subject: RFR: 8336585: BoundAttribute.readEntryList not type-safe Message-ID: Qualify the reading of entry lists with the anticipated types up-front, so we throw the correct `ConstantPoolException` instead of `ClassCastException` when we encounter malformed attribute lists. (`ClassModel.getInterfaces` already behave correctly, in comparison) ------------- Commit messages: - 8336585: BoundAttribute.readEntryList not type-safe Changes: https://git.openjdk.org/jdk/pull/20225/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20225&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336585 Stats: 65 lines in 2 files changed: 43 ins; 8 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20225.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20225/head:pull/20225 PR: https://git.openjdk.org/jdk/pull/20225 From liach at openjdk.org Wed Jul 17 20:56:53 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 20:56:53 GMT Subject: RFR: 8336585: BoundAttribute.readEntryList not type-safe In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 20:51:32 GMT, Chen Liang wrote: > Qualify the reading of entry lists with the anticipated types up-front, so we throw the correct `ConstantPoolException` instead of `ClassCastException` when we encounter malformed attribute lists. (`ClassModel.getInterfaces` already behave correctly, in comparison) test/jdk/jdk/classfile/BoundAttributeTest.java line 87: > 85: ((DirectClassBuilder) clb).writeAttribute(new UnboundAttribute.AdHocAttribute<>(Attributes.nestMembers()) { > 86: @Override > 87: public void writeBody(BufWriter b) { Suggestion: public void writeBody(BufWriterImpl b) { This is a conflict with #20205, whichever is integrated later should update this part. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20225#discussion_r1681721559 From acobbs at openjdk.org Wed Jul 17 21:14:03 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 17 Jul 2024 21:14:03 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater Message-ID: The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. However, while `DeflaterOutputStream` provides constructors that take a custom `Deflator` argument supplied by the caller, `GZIPOutputStream` has no such constructors. As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level. This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`. ------------- Commit messages: - Add a GZIPOutputStream() constructor that takes a Deflator. Changes: https://git.openjdk.org/jdk/pull/20226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4452735 Stats: 139 lines in 2 files changed: 139 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20226/head:pull/20226 PR: https://git.openjdk.org/jdk/pull/20226 From liach at openjdk.org Wed Jul 17 21:37:43 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 21:37:43 GMT Subject: RFR: 8336588: Ensure Transform downstream receives upstream start items only after downstream started Message-ID: There's another bug in ClassFile transform composition where the downstream transform receives items from upstream transform's chained builders before the downstream transform itself starts. This is a simple fix, and a test case against `ClassTransform` is added. ------------- Commit messages: - 8336588: Ensure Transform downstream receives upstream start items only after downstream started Changes: https://git.openjdk.org/jdk/pull/20227/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20227&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336588 Stats: 63 lines in 2 files changed: 49 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20227/head:pull/20227 PR: https://git.openjdk.org/jdk/pull/20227 From naoto at openjdk.org Wed Jul 17 21:41:16 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Jul 2024 21:41:16 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: Message-ID: > Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: ProcessTools overriding one-arg waitFor() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20220/files - new: https://git.openjdk.org/jdk/pull/20220/files/4d2e3fc8..ff3d259c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=00-01 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20220/head:pull/20220 PR: https://git.openjdk.org/jdk/pull/20220 From liach at openjdk.org Wed Jul 17 21:44:32 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 21:44:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 18:28:10 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> ProcessTools overriding one-arg waitFor() > > src/java.base/share/classes/java/lang/Process.java line 481: > >> 479: * this method returns immediately with the value {@code false}. >> 480: * >> 481: *

The default implementation of this method polls the {@code exitValue} > > There was discussion in the CSR on moving this to an `@implSpec`, are you going to do that change? It will be addressed by https://bugs.openjdk.org/browse/JDK-8336679 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1681799258 From naoto at openjdk.org Wed Jul 17 21:44:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Jul 2024 21:44:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: Message-ID: <4H48fwRNYuqbN2QP9v49sJZ7LsrAc__qGMKfnEmwzVY=.c5bd6fbb-628c-49c1-a140-da8dbd94d3f3@github.com> On Wed, 17 Jul 2024 21:39:39 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/Process.java line 481: >> >>> 479: * this method returns immediately with the value {@code false}. >>> 480: * >>> 481: *

The default implementation of this method polls the {@code exitValue} >> >> There was discussion in the CSR on moving this to an `@implSpec`, are you going to do that change? > > It will be addressed by https://bugs.openjdk.org/browse/JDK-8336679 I am planning to add `@implSpec` with a separate issue: [JDK-8336679](https://bugs.openjdk.org/browse/JDK-8336679) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1681801808 From naoto at openjdk.org Wed Jul 17 21:44:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Jul 2024 21:44:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 20:00:18 GMT, ExE Boss wrote: >>> waitFor can be overridden by pre-24 subclasses to provide a better implementation while ... >> >> It doesn't really make sense to extend Process, except maybe for mocking or other testing. Process is really for JDK implementations, it's just historical the constructor is public. Just saying that the compatibility concerns with adding methods aren't significant here. > > This?method needs to?be?overridden in?`test/lib/jdk/test/lib/process/ProcessTools.java` to?call `ProcessTools.ProcessImpl::waitForStreams`. I don't think current `ProcessTools.startProcess()` even calls `waitFor(long, TimeUnit)` let alone `waitFor(Duration)`. It is polling the process by itself to implement timeout. But I agree it is a good measure to add the override there, for the test to use it in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1681801768 From dholmes at openjdk.org Wed Jul 17 22:01:33 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 22:01:33 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 19:47:44 GMT, Chen Liang wrote: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. The relocation of the field to Java looks good. But I am concerned that the field is now exposed to reflection. ------------- PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2184157888 From jkarthikeyan at openjdk.org Wed Jul 17 22:50:31 2024 From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan) Date: Wed, 17 Jul 2024 22:50:31 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Wed, 17 Jul 2024 09:18:31 GMT, Galder Zamarre?o wrote: > Do you want a microbenchmark for the performance of vectorized max/min long? Yeah, I think a simple benchmark that tests for long min/max vectorization and reduction would be good. I worry that checking performance manually like in `ReductionPerf` can lead to harder to interpret results than with a microbenchmark, especially with vm warmup ? Thanks for looking into this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2234515775 From acobbs at openjdk.org Wed Jul 17 23:26:40 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 17 Jul 2024 23:26:40 GMT Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection, Comparator) [v6] In-Reply-To: References: Message-ID: On Thu, 28 Dec 2023 00:09:09 GMT, Valeh Hajiyev wrote: >> This commit addresses the current limitation in the `PriorityQueue` implementation, which lacks a constructor to efficiently create a priority queue with a custom comparator and an existing collection. In order to create such a queue, we currently need to initialize a new queue with custom comparator, and after that populate the queue using `addAll()` method, which in the background calls `add()` method (which takes `O(logn)` time) for each element of the collection (`n` times). This is resulting in an overall time complexity of `O(nlogn)`. >> >> >> PriorityQueue pq = new PriorityQueue<>(customComparator); >> pq.addAll(existingCollection); >> >> >> The pull request introduces a new constructor to streamline this process and reduce the time complexity to `O(n)`. If you create the queue above using the new constructor, the contents of the collection will be copied (which takes `O(n)` time) and then later `heapify()` operation (Floyd's algorithm) will be called once (another `O(n)` time). Overall the operation will be reduced from `O(nlogn)` to `O(2n)` -> `O(n)` time. >> >> >> PriorityQueue pq = new PriorityQueue<>(existingCollection, customComparator); > > Valeh Hajiyev has updated the pull request incrementally with one additional commit since the last revision: > > fix style Hmm. Why did this PR expire without further action? Are there any remaining blockers (other than it still needs a CSR and a review)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-2234671764 From liach at openjdk.org Wed Jul 17 23:51:40 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Jul 2024 23:51:40 GMT Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection, Comparator) [v6] In-Reply-To: References: <1C_qA3n7rwerTQGNq6H7OEY1FXAW5s4ZDRjDouRN-7U=.1ed642a0-b40e-4edf-86d1-de43d6026e5c@github.com> Message-ID: On Thu, 4 Jan 2024 15:34:03 GMT, Jason Mehrens wrote: >>> > I think this ticket should focus on adding the new constructor as part of the API. >>> >>> Okay. I would think the code would avoid heapify when the caller does foolish things with this API such as: >>> >>> ``` >>> SortedSet ss = filledSortedSet(); >>> PriorityQueue pq1 = new PriorityQueue(ss.comparator(), ss); >>> >>> PriorityQueue pq = filledPriorityQueue(); >>> PriorityQueue pq2 = new PriorityQueue(pq.comparator(), pq); >>> ``` >>> >>> I assume this constructor is going to be added to TreeSet, PriorityBlockingQueue, and ConcurrentSkipListSet? >> >> why do you think the code would avoid heapify? `initFromCollection` method will be called regardless of the type of the collection passed, which will heapify the queue. >> >> regarding adding the constructor to the other types mentioned, I believe I can be done, probably as part of a different ticket. > >> why do you think the code would avoid heapify? `initFromCollection` method will be called regardless of the type of the collection passed, which will heapify the queue. > > I simply mean to point out: > > 1. That if the given comparator and the sortedset/priority queue comparator are the same then the call to heapify should be avoided as this is what is done in the [copy constructor.](https://github.com/openjdk/jdk/blob/139abc453f9eeeb4763076298ec44573ab94a3b6/src/java.base/share/classes/java/util/PriorityQueue.java#L196) > 2. This new API has an anti-pattern not present with the other constructors. I think it's that @jmehrens arguing that the "set of constructors" should be settled and there shouldn't be more or less, like > This new API has an anti-pattern not present with the other constructors. In all honesty, our collection API docs is massively outdated, that we haven't even documented SequencedCollection since JDK 21; those "constructor parity" arguments are relics of the age of serialization and can be safely discarded. > I assume this constructor is going to be added to TreeSet, PriorityBlockingQueue, and ConcurrentSkipListSet? Feel free to. If you submit a patch, we are more than glad to review it. An overhaul ("anti-pattern" in @jmehrens' words) caused by doing the right thing is not a reason not to do so. ----------------- @archiecobbs You are right. I will create a CSR for this patch. Hope the original author can come back (just issue `/open` in a comment and bot will reopen PR), otherwise we can probably add such comparator+copy constructors to all these ordered collections. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-2234768805 From liach at openjdk.org Thu Jul 18 00:03:48 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 00:03:48 GMT Subject: RFR: 6356745: (coll) Add PriorityQueue(Collection, Comparator) [v6] In-Reply-To: References: <1C_qA3n7rwerTQGNq6H7OEY1FXAW5s4ZDRjDouRN-7U=.1ed642a0-b40e-4edf-86d1-de43d6026e5c@github.com> Message-ID: On Thu, 4 Jan 2024 14:21:54 GMT, Valeh Hajiyev wrote: >>>I think this ticket should focus on adding the new constructor as part of the API. >> >> Okay. I would think the code would avoid heapify when the caller does foolish things with this API such as: >> >> SortedSet ss = filledSortedSet(); >> PriorityQueue pq1 = new PriorityQueue(ss.comparator(), ss); >> >> PriorityQueue pq = filledPriorityQueue(); >> PriorityQueue pq2 = new PriorityQueue(pq.comparator(), pq); >> >> >> I assume this constructor is going to be added to TreeSet, PriorityBlockingQueue, and ConcurrentSkipListSet? > >> > I think this ticket should focus on adding the new constructor as part of the API. >> >> Okay. I would think the code would avoid heapify when the caller does foolish things with this API such as: >> >> ``` >> SortedSet ss = filledSortedSet(); >> PriorityQueue pq1 = new PriorityQueue(ss.comparator(), ss); >> >> PriorityQueue pq = filledPriorityQueue(); >> PriorityQueue pq2 = new PriorityQueue(pq.comparator(), pq); >> ``` >> >> I assume this constructor is going to be added to TreeSet, PriorityBlockingQueue, and ConcurrentSkipListSet? > > why do you think the code would avoid heapify? `initFromCollection` method will be called regardless of the type of the collection passed, which will heapify the queue. > > regarding adding the constructor to the other types mentioned, I believe I can be done, probably as part of a different ticket. I have created a CSR. @valeh feel free to come back and reopen this with `/reopen` command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17045#issuecomment-2234811170 From liach at openjdk.org Thu Jul 18 00:07:35 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 00:07:35 GMT Subject: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Should I no longer require 2 reviewers and integrate this patch, or should I wait for someone else? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20178#issuecomment-2234824700 From duke at openjdk.org Thu Jul 18 00:52:17 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 00:52:17 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v6] In-Reply-To: References: Message-ID: > [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. Shaojin Wen 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 14 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into merge_store_bench - Merge remote-tracking branch 'upstream/master' into merge_store_bench - bug fix for `putChars4C` - bug fix for `putChars4C` and `putChars4S` - use VarHandler CHAR_L & CHAR_B - copyright - bug fix for putIntBU - add cases for `getChar` & `putChar` - code format - add `setIntRL` & `setIntRLU` - ... and 4 more: https://git.openjdk.org/jdk/compare/e106b332...74f8837c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19734/files - new: https://git.openjdk.org/jdk/pull/19734/files/4c9b9418..74f8837c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=04-05 Stats: 48962 lines in 1282 files changed: 31836 ins; 11059 del; 6067 mod Patch: https://git.openjdk.org/jdk/pull/19734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19734/head:pull/19734 PR: https://git.openjdk.org/jdk/pull/19734 From duke at openjdk.org Thu Jul 18 00:58:04 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 00:58:04 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v14] In-Reply-To: References: Message-ID: > After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. > > This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2. Shaojin Wen 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 15 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406 - private static final field `UNSAFE` - Utf16 case remove `append first utf16 char` - `delete` -> `setLength` - copyright 2024 - optimization for x64 - rename benchmark - code format & use long address - fix assert - StringLatin1 & StringUTF16 use the same logic - ... and 5 more: https://git.openjdk.org/jdk/compare/a8ed2eb7...7563577c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19626/files - new: https://git.openjdk.org/jdk/pull/19626/files/6be002ac..7563577c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=12-13 Stats: 65489 lines in 1836 files changed: 38953 ins; 18739 del; 7797 mod Patch: https://git.openjdk.org/jdk/pull/19626.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626 PR: https://git.openjdk.org/jdk/pull/19626 From lmesnik at openjdk.org Thu Jul 18 01:07:34 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Jul 2024 01:07:34 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: <4p89Ssr0eLRG23x49tu4qY51hB6jbnz-r1ZknrJZc54=.830ad843-f3ac-4b60-8efe-a82d4488676f@github.com> On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19864#pullrequestreview-2184371193 From syan at openjdk.org Thu Jul 18 02:29:36 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 02:29:36 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Thanks for the review and approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235174531 From duke at openjdk.org Thu Jul 18 02:29:36 2024 From: duke at openjdk.org (duke) Date: Thu, 18 Jul 2024 02:29:36 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. @sendaoYan Your change (at version a7c1d63434bbb24122f4256cb695129afac70804) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235175938 From duke at openjdk.org Thu Jul 18 03:36:43 2024 From: duke at openjdk.org (duke) Date: Thu, 18 Jul 2024 03:36:43 GMT Subject: Withdrawn: 8331196: vector api: Remove unnecessary index check in Byte/ShortVector.fromArray/fromArray0Template In-Reply-To: References: Message-ID: On Fri, 26 Apr 2024 14:06:02 GMT, Hamlin Li wrote: > Hi, > Can you help to review this simple patch? > Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed. > Thanks This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18977 From jpai at openjdk.org Thu Jul 18 05:13:32 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 05:13:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: Message-ID: <4rizsae0Hyr0jR9RaSZVNmvwYBIFwZnSSu5Cgszvry0=.c13d8192-73a7-45df-8cc7-10d940dacd80@github.com> On Wed, 17 Jul 2024 21:41:16 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > ProcessTools overriding one-arg waitFor() src/java.base/share/classes/java/lang/Process.java line 501: > 499: if (hasExited()) > 500: return true; > 501: if (duration.isZero() || duration.isNegative()) Hello Naoto, I see that there's a `Duration.isPositive()` API. Should we use that here instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1682126873 From jpai at openjdk.org Thu Jul 18 05:19:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 05:19:31 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 21:41:16 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > ProcessTools overriding one-arg waitFor() src/java.base/share/classes/java/lang/Process.java line 499: > 497: Objects.requireNonNull(duration, "duration"); // throw NPE before other conditions > 498: > 499: if (hasExited()) For clarity, the javadoc on the private internal `hasExited()` method might need an update - it currently states that the method will be invoked from `waitFor(long, TimeUnit)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1682133588 From jpai at openjdk.org Thu Jul 18 05:27:32 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 05:27:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 21:41:16 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > ProcessTools overriding one-arg waitFor() test/jdk/java/lang/Process/WaitForDuration.java line 57: > 55: throws IOException, InterruptedException { > 56: assertEquals(expected, > 57: new ProcessBuilder("sleep", "3").start().waitFor(d)); I think in its current form, this has a chance of failure (for inputs like 0 or negative duration), if the sleep (for 3 seconds) completes (and thus the process exits) before the `Process.waitFor` implementation has had a chance to execute `hasExited()`. Also, this test is marked to run on all platforms. I think we might need special handling for `sleep` executable on Windows. In fact, looking at the `initSleepPath` in the `test/jdk/java/lang/ProcessBuilder/Basic.java` test, I suspect we might need something similar in this test even for *nix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1682143756 From duke at openjdk.org Thu Jul 18 05:28:56 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 05:28:56 GMT Subject: RFR: 8336706: Optimize LocalDate.toString with StringBuilder.repeat Message-ID: class LocalDate { public String toString() { if (absYear < 1000) { if (yearValue < 0) { buf.append(yearValue - 10000).deleteCharAt(1); } else { buf.append(yearValue + 10000).deleteCharAt(0); } // ... } } Currently, LocalDate.toString causes an extra memory copy when processing years < 1000. This can be replaced by using StringBuilder.repeat, which is more concise and has better performance. ------------- Commit messages: - use StringBuilder#repeat append zeros Changes: https://git.openjdk.org/jdk/pull/20229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336706 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20229/head:pull/20229 PR: https://git.openjdk.org/jdk/pull/20229 From jpai at openjdk.org Thu Jul 18 05:55:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 05:55:31 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. Hello @sendaoYan, after changes in JDK-8294960, there were a couple of issues reported. From what I see in the linked issues, Adam reviewed those and integrated relevant fixes. In JDK-8334771 you note: > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. So I think we should have this increase in memory reviewed by @asotona or someone familiar in that area, before deciding whether these tests should be changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235607869 From duke at openjdk.org Thu Jul 18 06:08:46 2024 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Thu, 18 Jul 2024 06:08:46 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) delay due to holidays and vacations ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2235695610 From alanb at openjdk.org Thu Jul 18 06:24:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 06:24:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: <4H48fwRNYuqbN2QP9v49sJZ7LsrAc__qGMKfnEmwzVY=.c5bd6fbb-628c-49c1-a140-da8dbd94d3f3@github.com> References: <4H48fwRNYuqbN2QP9v49sJZ7LsrAc__qGMKfnEmwzVY=.c5bd6fbb-628c-49c1-a140-da8dbd94d3f3@github.com> Message-ID: On Wed, 17 Jul 2024 21:42:17 GMT, Naoto Sato wrote: >> It will be addressed by https://bugs.openjdk.org/browse/JDK-8336679 > > I am planning to add `@implSpec` with a separate issue: [JDK-8336679](https://bugs.openjdk.org/browse/JDK-8336679) Okay, just a bit strange to add waitFor(Duration) here and then follow-up immediately to change it to move the text to an implSpec, I had hoped it would be done here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1682258197 From syan at openjdk.org Thu Jul 18 06:26:31 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 06:26:31 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 05:52:51 GMT, Jaikiran Pai wrote: > So I think we should have this increase in memory reviewed by @asotona or someone familiar in that area, before deciding whether these tests should be changed. Okey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235717028 From asotona at openjdk.org Thu Jul 18 07:34:38 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 18 Jul 2024 07:34:38 GMT Subject: RFR: 8336585: BoundAttribute.readEntryList not type-safe In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 20:51:32 GMT, Chen Liang wrote: > Qualify the reading of entry lists with the anticipated types up-front, so we throw the correct `ConstantPoolException` instead of `ClassCastException` when we encounter malformed attribute lists. (`ClassModel.getInterfaces` already behave correctly, in comparison) Looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20225#pullrequestreview-2184963817 From asotona at openjdk.org Thu Jul 18 07:38:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 18 Jul 2024 07:38:33 GMT Subject: RFR: 8336588: Ensure Transform downstream receives upstream start items only after downstream started In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 21:31:51 GMT, Chen Liang wrote: > There's another bug in ClassFile transform composition where the downstream transform receives items from upstream transform's chained builders before the downstream transform itself starts. This is a simple fix, and a test case against `ClassTransform` is added. Good catch and fix, thanks. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20227#pullrequestreview-2184970902 From sspitsyn at openjdk.org Thu Jul 18 08:42:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Jul 2024 08:42:32 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 05:58:18 GMT, David Holmes wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > src/java.base/share/classes/java/lang/VirtualThread.java line 273: > >> 271: // current thread is a ForkJoinWorkerThread so the task will be pushed >> 272: // to the local queue. For other schedulers, it avoids deadlock that >> 273: // would arise due to platform and virtual threads contenting for a > > s/contenting/contending/ Also noticed this typo. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682450204 From sspitsyn at openjdk.org Thu Jul 18 08:48:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Jul 2024 08:48:32 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Looks okay. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19864#pullrequestreview-2185137791 From syan at openjdk.org Thu Jul 18 09:08:32 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 09:08:32 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 08:45:43 GMT, Serguei Spitsyn wrote: > Looks okay. I agree this needs to be reviewed by @asotona . Thanks for the review. I will wait reviewed by @asotona before integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236003849 From asotona at openjdk.org Thu Jul 18 09:15:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 18 Jul 2024 09:15:32 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Unfortunately I'm not familiar with these tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236018675 From alanb at openjdk.org Thu Jul 18 09:43:33 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 09:43:33 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 19:47:44 GMT, Chen Liang wrote: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. Signers dates back to JDK 1.1, touching it now will shine light on long standing technical debt and other issues. I think the main thing that is jumping out is that ClassLoader.setSigners (protected final method so may be called in subclasses) isn't fully specified and it is also missing a number of important checks. The method doesn't specify that the method ignores array classes or class objects for primitives. It doesn't say anything about the elements that aren't a Certificate are ignored. It doesn't specify null behavior either and doesn't say anything that the signers can change at any time. What's worse is that in the hands of a cowboy builder, it can be used to set or clear the signers for any Class, or keep a reference to the signers array and muck with them mid-flight. So lots of issues there. Technical debt aside, I think the transformation looks okay, just a bit confusing to have signers declared under a comment "Set by VM", it's not clear the comment applies only to the classData before it. At some point I think we should put a question mark on the JVMTI JVMTI_HEAP_REFERENCE_SIGNERS heap ref and the HPROF heap dump CLASS record where there is a slot for the signers array. I don't see any need for these in 2024 and could be potentially be null'ed in the future (would require a JVM TI spec change of course). On David's comment about exposing the field to code using Class.getDecalredField or Class.getDeclaredFields. Nosy code can use these methods to get a reference to the Field but it's not accessible by default. For now, code can using sun.misc.Unsafe but that is temporary and will go away. I don't have a strong opinion and no objection to adding it to the filter (which I think is what David is wondering about). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20223#issuecomment-2236065493 From sspitsyn at openjdk.org Thu Jul 18 10:55:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Jul 2024 10:55:32 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 Q: There are some new files with a copyright year ranges. They are probably renamed files. Should their copyright years be updated? test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 1113: > 1111: @Test > 1112: void testYield3() throws Exception { > 1113: assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers"); Q: What was the reason to rename `testYield2()` to `testYield3()`? test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 72: > 70: System.out.format("Result: %d in %s ms%n", sum, (end-start)); > 71: if (sum != expected) > 72: throw new RuntimeException("Expected " + expected); Nit: This probably needs a copyright update. ------------- PR Review: https://git.openjdk.org/jdk/pull/20143#pullrequestreview-2185389469 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682627996 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682604568 From jvernee at openjdk.org Thu Jul 18 11:03:40 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 18 Jul 2024 11:03:40 GMT Subject: Integrated: 8335480: Only deoptimize threads if needed when closing shared arena In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 13:57:23 GMT, Jorn Vernee wrote: > This PR limits the number of cases in which we deoptimize frames when closing a shared Arena. The initial intent of this was to improve the performance of shared arena closure in cases where a lot of threads are accessing and closing shared arenas at the same time (see attached benchmark), but unfortunately even disabling deoptimization altogether does not have a great effect on that benchmark. > > Nevertheless, I think the extra logging/testing/benchmark code, and comments I've written, together with reducing the number of cases where we deoptimize (which makes it clearer exactly why we need to deoptimize in the first place), will be useful going forward. So, I've a create this PR out of them. > > In this PR: > - Deoptimizing is now only done in cases where it's needed, instead of always. Which is in cases where we are not inside an `@Scoped` method, but are inside a compiled frame that has a scoped access somewhere inside of it. > - I've separated the stack walking code (`for_scope_method`) from the code that checks for a reference to the arena being closed (`is_accessing_session`), and added logging code to the former. That also required changing vframe code to accept an `ouputStream*` rather than always printing to `tty`. > - Added a new test (`TestConcurrentClose`), that tries to close many shared arenas at the same time, in order to stress that use case. > - Added a new benchmark (`ConcurrentClose`), that stresses the cases where many threads are accessing and closing shared arenas. > > I've done several benchmark runs with different amounts of threads. The confined case stays much more consistent, while the shared cases balloons up in time spent quickly when there are more than 4 threads: > > > Benchmark Threads Mode Cnt Score Error Units > ConcurrentClose.sharedAccess 32 avgt 10 9017.397 ? 202.870 us/op > ConcurrentClose.sharedAccess 24 avgt 10 5178.214 ? 164.922 us/op > ConcurrentClose.sharedAccess 16 avgt 10 2224.420 ? 165.754 us/op > ConcurrentClose.sharedAccess 8 avgt 10 593.828 ? 8.321 us/op > ConcurrentClose.sharedAccess 7 avgt 10 470.700 ? 22.511 us/op > ConcurrentClose.sharedAccess 6 avgt 10 386.697 ? 59.170 us/op > ConcurrentClose.sharedAccess 5 avgt 10 291.157 ? 7.023 us/op > ConcurrentClose.sharedAccess 4 avgt 10 209.178 ? 5.802 us/op > ConcurrentClose.sharedAccess 1 avgt 10 52.042 ? 0.630 us/op > ConcurrentClose.conf... This pull request has now been integrated. Changeset: 7bf53132 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/7bf531324404419e7de3e83e245d351e1a4e4499 Stats: 482 lines in 20 files changed: 393 ins; 19 del; 70 mod 8335480: Only deoptimize threads if needed when closing shared arena Reviewed-by: mcimadamore, kvn, uschindler, vlivanov, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/20158 From alanb at openjdk.org Thu Jul 18 11:06:33 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 11:06:33 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 10:46:16 GMT, Serguei Spitsyn wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 1113: > >> 1111: @Test >> 1112: void testYield3() throws Exception { >> 1113: assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers"); > > Q: What was the reason to rename `testYield2()` to `testYield3()`? There are a lot of tests that can't be proposed to main line at this time because they depend on the object monitor work. This is one such "gap" where testYield2 can't be added. I can re-number them if you want to avoid the gap but there are other changes that rename several test methods so I'd prefer to leave it until then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682651423 From alanb at openjdk.org Thu Jul 18 11:20:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 11:20:32 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 10:52:43 GMT, Serguei Spitsyn wrote: > Q: There are some new files with a copyright year ranges. I will check but there are a few renames that have to keep the initial year. Also there are some new files that have been checked into the loom repo for a long time so they have their initial year too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20143#issuecomment-2236251273 From liach at openjdk.org Thu Jul 18 11:26:32 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 11:26:32 GMT Subject: RFR: 8336706: Optimize LocalDate.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 05:21:36 GMT, Shaojin Wen wrote: > class LocalDate { > public String toString() { > if (absYear < 1000) { > if (yearValue < 0) { > buf.append(yearValue - 10000).deleteCharAt(1); > } else { > buf.append(yearValue + 10000).deleteCharAt(0); > } > // ... > } > } > > Currently, LocalDate.toString causes an extra memory copy when processing years < 1000. This can be replaced by using StringBuilder.repeat, which is more concise and has better performance. Looks good to me; another engineer in the area should take a look too. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20229#pullrequestreview-2185544132 From rkennke at openjdk.org Thu Jul 18 11:33:40 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 18 Jul 2024 11:33:40 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/lightweightSynchronizer.cpp line 77: > 75: using ConcurrentTable = ConcurrentHashTable; > 76: > 77: ConcurrentTable* _table; So you have a class ObjectMonitorWorld, which references the ConcurrentTable, which, internally also has its actual table. This is 3 dereferences to get to the actual table, if I counted correctly. I'd try to eliminate the outermost ObjectMonitorWorld class, or at least make it a global flat structure instead of a reference to a heap-allocated object. I think, because this is a structure that is global and would exist throughout the lifetime of the Java program anyway, it might be worth figuring out how to do the actual ConcurrentHashTable flat in the global structure, too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1682682065 From duke at openjdk.org Thu Jul 18 11:41:41 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 11:41:41 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat Message-ID: class LocalTime { public String toString() { // ... if (nanoValue % 1000_000 == 0) { buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); } else if (nanoValue % 1000 == 0) { buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); } else { buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); } // ... } } Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. ------------- Commit messages: - use StringBuilder#repeat append zeros Changes: https://git.openjdk.org/jdk/pull/20232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336741 Stats: 14 lines in 1 file changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20232/head:pull/20232 PR: https://git.openjdk.org/jdk/pull/20232 From syan at openjdk.org Thu Jul 18 11:44:34 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 11:44:34 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. > Unfortunately I'm not familiar with these tests. > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. Can you confirm that the codecache usage increased is expected or not after [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) with -Xcomp jvm option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236291264 From liach at openjdk.org Thu Jul 18 11:49:32 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 11:49:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: References: <4H48fwRNYuqbN2QP9v49sJZ7LsrAc__qGMKfnEmwzVY=.c5bd6fbb-628c-49c1-a140-da8dbd94d3f3@github.com> Message-ID: On Thu, 18 Jul 2024 06:22:25 GMT, Alan Bateman wrote: >> I am planning to add `@implSpec` with a separate issue: [JDK-8336679](https://bugs.openjdk.org/browse/JDK-8336679) > > Okay, just a bit strange to add waitFor(Duration) here and then follow-up immediately to change it to move the text to an implSpec, I had hoped it would be done here. I believe the choice was made because both waitFor methods need this documentation update; better not touch the (long,TimeUnit) one in this patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1682701574 From coleenp at openjdk.org Thu Jul 18 12:32:31 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Jul 2024 12:32:31 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 19:47:44 GMT, Chen Liang wrote: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. I thought we moved this already. There's a change in the heapDumper.cpp that probably has to change also, because I think we're now dumping signers twice (two lines). The one in jvmtiTagMap.cpp reports the SIGNERS tag so that has to stay. ------------- PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2185676651 From liach at openjdk.org Thu Jul 18 12:40:32 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 12:40:32 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field In-Reply-To: References: Message-ID: <5gvvLeGQfl_OU3uY4P2QTYTXDxZTt5-INzv-Yt4mpRM=.a49d4d77-793a-46f0-90cb-d219af508f37@github.com> On Wed, 17 Jul 2024 19:47:44 GMT, Chen Liang wrote: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. The `native` flag is not rendered in API spec, so indeed we can drop without a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20223#issuecomment-2236359362 From alanb at openjdk.org Thu Jul 18 12:46:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 12:46:31 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 12:30:24 GMT, Coleen Phillimore wrote: > There's a change in the heapDumper.cpp that probably has to change also, because I think we're now dumping signers twice (two lines). The HPROF heap dump has a slot for signers so have to keep that to avoid breakage. So yes, it means two refs as the signers will be in the instance fields list too. The HPROF format could be rev'ed but may not be worth it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20223#issuecomment-2236404312 From duke at openjdk.org Thu Jul 18 12:49:53 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 12:49:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v31] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimized the square root's computation for long values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/a23cdef3..ebdd6d2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=29-30 Stats: 15 lines in 1 file changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Thu Jul 18 13:09:08 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 13:09:08 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v32] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Uniforming the computation of long values' square root ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/ebdd6d2d..3d8a913a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=30-31 Stats: 45 lines in 1 file changed: 21 ins; 22 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From coleenp at openjdk.org Thu Jul 18 13:09:34 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Jul 2024 13:09:34 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 19:47:44 GMT, Chen Liang wrote: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. Ok. It's not obvious from the code but I don't think it's worth commenting. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2185765767 From liach at openjdk.org Thu Jul 18 13:14:34 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 13:14:34 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: <6C5OhnxXXPNycBd3eWG4W8UY3wydDDe5dGT93Z29K0k=.fa6d463e-7419-4a57-9b18-5477f50bc575@github.com> On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. Looking at #20229, can we create another utility method in jdk.internal like in `DecimalDigits` to append to a StringBuilder a decimal output with a given field width? Like public static void printFixedWidth(StringBuilder sb, int width, int value) { var size = JLA.stringSize(value); sb.repeat('0', width - size); sb.append(value); } And call this in `LocalTime` `LocalDate` `Formatter` etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236463542 From liach at openjdk.org Thu Jul 18 13:31:02 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 13:31:02 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field [v2] In-Reply-To: References: Message-ID: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Reorder comment of classData to avoid misunderstanding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20223/files - new: https://git.openjdk.org/jdk/pull/20223/files/86b3a248..dd62b9d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20223&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20223&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20223/head:pull/20223 PR: https://git.openjdk.org/jdk/pull/20223 From alanb at openjdk.org Thu Jul 18 13:36:33 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 13:36:33 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field [v2] In-Reply-To: References: Message-ID: <2ZVM5wAKjhLfFx4CFBSyQ7yND6VIsMcNTxRubvcuXps=.c511f719-746a-4c01-b744-82f1f2b3619f@github.com> On Thu, 18 Jul 2024 13:31:02 GMT, Chen Liang wrote: >> `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) >> >> Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Reorder comment of classData to avoid misunderstanding Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2185842171 From rgiulietti at openjdk.org Thu Jul 18 13:43:38 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 13:43:38 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: References: Message-ID: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> On Wed, 17 Jul 2024 15:33:39 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > More accurate comment src/java.base/share/classes/java/math/MutableBigInteger.java line 1973: > 1971: > 1972: /* For every long value s in [0, 2^32) such that x == s * s, > 1973: * it is true that s == Math.round(Math.sqrt(x >= 0 ? x : x + 0x1p64)), To reinforce this claim, I suggest to add a test for all perfect squares. src/java.base/share/classes/java/math/MutableBigInteger.java line 1975: > 1973: * it is true that s == Math.round(Math.sqrt(x >= 0 ? x : x + 0x1p64)), > 1974: * and if x == 2^64 - 1, then Math.round(Math.sqrt(x >= 0 ? x : x + 0x1p64)) == 2^32. > 1975: * This means that the value returned by Math.round(Math.sqrt()) Suggestion: * Since both `Math.round()` and `Math.sqrt()` are (weakly) increasing, * this means that the value returned by `Math.round(Math.sqrt())` src/java.base/share/classes/java/math/MutableBigInteger.java line 2041: > 2039: > 2040: // Allocate sufficient space to hold the normalized final square root > 2041: MutableBigInteger sqrt = new MutableBigInteger(new int[(intLen + ((-intLen) & 3)) >> 1]); Rather than expecting the reader to stop for some minutes to figure out what's happening with the arithmetic here, add a comment or prefer Suggestion: MutableBigInteger sqrt = new MutableBigInteger(new int[2 * Math.ceilDiv(intLen, 4)]); src/java.base/share/classes/java/math/MutableBigInteger.java line 2077: > 2075: sqrt.shiftAdd(q, blockLen); > 2076: > 2077: MutableBigInteger chunk = u; // Corresponds to ub + a_0 in the paper As observed in the past, there seems to be no point in having `chunk`, which is just an alias for `u`. You can use `u` directly. src/java.base/share/classes/java/math/MutableBigInteger.java line 2128: > 2126: > 2127: /** > 2128: * Returns a {@code MutableBigInteger} obtained taking {@code blockLen} ints from Suggestion: * Returns a {@code MutableBigInteger} obtained by taking {@code blockLen} ints from src/java.base/share/classes/java/math/MutableBigInteger.java line 2135: > 2133: * @param limit the offset which is the end of valid words in the input value > 2134: * @param blockLen the length of the block in units of 32 bits > 2135: */ At first, I couldn't understand that `blockIndex` goes in the opposite direction as the array indices. Also, "starting" is very confusing, because no `int` at `blockIndex*blockLen` gets copied AFAIU. Two improvements: * Add a `@return` tag. Alternatively, use comments other than JavaDoc `/**`. * Make it explicit that the direction of `blockIndex` is the opposite of the array indices, and reconsider the wording like "starting", etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682861205 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682861681 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682862246 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682862627 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682862962 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682863810 From liach at openjdk.org Thu Jul 18 13:48:06 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 13:48:06 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field [v3] In-Reply-To: References: Message-ID: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. 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: - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-signers - Reorder comment of classData to avoid misunderstanding - 8334772: Change Class::signers to an explicit field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20223/files - new: https://git.openjdk.org/jdk/pull/20223/files/dd62b9d2..5d742e34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20223&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20223&range=01-02 Stats: 779 lines in 28 files changed: 676 ins; 29 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/20223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20223/head:pull/20223 PR: https://git.openjdk.org/jdk/pull/20223 From duke at openjdk.org Thu Jul 18 13:54:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 13:54:31 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: <9r0edJqOv6K61Wy4F1mjLPRRXKSEtuC-us_mqUWxFCQ=.590877c9-9cde-4b43-a543-037f1b3f0b53@github.com> On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. printFixedWidth cannot meet the needs of append nanos, For example, if the value is 1000, the output is `.000001`, not `.000001000` ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236588022 From liach at openjdk.org Thu Jul 18 14:00:33 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 14:00:33 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. This particular usage can become: buf.append('.'); if (nanoValue % 1000_000 == 0) { printFixedWidth(buf, 3, nanoValue / 1000_000); } else if (nanoValue % 1000 == 0) { printFixedWidth(buf, 6, nanoValue / 1000); } else { printFixedWidth(buf, 9, nanoValue); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236600615 From sgehwolf at openjdk.org Thu Jul 18 14:00:38 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 18 Jul 2024 14:00:38 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v14] In-Reply-To: <_hcyal491UTTWXj9TeVmrn7yv-nOqkdoC7WKhiSj64k=.1b5c5e06-e467-4dc9-bc6f-34c7ae573777@github.com> References: <_hcyal491UTTWXj9TeVmrn7yv-nOqkdoC7WKhiSj64k=.1b5c5e06-e467-4dc9-bc6f-34c7ae573777@github.com> Message-ID: On Mon, 15 Jul 2024 07:02:11 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Fix by Severin Gehwolf. >> Testcase by Jan Kratochvil. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > Fix a needless whitespace change Sorry I cannot review my own patch. You'd need somebody else to help review it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2236600764 From asotona at openjdk.org Thu Jul 18 14:08:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 18 Jul 2024 14:08:33 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. I can confirm [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) had effect on JDK bootstrap (benchmarked and discussed in https://github.com/openjdk/jdk/pull/17108 ). And there might be measurable differences in various benchmarks sensitive to JDK bootstrap. However I cannot confirm the numbers above, simply because I do not know what they represent. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236630582 From duke at openjdk.org Thu Jul 18 14:16:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 14:16:34 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. DateTimeFormatterBuilder uses DecimalStyle.getZeroDigit(), and printFixedWidth does not meet the requirements. The scenario where LocalDate.toString handles Year is very simple, and repeat can be used directly. printFixedWidth requires three different calls in LocalTime.toString. Is there a good reason to extract it into a public method? I do not reject this approach, but I do not fully support it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236644193 From rriggs at openjdk.org Thu Jul 18 14:16:35 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Jul 2024 14:16:35 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: <1pAFiC1qceCxkVi_mhf9q9DvfULpe0YBINoRQP_bMzg=.e96cb997-3591-4511-ba4b-38145e2f7f37@github.com> On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. The "better performance" claim is unsubstantiated. By how much. The change introduces non-local dependencies that make the code harder to follow. (Shared secrets). In a typical application, the improvement would not be noticeable and makes the code harder to maintain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236646939 From duke at openjdk.org Thu Jul 18 14:30:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 14:30:31 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. The current logic of adding a value and then substring(1) is not clear, and this approach is not elegant at all. I think the logic of changing to repeat('0') is concise and clear. Using repeat implementation will reduce two object allocations, Integer.toString & subString(1), and the time consumption will be 1/3 of the original. If JLA is not recommended, we can add a stringSize method in LocalTime, similar to DateTimeFormatterBuilder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236698626 From liach at openjdk.org Thu Jul 18 14:37:31 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 14:37:31 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. It seems that `DecimalDigit.size` was accidentally removed in 03e84178ebfd2ca48b89d65d8f3c291e0c622fb5. You are welcome to add it back and drop the dependency on `JavaLangAccess`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236739524 From duke at openjdk.org Thu Jul 18 14:41:37 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 14:41:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> Message-ID: On Thu, 18 Jul 2024 13:39:01 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> More accurate comment > > src/java.base/share/classes/java/math/MutableBigInteger.java line 1973: > >> 1971: >> 1972: /* For every long value s in [0, 2^32) such that x == s * s, >> 1973: * it is true that s == Math.round(Math.sqrt(x >= 0 ? x : x + 0x1p64)), > > To reinforce this claim, I suggest to add a test for all perfect squares. I did it, although I'm afraid it takes up too much running time due to the overhead of BigInteger's wrapping... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682972234 From jkratochvil at openjdk.org Thu Jul 18 14:48:02 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 18 Jul 2024 14:48:02 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v15] In-Reply-To: References: Message-ID: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> > The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: Unify 4 copies of adjust_controller() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17198/files - new: https://git.openjdk.org/jdk/pull/17198/files/82db527b..fc17369c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=13-14 Stats: 203 lines in 4 files changed: 43 ins; 139 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From jkratochvil at openjdk.org Thu Jul 18 14:48:02 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 18 Jul 2024 14:48:02 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12] In-Reply-To: References: <1oAMxRMmq_ImX33Zelz2lKCQj1_uiwEw0WcPBAkvg-w=.0b0294c1-3282-48cd-a215-43a072dd0cea@github.com> Message-ID: On Fri, 12 Jul 2024 13:12:11 GMT, Severin Gehwolf wrote: > There ought to be a way to remove the duplication between cgv1 and cgv2's impl of `adjust_controller()` but I haven't spent time on that. I have tied to implemented but I am fine to drop it if you don't like it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2236763968 From rriggs at openjdk.org Thu Jul 18 14:49:39 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Jul 2024 14:49:39 GMT Subject: RFR: 8334394: Race condition in Class::protectionDomain [v2] In-Reply-To: References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> Message-ID: On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote: >> Make sure `pd` is always the same object when `getProtectionDomain0` is null. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > explain why the test is related to the fix lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19752#pullrequestreview-2186068679 From rgiulietti at openjdk.org Thu Jul 18 14:52:36 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 14:52:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> Message-ID: On Thu, 18 Jul 2024 14:39:16 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1973: >> >>> 1971: >>> 1972: /* For every long value s in [0, 2^32) such that x == s * s, >>> 1973: * it is true that s == Math.round(Math.sqrt(x >= 0 ? x : x + 0x1p64)), >> >> To reinforce this claim, I suggest to add a test for all perfect squares. > > I did it, although I'm afraid it takes up too much running time due to the overhead of BigInteger's wrapping... I mean only restricted to unsigned `long` perfect squares, something like the following, but written as a proper test long i = 0; for (; i < 1L << 32; ++i) { long x = i * i; long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); if (!(s + 1 == i || s == i)) { System.out.format("oops... i=%d, but s=%d%n", i, s); System.exit(1); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682989536 From rgiulietti at openjdk.org Thu Jul 18 14:52:36 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 14:52:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> Message-ID: On Thu, 18 Jul 2024 14:49:19 GMT, Raffaello Giulietti wrote: >> I did it, although I'm afraid it takes up too much running time due to the overhead of BigInteger's wrapping... > > I mean only restricted to unsigned `long` perfect squares, something like the following, but written as a proper test > > > long i = 0; > for (; i < 1L << 32; ++i) { > long x = i * i; > long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); > if (!(s + 1 == i || s == i)) { > System.out.format("oops... i=%d, but s=%d%n", i, s); > System.exit(1); > } > } It takes about 5 s on my laptop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682990602 From duke at openjdk.org Thu Jul 18 14:58:41 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 14:58:41 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> Message-ID: On Thu, 18 Jul 2024 13:40:38 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> More accurate comment > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2135: > >> 2133: * @param limit the offset which is the end of valid words in the input value >> 2134: * @param blockLen the length of the block in units of 32 bits >> 2135: */ > > At first, I couldn't understand that `blockIndex` goes in the opposite direction as the array indices. Also, "starting" is very confusing, because no `int` at `blockIndex*blockLen` gets copied AFAIU. > > Two improvements: > * Add a `@return` tag. Alternatively, use comments other than JavaDoc `/**`. > * Make it explicit that the direction of `blockIndex` is the opposite of the array indices, and reconsider the wording like "starting", etc. For the sake of information: the documentation of this method is actually based on that of `MBI.getBlock(int, int, int)`, which has the same problems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1682999848 From jpai at openjdk.org Thu Jul 18 14:59:38 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 14:59:38 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v7] In-Reply-To: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@github.com> References: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@github.com> Message-ID: On Tue, 4 Jun 2024 17:43:24 GMT, Liam Miller-Cushon wrote: >> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. > > Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8328995 > - Move test to test/jdk/tools/launcher > - Add some more comments > - Maximum Zip64 extra field length is 32 > - Make cendsk an unsigned short > - Fix disk number size > - Improvements > > * don't rely on variable length arrays > * only run the test of 64 bit machines, since it requires >4GB of heap > - 8328995: launcher can't open jar files where the offset of the manifest is >4GB src/java.base/share/native/libjli/parse_manifest.c line 520: > 518: free(buffer); > 519: return (-1); > 520: } I think we are missing a `break;` here, after this inner `if` block reads the zip64 extra fields and returns `JNI_TRUE`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1682999880 From duke at openjdk.org Thu Jul 18 15:04:36 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 15:04:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> Message-ID: <_q6USP7P3bBY3Cwed54KxEmL8wsRYwMmgyKK1JknYPM=.a47dd90d-b0a1-4bf6-8ed4-99bfa47d2ef0@github.com> On Thu, 18 Jul 2024 14:50:00 GMT, Raffaello Giulietti wrote: >> I mean only restricted to unsigned `long` perfect squares, something like the following, but written as a proper test >> >> >> long i = 0; >> for (; i < 1L << 32; ++i) { >> long x = i * i; >> long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); >> if (!(s + 1 == i || s == i)) { >> System.out.format("oops... i=%d, but s=%d%n", i, s); >> System.exit(1); >> } >> } > > It takes about 5 s on my laptop. > I mean only restricted to unsigned `long` perfect squares, something like the following, but written as a proper test > > ``` > long i = 0; > for (; i < 1L << 32; ++i) { > long x = i * i; > long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); > if (!(s + 1 == i || s == i)) { > System.out.format("oops... i=%d, but s=%d%n", i, s); > System.exit(1); > } > } > ``` So, it is okay although the code does not test directly BigInteger.sqrt()? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683009907 From duke at openjdk.org Thu Jul 18 15:08:32 2024 From: duke at openjdk.org (Brett Okken) Date: Thu, 18 Jul 2024 15:08:32 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. src/java.base/share/classes/java/time/LocalTime.java line 1653: > 1651: int digits; > 1652: if (nanoValue % 1000_000 == 0) { > 1653: digits = nanoValue / 1000_000; should it be `1_000_000` - breaking on every 3 digits? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20232#discussion_r1683016529 From rgiulietti at openjdk.org Thu Jul 18 15:09:40 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 15:09:40 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> Message-ID: On Thu, 18 Jul 2024 14:55:30 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2135: >> >>> 2133: * @param limit the offset which is the end of valid words in the input value >>> 2134: * @param blockLen the length of the block in units of 32 bits >>> 2135: */ >> >> At first, I couldn't understand that `blockIndex` goes in the opposite direction as the array indices. Also, "starting" is very confusing, because no `int` at `blockIndex*blockLen` gets copied AFAIU. >> >> Two improvements: >> * Add a `@return` tag. Alternatively, use comments other than JavaDoc `/**`. >> * Make it explicit that the direction of `blockIndex` is the opposite of the array indices, and reconsider the wording like "starting", etc. > > For the sake of information: the documentation of this method is actually based on that of `MBI.getBlock(int, int, int)`, which has the same problems. I agree, and one could keep improving MBI's doc a lot, in particular implicit assumptions. But let's concentrate on this PR and make this code readable and well documented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683018032 From rriggs at openjdk.org Thu Jul 18 15:11:33 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Jul 2024 15:11:33 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 13:48:06 GMT, Chen Liang wrote: >> `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) >> >> Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. > > 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-signers > - Reorder comment of classData to avoid misunderstanding > - 8334772: Change Class::signers to an explicit field lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2186132979 From duke at openjdk.org Thu Jul 18 15:14:36 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 15:14:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: <_q6USP7P3bBY3Cwed54KxEmL8wsRYwMmgyKK1JknYPM=.a47dd90d-b0a1-4bf6-8ed4-99bfa47d2ef0@github.com> References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> <_q6USP7P3bBY3Cwed54KxEmL8wsRYwMmgyKK1JknYPM=.a47dd90d-b0a1-4bf6-8ed4-99bfa47d2ef0@github.com> Message-ID: On Thu, 18 Jul 2024 15:01:22 GMT, fabioromano1 wrote: >> It takes about 5 s on my laptop. > >> I mean only restricted to unsigned `long` perfect squares, something like the following, but written as a proper test >> >> ``` >> long i = 0; >> for (; i < 1L << 32; ++i) { >> long x = i * i; >> long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); >> if (!(s + 1 == i || s == i)) { >> System.out.format("oops... i=%d, but s=%d%n", i, s); >> System.exit(1); >> } >> } >> ``` > > So, it is okay although the code does not test directly BigInteger.sqrt()? I found the way: I can test directly the code through `java.math.Accessor.java` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683022159 From duke at openjdk.org Thu Jul 18 15:19:49 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 15:19:49 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v2] In-Reply-To: References: Message-ID: <8f2Q2ItEdTTGPPSRTGPfMuIC68nUEj7kacuMXcbZLIs=.8aec9e2e-51c6-4d28-b07e-337893f3b873@github.com> > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - add benchmark - remove JLA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20232/files - new: https://git.openjdk.org/jdk/pull/20232/files/aa0af2fa..ac302761 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20232&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20232&range=00-01 Stats: 154 lines in 3 files changed: 150 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20232/head:pull/20232 PR: https://git.openjdk.org/jdk/pull/20232 From rgiulietti at openjdk.org Thu Jul 18 15:25:40 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 15:25:40 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> <_q6USP7P3bBY3Cwed54KxEmL8wsRYwMmgyKK1JknYPM=.a47dd90d-b0a1-4bf6-8ed4-99bfa47d2ef0@github.com> Message-ID: <9vqIwuN6P6dfXQKjgdEunrxC3FRZFpHibD1m1T2crfw=.a37c2a38-68c2-4b42-b925-7b7c253f8a5c@github.com> On Thu, 18 Jul 2024 15:09:41 GMT, fabioromano1 wrote: >>> I mean only restricted to unsigned `long` perfect squares, something like the following, but written as a proper test >>> >>> ``` >>> long i = 0; >>> for (; i < 1L << 32; ++i) { >>> long x = i * i; >>> long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); >>> if (!(s + 1 == i || s == i)) { >>> System.out.format("oops... i=%d, but s=%d%n", i, s); >>> System.exit(1); >>> } >>> } >>> ``` >> >> So, it is okay although the code does not test directly BigInteger.sqrt()? > > I found the way: I can test directly the code through `java.math.Accessor.java` I think there's a misunderstanding here. What I'd like to see is a test that verifies the claim /* For every long value s in [0, 2^32) such that x == s * s, * it is true that s - 1 <= (long) Math.sqrt(x >= 0 ? x : x + 0x1p64) <= s, A test similar to my code above should be more than enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683045737 From mcimadamore at openjdk.org Thu Jul 18 15:27:45 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 18 Jul 2024 15:27:45 GMT Subject: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v3] In-Reply-To: References: <05NPlQ4U6cgxul3_rm6V-5PhPdRYSWO6oKIn67lfTxo=.e36064f0-274e-422a-aeed-4672159aaf7e@github.com> <6LWfBFLTU5Umn6EoF6qNsNjOi-uzedphDp661DUr2Q4=.7cc12bce-2283-4038-b3a5-28e6750dacfa@github.com> Message-ID: On Mon, 15 Jul 2024 16:30:11 GMT, Maurizio Cimadamore wrote: > * there is some issue involving segment access with `int` induction variable which we should investigate separately This issue is tracked here: https://bugs.openjdk.org/browse/JDK-8336759 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2236855896 From duke at openjdk.org Thu Jul 18 15:28:23 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 15:28:23 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v3] In-Reply-To: References: Message-ID: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: breaking on every 3 digits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20232/files - new: https://git.openjdk.org/jdk/pull/20232/files/ac302761..be7daa68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20232&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20232&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20232/head:pull/20232 PR: https://git.openjdk.org/jdk/pull/20232 From rgiulietti at openjdk.org Thu Jul 18 15:30:38 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 15:30:38 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v32] In-Reply-To: References: Message-ID: <_2WjOcZ1TEVFkUAONo4DISnGBj3AQyEXV0Fz59yEo20=.061172ae-21e8-41ca-be0a-b01811119692@github.com> On Thu, 18 Jul 2024 13:09:08 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Uniforming the computation of long values' square root src/java.base/share/classes/java/math/MutableBigInteger.java line 2032: > 2030: s = s1; > 2031: } > 2032: return s; Experimentally, the following seems a bit faster. In some cases, it avoids a full multiplication, some updates, and has one less test. I hope it is correct as well ;-) Suggestion: long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); long s2 = s * s; // overflows iff s = 2^32 if (s == 1L << 32 || Long.compareUnsigned(x, s2) < 0) { return s - 1; } if (Long.compareUnsigned(x, s2 + 2 * s) <= 0) { // x < (s + 1)^2 return s; } return s + 1; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683053330 From duke at openjdk.org Thu Jul 18 15:33:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 15:33:31 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:28:23 GMT, Shaojin Wen wrote: >> class LocalTime { >> public String toString() { >> // ... >> if (nanoValue % 1000_000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); >> } else if (nanoValue % 1000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); >> } else { >> buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); >> } >> // ... >> } >> } >> >> Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > breaking on every 3 digits Here are the performance numbers running on a MacBook M1 Max, 182.06% performance improvement -Benchmark Mode Cnt Score Error Units (master) -ToStringBench.localTimeToString thrpt 15 7.752 ? 1.036 ops/ms +Benchmark Mode Cnt Score Error Units (current ac30276105e541dac48e0d11f4595f93202031b8) +ToStringBench.localTimeToString thrpt 15 21.866 ? 0.417 ops/ms +182.06% ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2236864823 From duke at openjdk.org Thu Jul 18 15:43:05 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 18 Jul 2024 15:43:05 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v4] In-Reply-To: References: Message-ID: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20232/files - new: https://git.openjdk.org/jdk/pull/20232/files/be7daa68..d930eb37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20232&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20232&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20232/head:pull/20232 PR: https://git.openjdk.org/jdk/pull/20232 From rgiulietti at openjdk.org Thu Jul 18 15:54:35 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 15:54:35 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v30] In-Reply-To: <9vqIwuN6P6dfXQKjgdEunrxC3FRZFpHibD1m1T2crfw=.a37c2a38-68c2-4b42-b925-7b7c253f8a5c@github.com> References: <5kpNztl7IHKApAEam6363Sk7v5HruGyEDu-Waav8mZI=.e62e73fc-5184-4a52-b772-062b5995ff04@github.com> <_q6USP7P3bBY3Cwed54KxEmL8wsRYwMmgyKK1JknYPM=.a47dd90d-b0a1-4bf6-8ed4-99bfa47d2ef0@github.com> <9vqIwuN6P6dfXQKjgdEunrxC3FRZFpHibD1m1T2crfw=.a37c2a38-68c2-4b42-b925-7b7c253f8a5c@github.com> Message-ID: On Thu, 18 Jul 2024 15:22:39 GMT, Raffaello Giulietti wrote: >> I found the way: I can test directly the code through `java.math.Accessor.java` > > I think there's a misunderstanding here. > > What I'd like to see is a test that verifies the claim > > /* For every long value s in [0, 2^32) such that x == s * s, > * it is true that s - 1 <= (long) Math.sqrt(x >= 0 ? x : x + 0x1p64) <= s, > > A test similar to my code above should be more than enough. That test would not exercise any code in `MutableBigInteger` or `BigInteger`. It would just ensure that `MBI.ulongSqrt()` has solid foundations. Feel free to add the test at your discretion. However, if you decide for it, please make sure that it describes in comments what its purpose really is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683086849 From duke at openjdk.org Thu Jul 18 15:58:36 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 15:58:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v32] In-Reply-To: <_2WjOcZ1TEVFkUAONo4DISnGBj3AQyEXV0Fz59yEo20=.061172ae-21e8-41ca-be0a-b01811119692@github.com> References: <_2WjOcZ1TEVFkUAONo4DISnGBj3AQyEXV0Fz59yEo20=.061172ae-21e8-41ca-be0a-b01811119692@github.com> Message-ID: <2O4JE2b_yxSgCIBtAcJnQUrzGIuWO8VY96d-FTRaKoU=.6fbcc9c0-c7e0-4316-9faa-d0eab89c019a@github.com> On Thu, 18 Jul 2024 15:27:53 GMT, Raffaello Giulietti wrote: > Experimentally, the following seems a bit faster. In some cases, it avoids a full multiplication, some updates, and has one less test. I hope it is correct as well ;-) It's a nice code, but I'm afraid that if `s == LONG_MASK` and `Long.compareUnsigned(x, s * s) >= 0`, the overflow check is unavoidable... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683093419 From rgiulietti at openjdk.org Thu Jul 18 16:09:36 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 16:09:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v32] In-Reply-To: <2O4JE2b_yxSgCIBtAcJnQUrzGIuWO8VY96d-FTRaKoU=.6fbcc9c0-c7e0-4316-9faa-d0eab89c019a@github.com> References: <_2WjOcZ1TEVFkUAONo4DISnGBj3AQyEXV0Fz59yEo20=.061172ae-21e8-41ca-be0a-b01811119692@github.com> <2O4JE2b_yxSgCIBtAcJnQUrzGIuWO8VY96d-FTRaKoU=.6fbcc9c0-c7e0-4316-9faa-d0eab89c019a@github.com> Message-ID: <_ThuJ65B8HvemKA1-mcRbbrt01_Wk3cWqfG7eaKxx84=.decdb41d-b712-4e94-b19b-c52e6f443c66@github.com> On Thu, 18 Jul 2024 15:55:08 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2032: >> >>> 2030: s = s1; >>> 2031: } >>> 2032: return s; >> >> Experimentally, the following seems a bit faster. >> In some cases, it avoids a full multiplication, some updates, and has one less test. >> I hope it is correct as well ;-) >> >> Suggestion: >> >> long s = (long) Math.sqrt(x >= 0 ? x : x + 0x1p64); >> long s2 = s * s; // overflows iff s = 2^32 >> if (s == 1L << 32 >> || Long.compareUnsigned(x, s2) < 0) { >> return s - 1; >> } >> if (Long.compareUnsigned(x, s2 + 2 * s) <= 0) { // x < (s + 1)^2 >> return s; >> } >> return s + 1; > >> Experimentally, the following seems a bit faster. In some cases, it avoids a full multiplication, some updates, and has one less test. I hope it is correct as well ;-) > > It's a nice code, but I'm afraid that if `s == LONG_MASK` and `Long.compareUnsigned(x, s * s) >= 0`, the overflow check is unavoidable... I guess you are concerned about an overflow in `s2 + 2 * s`? If s = 2^32 - 1, then s2 = 2^64 - 2?2^32 + 1 and 2s = 2?2^32 - 2, without overflows. Thus, s2 + 2s = 2^64 - 1, without overflows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683119623 From duke at openjdk.org Thu Jul 18 16:16:35 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 16:16:35 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v32] In-Reply-To: <_ThuJ65B8HvemKA1-mcRbbrt01_Wk3cWqfG7eaKxx84=.decdb41d-b712-4e94-b19b-c52e6f443c66@github.com> References: <_2WjOcZ1TEVFkUAONo4DISnGBj3AQyEXV0Fz59yEo20=.061172ae-21e8-41ca-be0a-b01811119692@github.com> <2O4JE2b_yxSgCIBtAcJnQUrzGIuWO8VY96d-FTRaKoU=.6fbcc9c0-c7e0-4316-9faa-d0eab89c019a@github.com> <_ThuJ65B8HvemKA1-mcRbbrt01_Wk3cWqfG7eaKxx84=.decdb41d-b712-4e94-b19b-c52e6f443c66@github.com> Message-ID: On Thu, 18 Jul 2024 16:06:31 GMT, Raffaello Giulietti wrote: >>> Experimentally, the following seems a bit faster. In some cases, it avoids a full multiplication, some updates, and has one less test. I hope it is correct as well ;-) >> >> It's a nice code, but I'm afraid that if `s == LONG_MASK` and `Long.compareUnsigned(x, s * s) >= 0`, the overflow check is unavoidable... > > I guess you are concerned about an overflow in `s2 + 2 * s`? > > If s = 2^32 - 1, then s2 = 2^64 - 2?2^32 + 1 and 2s = 2?2^32 - 2, without overflows. > Thus, s2 + 2s = 2^64 - 1, without overflows. @rgiulietti True, it's almost borderline code... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683135335 From asotona at openjdk.org Thu Jul 18 16:29:56 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 18 Jul 2024 16:29:56 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors Message-ID: `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. Relevant test is added. Please review. Thanks, Adam ------------- Commit messages: - 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors Changes: https://git.openjdk.org/jdk/pull/20241/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20241&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333812 Stats: 31 lines in 3 files changed: 25 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20241/head:pull/20241 PR: https://git.openjdk.org/jdk/pull/20241 From liach at openjdk.org Thu Jul 18 16:32:32 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 16:32:32 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 16:23:44 GMT, Adam Sotona wrote: > `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. > `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. > > This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. > > Relevant test is added. > > Please review. > > Thanks, > Adam src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java line 117: > 115: > 116: public static List verify(ClassModel classModel, ClassHierarchyResolver classHierarchyResolver, Consumer logger) { > 117: String clsName = classModel.thisClass().asInternalName(); This can still throw `ConstantPoolException` if this_class points to a non-Class entry. This entry is lazily read by `ClassReader`, so you can create a `ClassModel` for such a bad class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20241#discussion_r1683165097 From darcy at openjdk.org Thu Jul 18 16:36:35 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 18 Jul 2024 16:36:35 GMT Subject: Integrated: 8333768: Minor doc updates to java.lang.{Float, Double} In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 04:47:12 GMT, Joe Darcy wrote: > Misc small doc updates and addition of `@Overrides` annotations. This pull request has now been integrated. Changeset: bbc79a5e Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/bbc79a5e0144cb5ee6051e078681f9c6821441cb Stats: 113 lines in 4 files changed: 82 ins; 2 del; 29 mod 8333768: Minor doc updates to java.lang.{Float, Double} Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/19590 From aph at openjdk.org Thu Jul 18 16:39:33 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Jul 2024 16:39:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Thu, 11 Jul 2024 23:22:19 GMT, Vladimir Ivanov wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1433: >> >>> 1431: >>> 1432: // Don't check secondary_super_cache >>> 1433: if (super_check_offset.is_register() >> >> Do you see any effects from this particular change? >> >> It adds a runtime check on the fast path for all subtype checks (irrespective of whether it checks primary or secondary super). Moreover, the very same check is performed after primary super slot is checked. >> >> Unless `_secondary_super_cache` field is removed, unconditionally checking the slot at `super_check_offset` is benign. > > BTW `MacroAssembler::check_klass_subtype_fast_path` deserves a cleanup: `super_check_offset` can be safely turned into `Register` thus eliminating the code guarded by `super_check_offset.is_register() == false`. > Do you see any effects from this particular change? > > It adds a runtime check on the fast path for all subtype checks (irrespective of whether it checks primary or secondary super). Moreover, the very same check is performed after primary super slot is checked. OK. I think this was more for testing, but you make sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683178664 From aph at openjdk.org Thu Jul 18 16:39:33 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Jul 2024 16:39:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Wed, 17 Jul 2024 18:54:32 GMT, Vladimir Ivanov wrote: >> Now it starts to sound concerning... `Klass::set_secondary_supers()` initializes both `_secondary_supers` and `_bitmap` which implies that `Klass::is_subtype_of()` may be called on not yet initialized Klass. It that's the case, it does look like a bug on its own. How is it expected to work when `_secondary_supers` hasn't been set yet? > > On a second thought the following setter may be the culprit: > > void Klass::set_secondary_supers(Array* secondaries) { > assert(!UseSecondarySupersTable || secondaries == nullptr, ""); > set_secondary_supers(secondaries, SECONDARY_SUPERS_BITMAP_EMPTY); > } > > It should be adjusted to set `SECONDARY_SUPERS_BITMAP_FULL` instead. I've spent a while trying to reproduce the problem but I can't. I was seeing a problem where `Klass::is_subtype_of(vmClasses::Cloneable_klass())` was being called before the bitmap had been set. I'm not sure what to think, really. Maybe I should just back out this change to see what happens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683174591 From aph at openjdk.org Thu Jul 18 16:44:32 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Jul 2024 16:44:32 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Thu, 11 Jul 2024 23:39:11 GMT, Vladimir Ivanov wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1040: > >> 1038: >> 1039: // Secondary subtype checking >> 1040: void lookup_secondary_supers_table(Register sub_klass, > > While browsing the code, I noticed that it's far from evident at call sites which overload is used (especially with so many arguments). Does it make sense to avoid method overloads here and use distinct method names instead? So I confess: this is surely true, but I failed to think of a name for the known- and unknown-at-compile-time versions. maybe `check_const_klass_subtype_slow_path_table` and `check_var_klass_subtype_slow_path_table` ? > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 1981: > >> 1979: __ load_klass(r19_klass, copied_oop);// query the object klass >> 1980: >> 1981: BLOCK_COMMENT("type_check:"); > > Why don't you move it inside `generate_type_check`? Sorry, what? Do you mean move just this block comment? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683182967 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683184664 From duke at openjdk.org Thu Jul 18 17:11:13 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 17:11:13 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v33] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Second revision changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/3d8a913a..ca075ed8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=31-32 Stats: 44 lines in 2 files changed: 26 ins; 3 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From rgiulietti at openjdk.org Thu Jul 18 17:16:36 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Jul 2024 17:16:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v32] In-Reply-To: References: <_2WjOcZ1TEVFkUAONo4DISnGBj3AQyEXV0Fz59yEo20=.061172ae-21e8-41ca-be0a-b01811119692@github.com> <2O4JE2b_yxSgCIBtAcJnQUrzGIuWO8VY96d-FTRaKoU=.6fbcc9c0-c7e0-4316-9faa-d0eab89c019a@github.com> <_ThuJ65B8HvemKA1-mcRbbrt01_Wk3cWqfG7eaKxx84=.decdb41d-b712-4e94-b19b-c52e6f443c66@github.com> Message-ID: <1k1z4qtaqTm9Dhdd1V5v0jSxVNxWmrRdKqGt-Fygt9k=.ec93b2fe-3f8e-41d7-bd18-cf6f8813d477@github.com> On Thu, 18 Jul 2024 16:14:02 GMT, fabioromano1 wrote: >> I guess you are concerned about an overflow in `s2 + 2 * s`? >> >> If s = 2^32 - 1, then s2 = 2^64 - 2?2^32 + 1 and 2s = 2?2^32 - 2, without overflows. >> Thus, s2 + 2s = 2^64 - 1, without overflows. > > @rgiulietti True, it's almost borderline code... BTW, experimentally there are just 1024 cases for which `(long) Math.sqrt(x >= 0 ? x : x + 0x1p64)` is 2^32. Thus, there are just 1024 cases for which `s2` is 0, and for these `Long.compareUnsigned(x, s2) < 0` is always false. Therefore, I think it's statistically more convenient to interchange the two predicates of `||`, like so, to favor the case x < s2 if (Long.compareUnsigned(x, s2) < 0 || s == 1L << 32) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1683220381 From liach at openjdk.org Thu Jul 18 17:18:35 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 17:18:35 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v4] In-Reply-To: References: Message-ID: <1979AF9Czreu0fL5QeiAMXfS1jRohd8KDl8HcMSdiss=.3137b771-31a0-4b3a-94d8-dde162d7e911@github.com> On Thu, 18 Jul 2024 15:43:05 GMT, Shaojin Wen wrote: >> class LocalTime { >> public String toString() { >> // ... >> if (nanoValue % 1000_000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); >> } else if (nanoValue % 1000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); >> } else { >> buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); >> } >> // ... >> } >> } >> >> Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright The extraction of string length logic to `DecimalDigits` look great. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20232#pullrequestreview-2186450502 From duke at openjdk.org Thu Jul 18 17:22:50 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 18 Jul 2024 17:22:50 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Conditions' order reversed in MBI.ulongSqrt() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/ca075ed8..2598ec97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=32-33 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From aph at openjdk.org Thu Jul 18 17:43:29 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Jul 2024 17:43:29 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Negated tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19989/files - new: https://git.openjdk.org/jdk/pull/19989/files/7d7694cc..bfe9ceed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=00-01 Stats: 23 lines in 3 files changed: 10 ins; 10 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From naoto at openjdk.org Thu Jul 18 18:16:48 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Jul 2024 18:16:48 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v3] In-Reply-To: References: Message-ID: > Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20220/files - new: https://git.openjdk.org/jdk/pull/20220/files/ff3d259c..4f8f1181 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=01-02 Stats: 21 lines in 2 files changed: 8 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/20220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20220/head:pull/20220 PR: https://git.openjdk.org/jdk/pull/20220 From vromero at openjdk.org Thu Jul 18 18:43:34 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 18 Jul 2024 18:43:34 GMT Subject: RFR: 8334714: Class-File API leaves preview [v2] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 08:59:07 GMT, Adam Sotona wrote: >> Class-File API is leaving preview. >> This is a removal of all `@PreviewFeature` annotations from Class-File API. >> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into JDK-8334714-final > - bumped @since tag > - 8334714: Class-File API leaves preview lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2186608609 From bpb at openjdk.org Thu Jul 18 18:43:52 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Jul 2024 18:43:52 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: <4QqW1hotlgDnm9hH4MuBpGKWzToVRYLc210z_fKfIyY=.08683fe9-6ecf-4390-97e4-009438e77ace@github.com> References: <4QqW1hotlgDnm9hH4MuBpGKWzToVRYLc210z_fKfIyY=.08683fe9-6ecf-4390-97e4-009438e77ace@github.com> Message-ID: On Thu, 11 Jul 2024 13:10:32 GMT, Olivier Masseau wrote: > Hello, Has this been backported to Java 8 ? I can't really find the info. According to the issue [JDK-8321863](https://bugs.openjdk.org/browse/JDK-8321863) it looks like it has been so backported. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16502#issuecomment-2237262955 From vlivanov at openjdk.org Thu Jul 18 19:07:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Jul 2024 19:07:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Thu, 18 Jul 2024 16:40:47 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1040: >> >>> 1038: >>> 1039: // Secondary subtype checking >>> 1040: void lookup_secondary_supers_table(Register sub_klass, >> >> While browsing the code, I noticed that it's far from evident at call sites which overload is used (especially with so many arguments). Does it make sense to avoid method overloads here and use distinct method names instead? > > So I confess: this is surely true, but I failed to think of a name for the known- and unknown-at-compile-time versions. maybe `check_const_klass_subtype_slow_path_table` and `check_var_klass_subtype_slow_path_table` ? Another idea: `lookup_secondary_supers_table_var` vs `lookup_secondary_supers_table_const`. Or `lookup_secondary_supers_table_super_var` vs `lookup_secondary_supers_table_super_const`. >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 1981: >> >>> 1979: __ load_klass(r19_klass, copied_oop);// query the object klass >>> 1980: >>> 1981: BLOCK_COMMENT("type_check:"); >> >> Why don't you move it inside `generate_type_check`? > > Sorry, what? Do you mean move just this block comment? No, the whole piece with `if (UseSecondarySupersTable) { ... } else { ... }` included. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683349665 PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683348239 From rriggs at openjdk.org Thu Jul 18 19:14:33 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Jul 2024 19:14:33 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 18:16:48 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments src/java.base/share/classes/java/lang/Process.java line 462: > 460: throws InterruptedException { > 461: Objects.requireNonNull(unit, "unit"); // throw NPE before other conditions > 462: Seems out of scope for this enhancement. Might be better in the PR to update @implSpec as minor updates. src/java.base/share/classes/java/lang/Process.java line 504: > 502: return false; > 503: > 504: return waitForNanos(TimeUnit.NANOSECONDS.convert(duration)); I'd rather see one of these methods call the other, to make it easy keep the behavior in sync. The Duration can be extracted to nanos and call the existing method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683348791 PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683352257 From wxiao at openjdk.org Thu Jul 18 19:18:41 2024 From: wxiao at openjdk.org (Weibing Xiao) Date: Thu, 18 Jul 2024 19:18:41 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. It was not backport to jdk8u. https://bugs.openjdk.org/browse/JDK-8321863 is for 8u411-perf, which is not same as jdk8u release. The bug originally was reported in jdk11, not in jdk8. That?s the reason I did not backport the change to jdk8u. From: Brian Burkhalter ***@***.***> Date: Thursday, July 18, 2024 at 2:41?PM To: openjdk/jdk ***@***.***> Cc: Weibing Xiao ***@***.***>, Mention ***@***.***> Subject: [External] : Re: [openjdk/jdk] 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder (PR #16502) Hello, Has this been backported to Java 8 ? I can't really find the info. According to the issue JDK-8321863 it looks like it has been so backported. ? Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***> ------------- PR Comment: https://git.openjdk.org/jdk/pull/16502#issuecomment-2237355311 From bpb at openjdk.org Thu Jul 18 19:23:40 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Jul 2024 19:23:40 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 19:16:03 GMT, Weibing Xiao wrote: > It was not backport to jdk8u. https://bugs.openjdk.org/browse/JDK-8321863 is for 8u411-perf, which is not same as jdk8u release. Thanks for the clarification. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16502#issuecomment-2237363760 From vlivanov at openjdk.org Thu Jul 18 19:59:35 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Jul 2024 19:59:35 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Thu, 18 Jul 2024 16:35:16 GMT, Andrew Haley wrote: >> On a second thought the following setter may be the culprit: >> >> void Klass::set_secondary_supers(Array* secondaries) { >> assert(!UseSecondarySupersTable || secondaries == nullptr, ""); >> set_secondary_supers(secondaries, SECONDARY_SUPERS_BITMAP_EMPTY); >> } >> >> It should be adjusted to set `SECONDARY_SUPERS_BITMAP_FULL` instead. > > I've spent a while trying to reproduce the problem but I can't. > > I was seeing a problem where `Klass::is_subtype_of(vmClasses::Cloneable_klass())` was being called before the bitmap had been set. I'm not sure what to think, really. Maybe I should just back out this change to see what happens. I'm in favor of backing out this change and adding an assert/guarantee (on `_secondary_supers != nullptr`) in `Klass::is_subtype_of()` to ensure no subtype checks happen on uninitialized Klasses. Then we should be able to spot and fix all the places where problematic checks happen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683409343 From vlivanov at openjdk.org Thu Jul 18 20:09:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Jul 2024 20:09:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Wed, 17 Jul 2024 17:15:32 GMT, Andrew Haley wrote: >> src/hotspot/share/oops/klass.inline.hpp line 122: >> >>> 120: return true; >>> 121: >>> 122: bool result = lookup_secondary_supers_table(k); >> >> Should `UseSecondarySupersTable` affect `Klass::search_secondary_supers` as well? > > I think not. It'd complicate C++ runtime for no useful reason. On the other hand, if `-XX:-UseSecondarySupersTable` is intended solely for diagnostic purposes, then handling all possible execution modes uniformly is preferable, since it gives more confidence when troubleshooting seemingly related failures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683419259 From vlivanov at openjdk.org Thu Jul 18 20:13:32 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 18 Jul 2024 20:13:32 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Thu, 18 Jul 2024 20:07:14 GMT, Vladimir Ivanov wrote: >> I think not. It'd complicate C++ runtime for no useful reason. > > On the other hand, if `-XX:-UseSecondarySupersTable` is intended solely for diagnostic purposes, then handling all possible execution modes uniformly is preferable, since it gives more confidence when troubleshooting seemingly related failures. Alternatively, `Klass::is_subtype_of()` can unconditionally perform linear search over secondary_supers array. Even though I very much like to see table lookup written in C++ (accompanying heavily optimized platform-specific MacroAssembler variants), it would make C++ runtime even simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1683423052 From naoto at openjdk.org Thu Jul 18 20:49:10 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Jul 2024 20:49:10 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v4] In-Reply-To: References: Message-ID: > Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20220/files - new: https://git.openjdk.org/jdk/pull/20220/files/4f8f1181..95085cc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=02-03 Stats: 34 lines in 1 file changed: 9 ins; 19 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20220/head:pull/20220 PR: https://git.openjdk.org/jdk/pull/20220 From naoto at openjdk.org Thu Jul 18 20:49:11 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Jul 2024 20:49:11 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 19:07:18 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments > > src/java.base/share/classes/java/lang/Process.java line 504: > >> 502: return false; >> 503: >> 504: return waitForNanos(TimeUnit.NANOSECONDS.convert(duration)); > > I'd rather see one of these methods call the other, to make it easy keep the behavior in sync. > The Duration can be extracted to nanos and call the existing method. Fixed as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683484772 From naoto at openjdk.org Thu Jul 18 20:51:48 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Jul 2024 20:51:48 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: > Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: removed a blank line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20220/files - new: https://git.openjdk.org/jdk/pull/20220/files/95085cc7..fac29cfc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20220&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20220/head:pull/20220 PR: https://git.openjdk.org/jdk/pull/20220 From liach at openjdk.org Thu Jul 18 21:15:31 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 21:15:31 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: <3FXpUS-g2UvFcSu1Dk-g7ernkRdBfpNOqUwX-MKZdBU=.75048598-9a6d-4a1f-bb38-a1821ebd2e54@github.com> On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > removed a blank line Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20220#pullrequestreview-2186923087 From liach at openjdk.org Thu Jul 18 21:26:31 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 21:26:31 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: <0lpKW8uPpuowuEsGNm67rjvOtNuOa2AOMnWxw_HtRJ4=.2390ea35-6e29-421a-aac4-2f9038ec25d6@github.com> On Wed, 17 Jul 2024 21:42:15 GMT, Naoto Sato wrote: >> This?method needs to?be?overridden in?`test/lib/jdk/test/lib/process/ProcessTools.java` to?call `ProcessTools.ProcessImpl::waitForStreams`. > > I don't think current `ProcessTools.startProcess()` even calls `waitFor(long, TimeUnit)` let alone `waitFor(Duration)`. It is polling the process by itself to implement timeout. But I agree it is a good measure to add the override there, for the test to use it in the future. Incidentally the same remark has been raised in https://github.com/openjdk/jdk/pull/20220#discussion_r1683352257 and addressed. Good enough for me! ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683523348 From rriggs at openjdk.org Thu Jul 18 21:30:32 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Jul 2024 21:30:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: <4vicTmz9bmkIn52hMQlU5150BKwfcYI9eEG56ZtaWh4=.c95b0d47-a69b-41c5-a7df-07ad88d8f760@github.com> On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > removed a blank line src/java.base/share/classes/java/lang/Process.java line 505: > 503: public boolean waitFor(Duration duration) throws InterruptedException { > 504: Objects.requireNonNull(duration, "duration"); > 505: return waitFor(TimeUnit.NANOSECONDS.convert(duration), TimeUnit.NANOSECONDS); With this change, the update to ProcessTools is unnecessary and could be backed out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683527366 From naoto at openjdk.org Thu Jul 18 18:21:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Jul 2024 18:21:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v2] In-Reply-To: <4rizsae0Hyr0jR9RaSZVNmvwYBIFwZnSSu5Cgszvry0=.c13d8192-73a7-45df-8cc7-10d940dacd80@github.com> References: <4rizsae0Hyr0jR9RaSZVNmvwYBIFwZnSSu5Cgszvry0=.c13d8192-73a7-45df-8cc7-10d940dacd80@github.com> Message-ID: On Thu, 18 Jul 2024 05:11:12 GMT, Jaikiran Pai wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> ProcessTools overriding one-arg waitFor() > > src/java.base/share/classes/java/lang/Process.java line 501: > >> 499: if (hasExited()) >> 500: return true; >> 501: if (duration.isZero() || duration.isNegative()) > > Hello Naoto, I see that there's a `Duration.isPositive()` API. Should we use that here instead? Good point. I forgot it although I introduced the methd back in JDK18 ? > test/jdk/java/lang/Process/WaitForDuration.java line 57: > >> 55: throws IOException, InterruptedException { >> 56: assertEquals(expected, >> 57: new ProcessBuilder("sleep", "3").start().waitFor(d)); > > I think in its current form, this has a chance of failure (for inputs like 0 or negative duration), if the sleep (for 3 seconds) completes (and thus the process exits) before the `Process.waitFor` implementation has had a chance to execute `hasExited()`. > > Also, this test is marked to run on all platforms. I think we might need special handling for `sleep` executable on Windows. In fact, looking at the `initSleepPath` in the `test/jdk/java/lang/ProcessBuilder/Basic.java` test, I suspect we might need something similar in this test even for *nix. Made the sleep length variable, and used one hour for zero or negative (should be enough). For the positive, the process completes immediately. Also, I changed the sleep part to pure Java so that it won't rely on the testing platform. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683292669 PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683292765 From liach at openjdk.org Thu Jul 18 21:35:32 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 21:35:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: <4vicTmz9bmkIn52hMQlU5150BKwfcYI9eEG56ZtaWh4=.c95b0d47-a69b-41c5-a7df-07ad88d8f760@github.com> References: <4vicTmz9bmkIn52hMQlU5150BKwfcYI9eEG56ZtaWh4=.c95b0d47-a69b-41c5-a7df-07ad88d8f760@github.com> Message-ID: On Thu, 18 Jul 2024 21:27:35 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> removed a blank line > > src/java.base/share/classes/java/lang/Process.java line 505: > >> 503: public boolean waitFor(Duration duration) throws InterruptedException { >> 504: Objects.requireNonNull(duration, "duration"); >> 505: return waitFor(TimeUnit.NANOSECONDS.convert(duration), TimeUnit.NANOSECONDS); > > With this change, the update to ProcessTools is unnecessary and could be backed out. The `ProcessTools` override is a delegating override; I think it still makes sense and should be kept. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683532105 From cushon at openjdk.org Thu Jul 18 21:36:54 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 18 Jul 2024 21:36:54 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v8] In-Reply-To: References: Message-ID: > This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. Liam Miller-Cushon 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 10 additional commits since the last revision: - Add a missing `break` - Merge branch 'master' into JDK-8328995 - Merge remote-tracking branch 'origin/master' into JDK-8328995 - Move test to test/jdk/tools/launcher - Add some more comments - Maximum Zip64 extra field length is 32 - Make cendsk an unsigned short - Fix disk number size - Improvements * don't rely on variable length arrays * only run the test of 64 bit machines, since it requires >4GB of heap - 8328995: launcher can't open jar files where the offset of the manifest is >4GB ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18479/files - new: https://git.openjdk.org/jdk/pull/18479/files/da36c059..172609a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=06-07 Stats: 86273 lines in 2119 files changed: 54788 ins; 22033 del; 9452 mod Patch: https://git.openjdk.org/jdk/pull/18479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18479/head:pull/18479 PR: https://git.openjdk.org/jdk/pull/18479 From cushon at openjdk.org Thu Jul 18 21:36:58 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 18 Jul 2024 21:36:58 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v7] In-Reply-To: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@github.com> References: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@github.com> Message-ID: On Tue, 4 Jun 2024 17:43:24 GMT, Liam Miller-Cushon wrote: >> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. > > Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8328995 > - Move test to test/jdk/tools/launcher > - Add some more comments > - Maximum Zip64 extra field length is 32 > - Make cendsk an unsigned short > - Fix disk number size > - Improvements > > * don't rely on variable length arrays > * only run the test of 64 bit machines, since it requires >4GB of heap > - 8328995: launcher can't open jar files where the offset of the manifest is >4GB For what it's worth I have been testing the current version of the PR at Google, and have verified it allows jars with >4GB offsets to be launched, and we haven't observed any regressions using it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2237656114 From cushon at openjdk.org Thu Jul 18 21:36:59 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 18 Jul 2024 21:36:59 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v7] In-Reply-To: References: <_TvJQ-I5L2LkS4PrOqEX4MU_GBDxP0nJy_kkwMk9lr0=.ca7a9572-fdad-4c43-8355-8c273646bfc5@github.com> Message-ID: On Thu, 18 Jul 2024 14:55:31 GMT, Jaikiran Pai wrote: >> Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8328995 >> - Move test to test/jdk/tools/launcher >> - Add some more comments >> - Maximum Zip64 extra field length is 32 >> - Make cendsk an unsigned short >> - Fix disk number size >> - Improvements >> >> * don't rely on variable length arrays >> * only run the test of 64 bit machines, since it requires >4GB of heap >> - 8328995: launcher can't open jar files where the offset of the manifest is >4GB > > src/java.base/share/native/libjli/parse_manifest.c line 520: > >> 518: free(buffer); >> 519: return (-1); >> 520: } > > I think we are missing a `break;` here, after this inner `if` block reads the zip64 extra fields and returns `JNI_TRUE`. Thanks for the catch, fixed. It is unnecessary to loop over any other extensions that are present after the zip64 one is found. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1683531984 From dholmes at openjdk.org Thu Jul 18 21:40:35 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Jul 2024 21:40:35 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 13:48:06 GMT, Chen Liang wrote: >> `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) >> >> Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. > > 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-signers > - Reorder comment of classData to avoid misunderstanding > - 8334772: Change Class::signers to an explicit field On the JVMTI side and the heapDumper ... I see that heapDumper explicitly fills in a slot for the classloader, but that is also an explicit field. Does that mean that the classloader appears twice, or does the fact it is filtered by reflection mean that the heapDumper doesn't see it when dumping fields? If the latter then it suggests to me that we should be doing the same for the signers. Otherwise I don't know what the implications might be for having the field listed twice. ------------- PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2186958021 From liach at openjdk.org Thu Jul 18 21:48:35 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 21:48:35 GMT Subject: Integrated: 8336588: Ensure Transform downstream receives upstream start items only after downstream started In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 21:31:51 GMT, Chen Liang wrote: > There's another bug in ClassFile transform composition where the downstream transform receives items from upstream transform's chained builders before the downstream transform itself starts. This is a simple fix, and a test case against `ClassTransform` is added. This pull request has now been integrated. Changeset: b44632aa Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/b44632aa15d21a10e559aee02a9e4dcd876654f6 Stats: 63 lines in 2 files changed: 49 ins; 9 del; 5 mod 8336588: Ensure Transform downstream receives upstream start items only after downstream started Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20227 From liach at openjdk.org Thu Jul 18 21:48:36 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 21:48:36 GMT Subject: Integrated: 8336585: BoundAttribute.readEntryList not type-safe In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 20:51:32 GMT, Chen Liang wrote: > Qualify the reading of entry lists with the anticipated types up-front, so we throw the correct `ConstantPoolException` instead of `ClassCastException` when we encounter malformed attribute lists. (`ClassModel.getInterfaces` already behave correctly, in comparison) This pull request has now been integrated. Changeset: 902c2afb Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/902c2afb6714f778e3229c8411e9f9d5c392b388 Stats: 65 lines in 2 files changed: 43 ins; 8 del; 14 mod 8336585: BoundAttribute.readEntryList not type-safe Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20225 From naoto at openjdk.org Thu Jul 18 21:53:30 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Jul 2024 21:53:30 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: <4vicTmz9bmkIn52hMQlU5150BKwfcYI9eEG56ZtaWh4=.c95b0d47-a69b-41c5-a7df-07ad88d8f760@github.com> Message-ID: <-YwiNkhbOyG7emMi9WunX_ijLe9TSjmDpwgyblVPvaY=.09d378e8-c970-44c5-8076-e5dc6831e018@github.com> On Thu, 18 Jul 2024 21:32:31 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/Process.java line 505: >> >>> 503: public boolean waitFor(Duration duration) throws InterruptedException { >>> 504: Objects.requireNonNull(duration, "duration"); >>> 505: return waitFor(TimeUnit.NANOSECONDS.convert(duration), TimeUnit.NANOSECONDS); >> >> With this change, the update to ProcessTools is unnecessary and could be backed out. > > The `ProcessTools` override is a delegating override; I think it still makes sense and should be kept. I think the test tool should not depend on the internal implementation, so I think it should be kept. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683545877 From liach at openjdk.org Thu Jul 18 22:00:31 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 22:00:31 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors In-Reply-To: References: Message-ID: <5GQMlKLvx_SAcLW3eItg1tkEL-C2vASmqEC9EyVbNd4=.e204663a-0e79-43f2-b9e1-4fb5597cd835@github.com> On Thu, 18 Jul 2024 16:29:17 GMT, Chen Liang wrote: >> `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. >> `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. >> >> This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. >> >> Relevant test is added. >> >> Please review. >> >> Thanks, >> Adam > > src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java line 117: > >> 115: >> 116: public static List verify(ClassModel classModel, ClassHierarchyResolver classHierarchyResolver, Consumer logger) { >> 117: String clsName = classModel.thisClass().asInternalName(); > > This can still throw `ConstantPoolException` if this_class points to a non-Class entry. This entry is lazily read by `ClassReader`, so you can create a `ClassModel` for such a bad class. Alternatively, a malformed Class constant can point to a non-utf8, so the `asInternalName` can fail too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20241#discussion_r1683550724 From dholmes at openjdk.org Thu Jul 18 22:18:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Jul 2024 22:18:32 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 13:48:06 GMT, Chen Liang wrote: >> `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) >> >> Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. > > 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-signers > - Reorder comment of classData to avoid misunderstanding > - 8334772: Change Class::signers to an explicit field I am not a hprof expert but AFAICS the `HPROF_GC_CLASS_DUMP` contains an explicit id for the classloader, signers, and pd, of the class, and then later a list of all fields declared in the class. AFAICS there is no real connection between these, so it doesn't matter if the classloader/signers/pd is an injected field, a regular Java field, or not a field at all. So in that regard it seems `signers` will now be handled the same way as `classloader` and so that should be fine. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2186999675 From liach at openjdk.org Thu Jul 18 22:25:36 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 22:25:36 GMT Subject: RFR: 8334772: Change Class::signers to an explicit field [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 13:48:06 GMT, Chen Liang wrote: >> `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) >> >> Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. > > 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-signers > - Reorder comment of classData to avoid misunderstanding > - 8334772: Change Class::signers to an explicit field Thanks for the reviews! I will go ahead and integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20223#issuecomment-2237720701 From liach at openjdk.org Thu Jul 18 22:25:36 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 22:25:36 GMT Subject: Integrated: 8334772: Change Class::signers to an explicit field In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 19:47:44 GMT, Chen Liang wrote: > `Class` has 2 VM-injected fields that can be made explicit: `Object[] signers` and `ProtectionDomain protectionDomain`. We make the signers field explicit. (The ProtectionDomain can be revisited when SecurityManager is removed, as SecurityManager is accessing it via JNI as well.) > > Migrate the JNI code to Java. The getter previously had a redundant primitive type check, which is dropped in the migrated Java code. The `Object[] getSigners` is no longer `native`, thus requiring a CSR record. Reviewers please help review the associated CSR. This pull request has now been integrated. Changeset: 39f44768 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/39f44768131254ee11f723f92e2bac57b0d1ade0 Stats: 72 lines in 6 files changed: 6 ins; 53 del; 13 mod 8334772: Change Class::signers to an explicit field Reviewed-by: dholmes, alanb, rriggs, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/20223 From liach at openjdk.org Thu Jul 18 22:27:03 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 22:27:03 GMT Subject: RFR: 8336777: BufferedMethodBuilder not initialized with static flag Message-ID: `BufferedMethodBuilder` accepts a static flag and passes it to the `CodeBuilder` it creates; yet it does not prevent static flag tampering like `DirectMethodBuilder` does. This patch makes their behaviors consistent. Note that the throwing of IAE is provisional; it is open to discussion later. ------------- Commit messages: - 8336777: BufferedMethodBuilder not initialized with static flag Changes: https://git.openjdk.org/jdk/pull/20244/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20244&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336777 Stats: 102 lines in 6 files changed: 91 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20244.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20244/head:pull/20244 PR: https://git.openjdk.org/jdk/pull/20244 From liach at openjdk.org Thu Jul 18 22:52:31 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 22:52:31 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 21:07:23 GMT, Archie Cobbs wrote: > The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. > > However, while `DeflaterOutputStream` provides constructors that take a custom `Deflater` argument supplied by the caller, `GZIPOutputStream` has no such constructors. > > As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level. > > This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`. @jaikiran Is it possible for you to review this, as you are familiar with this area? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2237745878 From liach at openjdk.org Thu Jul 18 22:56:10 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 22:56:10 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v2] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition 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 ten additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge BoundAttributeTest - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage The rest of Writable in annotations can be removed in later cleanup - Fix up usages of Util.write - Hide writeTo from all class file elements To consider the fate of WritableElement later! ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20205/files - new: https://git.openjdk.org/jdk/pull/20205/files/78830195..bbd6c73c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=00-01 Stats: 2383 lines in 117 files changed: 1586 ins; 335 del; 462 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From prappo at openjdk.org Thu Jul 18 23:00:39 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 18 Jul 2024 23:00:39 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: <1c_hQHyD2LrOjoSFB6kCnYWHYme89pAx2LmfTGlI7I4=.6ca449bb-ca65-4766-be87-46c26e2e01e0@github.com> On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > removed a blank line src/java.base/share/classes/java/lang/Process.java line 504: > 502: */ > 503: public boolean waitFor(Duration duration) throws InterruptedException { > 504: Objects.requireNonNull(duration, "duration"); Does this explicit null-check pull its weight here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683585609 From liach at openjdk.org Thu Jul 18 23:05:31 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 23:05:31 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: <1c_hQHyD2LrOjoSFB6kCnYWHYme89pAx2LmfTGlI7I4=.6ca449bb-ca65-4766-be87-46c26e2e01e0@github.com> References: <1c_hQHyD2LrOjoSFB6kCnYWHYme89pAx2LmfTGlI7I4=.6ca449bb-ca65-4766-be87-46c26e2e01e0@github.com> Message-ID: On Thu, 18 Jul 2024 22:57:59 GMT, Pavel Rappo wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> removed a blank line > > src/java.base/share/classes/java/lang/Process.java line 504: > >> 502: */ >> 503: public boolean waitFor(Duration duration) throws InterruptedException { >> 504: Objects.requireNonNull(duration, "duration"); > > Does this explicit null-check pull its weight here? Maybe not, but when this method gets a custom implementation, people don't have to remember to add a null check at front so there's no path that misses the NPE. It isn't wrong, so I don't see a problem with this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683588397 From naoto at openjdk.org Fri Jul 19 00:42:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 19 Jul 2024 00:42:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: <1c_hQHyD2LrOjoSFB6kCnYWHYme89pAx2LmfTGlI7I4=.6ca449bb-ca65-4766-be87-46c26e2e01e0@github.com> Message-ID: <2IhdsH-WETB5A23YnZ4D53Wd454NjydEcvUMiEaxcds=.822db39b-a73c-4695-9347-be825106ae06@github.com> On Thu, 18 Jul 2024 23:02:53 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/Process.java line 504: >> >>> 502: */ >>> 503: public boolean waitFor(Duration duration) throws InterruptedException { >>> 504: Objects.requireNonNull(duration, "duration"); >> >> Does this explicit null-check pull its weight here? > > Maybe not, but when this method gets a custom implementation, people don't have to remember to add a null check at front so there's no path that misses the NPE. It isn't wrong, so I don't see a problem with this. Maybe it's a personal preference, but I think it is a good practice to explicitly check non-null for public APIs. Some recent methods in that class, such as `inputReader(Charset)` do it, so there are precedences. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1683633761 From duke at openjdk.org Fri Jul 19 00:45:59 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 00:45:59 GMT Subject: RFR: 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat Message-ID: The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder ------------- Commit messages: - use StringBuilder#repeat append zeros Changes: https://git.openjdk.org/jdk/pull/20245/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20245&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336792 Stats: 12 lines in 1 file changed: 2 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20245.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20245/head:pull/20245 PR: https://git.openjdk.org/jdk/pull/20245 From duke at openjdk.org Fri Jul 19 01:28:36 2024 From: duke at openjdk.org (lingjun-cg) Date: Fri, 19 Jul 2024 01:28:36 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v17] In-Reply-To: References: <72jz9brO1nItDKitOCrcGYQMiEv4GKKfMUQvASiVH4c=.903656b2-bb11-40b3-b1a5-fe472d729a22@github.com> Message-ID: On Mon, 8 Jul 2024 16:31:23 GMT, Naoto Sato wrote: >> Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`? >> >> In the ClassFile API, there are similar "behave as if" notes such as https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438, yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same. > >> Quick question about the violation of the "This is equivalent to" spec: Does our new implementation lead to any observable side effects that make the returned results or thrown exceptions different from that of `format(obj, new StringBuffer(), new FieldPosition(0)).toString()`? >> >> In the ClassFile API, there are similar "behave as if" notes such as >> >> https://github.com/openjdk/jdk/blob/3f37c5718d676b7001e6a084aed3ba645745a144/src/java.base/share/classes/java/lang/classfile/ClassFile.java#L433-L438 >> >> , yet we don't restrict implementations as the API surface, including the return an exception result and side effects are the same. > > AFAIK, there will be no behavioral difference, but I think CSR has to be accompanied with this issue to remove that wording, because it is not correct anymore. @naotoj The CSR has been approved. Is it enough to start new review process? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2237844937 From liach at openjdk.org Fri Jul 19 02:01:52 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 02:01:52 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation Message-ID: `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. Depends on #20205. ------------- Depends on: https://git.openjdk.org/jdk/pull/20205 Commit messages: - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation Changes: https://git.openjdk.org/jdk/pull/20247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336754 Stats: 218 lines in 18 files changed: 60 ins; 116 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From liach at openjdk.org Fri Jul 19 02:17:33 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 02:17:33 GMT Subject: RFR: 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat In-Reply-To: References: Message-ID: <6nnYvAdJa9q_r1f0bjCD1I09EdL5ET371RzUSwSPi-8=.8bbd567a-6d68-4c4d-8c66-b5364fbd510d@github.com> On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen wrote: > The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder Looks good and simple. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20245#pullrequestreview-2187172092 From jpai at openjdk.org Fri Jul 19 03:49:35 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 03:49:35 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater In-Reply-To: References: Message-ID: <3kKumdtdJGus7akHo53WOZLitXr7J89VQG_ABrOYVYc=.25e4bfe0-0493-46dc-b9fe-95bda59012ca@github.com> On Wed, 17 Jul 2024 21:07:23 GMT, Archie Cobbs wrote: > The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. > > However, while `DeflaterOutputStream` provides constructors that take a custom `Deflater` argument supplied by the caller, `GZIPOutputStream` has no such constructors. > > As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level. > > This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`. Hello Chen, yes this PR and another one from Archie in this area is on my list to review. I'll be getting to this one shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2238060585 From jpai at openjdk.org Fri Jul 19 04:06:42 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 04:06:42 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:42:17 GMT, SendaoYan wrote: >> Hi all, >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. >> Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. >> Only change the testcase, the change has been verified, no risk. > >> Unfortunately I'm not familiar with these tests. > >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. > > Can you confirm that the codecache usage increased is expected or not after [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) with -Xcomp jvm option. @sendaoYan, Given Adam's inputs and the reviews you have had for this change, I think you should be able to go ahead and integrate this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238072647 From jpai at openjdk.org Fri Jul 19 04:18:32 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 04:18:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > removed a blank line Thank you Naoto, the updated changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20220#pullrequestreview-2187267936 From dholmes at openjdk.org Fri Jul 19 05:53:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Jul 2024 05:53:02 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Note this is simply a re-generation of the troff files from their sources. If there are any problems that need fixing then a new JBS issue has to be filed to update the source file and regenerate the troff file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238248354 From dholmes at openjdk.org Fri Jul 19 05:53:01 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Jul 2024 05:53:01 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC Message-ID: Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. This also picks up the unpublished changes to java.1 from: - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC And a typo crept in to java.1 from: - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal This also picks up the unpublished change to keytool.1 from: - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints This also picks up the unpublished change to javadoc.1 from: - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). Thanks. ------------- Commit messages: - 8325280: Update troff manpages in JDK 23 before RC Changes: https://git.openjdk.org/jdk/pull/20248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325280 Stats: 142 lines in 28 files changed: 51 ins; 52 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/20248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20248/head:pull/20248 PR: https://git.openjdk.org/jdk/pull/20248 From syan at openjdk.org Fri Jul 19 06:12:36 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Jul 2024 06:12:36 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:42:17 GMT, SendaoYan wrote: >> Hi all, >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. >> Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. >> Only change the testcase, the change has been verified, no risk. > >> Unfortunately I'm not familiar with these tests. > >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. > > Can you confirm that the codecache usage increased is expected or not after [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) with -Xcomp jvm option. > @sendaoYan, Given Adam's inputs and the reviews you have had for this change, I think you should be able to go ahead and integrate this. Thanks all for the review. Can you sponsor this PR for me. @jaikiran ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238306043 From duke at openjdk.org Fri Jul 19 06:12:37 2024 From: duke at openjdk.org (duke) Date: Fri, 19 Jul 2024 06:12:37 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. @sendaoYan Your change (at version a7c1d63434bbb24122f4256cb695129afac70804) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238311075 From syan at openjdk.org Fri Jul 19 07:10:37 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Jul 2024 07:10:37 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Thanks for the sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238518349 From syan at openjdk.org Fri Jul 19 07:10:38 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Jul 2024 07:10:38 GMT Subject: Integrated: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: <0QhSjAuTPmCWwJIkMyPmeMjN_RpNMFeQQ-h44p2LOBo=.e8d47427-a3d3-4f30-aa45-65b19bc1eb7d@github.com> On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. This pull request has now been integrated. Changeset: fa5ad700 Author: SendaoYan Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/fa5ad700bb6a92aef7577969e09b4fbd93feb388 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 Reviewed-by: lmesnik, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/19864 From asotona at openjdk.org Fri Jul 19 07:12:35 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 07:12:35 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 22:56:10 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > 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 ten additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge BoundAttributeTest > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - 2 test failures > - Web review cleanup > - Remove WritableElement and reduce Writable usage > > The rest of Writable in annotations can be removed in later cleanup > - Fix up usages of Util.write > - Hide writeTo from all class file elements > > To consider the fate of WritableElement later! Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20205#pullrequestreview-2187499298 From sspitsyn at openjdk.org Fri Jul 19 08:00:36 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 19 Jul 2024 08:00:36 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:18:08 GMT, Alan Bateman wrote: > I will check but there are a few renames that have to keep the initial year. Also there are some new files that have been checked into the loom repo for a long time so they have their initial year too. Okay, thanks. >> test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 1113: >> >>> 1111: @Test >>> 1112: void testYield3() throws Exception { >>> 1113: assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers"); >> >> Q: What was the reason to rename `testYield2()` to `testYield3()`? > > There are a lot of tests that can't be proposed to main line at this time because they depend on the object monitor work. This is one such "gap" where testYield2 can't be added. I can re-number them if you want to avoid the gap but there are other changes that rename several test methods so I'd prefer to leave it until then. Okay, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20143#issuecomment-2238590482 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1683973972 From asotona at openjdk.org Fri Jul 19 08:06:37 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 08:06:37 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors In-Reply-To: <5GQMlKLvx_SAcLW3eItg1tkEL-C2vASmqEC9EyVbNd4=.e204663a-0e79-43f2-b9e1-4fb5597cd835@github.com> References: <5GQMlKLvx_SAcLW3eItg1tkEL-C2vASmqEC9EyVbNd4=.e204663a-0e79-43f2-b9e1-4fb5597cd835@github.com> Message-ID: On Thu, 18 Jul 2024 21:57:52 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java line 117: >> >>> 115: >>> 116: public static List verify(ClassModel classModel, ClassHierarchyResolver classHierarchyResolver, Consumer logger) { >>> 117: String clsName = classModel.thisClass().asInternalName(); >> >> This can still throw `ConstantPoolException` if this_class points to a non-Class entry. This entry is lazily read by `ClassReader`, so you can create a `ClassModel` for such a bad class. > > Alternatively, a malformed Class constant can point to a non-utf8, so the `asInternalName` can fail too. Right, it will still throw if you pass a broken model to `ClassFile::verify(ClassModel)`. I'll catch this top-level exception in both `ClassFile::verify` methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20241#discussion_r1683981268 From asotona at openjdk.org Fri Jul 19 08:18:45 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 08:18:45 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors [v2] In-Reply-To: References: Message-ID: > `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. > `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. > > This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. > > Relevant test is added. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: wrapped ClassFile::verify(Method) + added test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20241/files - new: https://git.openjdk.org/jdk/pull/20241/files/32476edf..c5f6e018 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20241&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20241&range=00-01 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20241/head:pull/20241 PR: https://git.openjdk.org/jdk/pull/20241 From asotona at openjdk.org Fri Jul 19 08:26:46 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 08:26:46 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors [v3] In-Reply-To: References: Message-ID: > `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. > `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. > > This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. > > Relevant test is added. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: nit change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20241/files - new: https://git.openjdk.org/jdk/pull/20241/files/c5f6e018..af796a0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20241&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20241&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20241/head:pull/20241 PR: https://git.openjdk.org/jdk/pull/20241 From alanb at openjdk.org Fri Jul 19 08:29:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Jul 2024 08:29:36 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Marked as reviewed by alanb (Reviewer). Thanks for the tireless effort to update the man pages at the end of each release. ------------- PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2187669729 PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238647463 From eirbjo at openjdk.org Fri Jul 19 09:35:35 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 19 Jul 2024 09:35:35 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Bump @since from 23 to 24. > - Merge branch 'master' into JDK-8322256 > - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. > - Simplify code by eliminating an impossible case. > - Field name change and Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Clarify exceptions: sometimes ZipException, sometimes EOFException. > - Merge branch 'master' into JDK-8322256 > - ... and 2 more: https://git.openjdk.org/jdk/compare/75dc2f85...f845a75b I'm late to the table for this PR, but could we stop a moment to consider whether boolean constructor arguments is the best way to represent and compose optional parser configuration? Boolean options by themselves can be tricky in that it requires knowing/understanding what the negative and positive is. Multiple constructor arguments of the same type makes it easy to mistake the order of the options while writing code. Reading the constructor with new GZIPInputStream(in, size, true, true), forces you to read the constructor documentation, figure out which of the boolean options is which, then what they represent. What if someone wants to introduce other options in the future, how will that scale? I'm not sure what a better alternative would be, but I'm sure we must have prior art in parser configuration in the JDK? Perhaps enums for the options, or composing constant int fields would be an improvement? Again, not sure what the optimal API solution is here, just wanted to raise the concern :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2238752137 From eirbjo at openjdk.org Fri Jul 19 09:59:36 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 19 Jul 2024 09:59:36 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Bump @since from 23 to 24. > - Merge branch 'master' into JDK-8322256 > - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. > - Simplify code by eliminating an impossible case. > - Field name change and Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - Clarify exceptions: sometimes ZipException, sometimes EOFException. > - Merge branch 'master' into JDK-8322256 > - ... and 2 more: https://git.openjdk.org/jdk/compare/75dc2f85...f845a75b src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 143: > 141: * @param allowConcatenation true to allow multiple concatenated compressed data streams, > 142: * or false to expect exactly one compressed data stream > 143: * @param ignoreExtraBytes true to tolerate and ignore extra bytes, false to throw The term "extra" here feels somewhat open to interpretation. Specifically, "extra" sounds like something that is out of the ordinary, but not uncommon or wrong. It could be used when describing an optional feature in a format specification. The API description referes to "unexpected data". Perhaps the word "unexpected" is more precise term to use in this option? So `ignoreUnexpectedBytes` or `ignoreUnexpectedData`. I think my eyebrows would be raised more when seeing someone ignoring 'unexpected data' rather than when ignoring 'extra data'. I know this might smell of bikeshedding, but naming is important (and hard!). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1684148142 From eirbjo at openjdk.org Fri Jul 19 10:05:35 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 19 Jul 2024 10:05:35 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: <1LpE3PouwnkAjmDiKs0y6eUsM6NrH-YbesXHLPFZcUs=.c38e1f6e-0d1c-4390-b575-733f051ea920@github.com> References: <1LpE3PouwnkAjmDiKs0y6eUsM6NrH-YbesXHLPFZcUs=.c38e1f6e-0d1c-4390-b575-733f051ea920@github.com> Message-ID: On Mon, 15 Jul 2024 10:01:47 GMT, Jaikiran Pai wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Bump @since from 23 to 24. >> - Merge branch 'master' into JDK-8322256 >> - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. >> - Simplify code by eliminating an impossible case. >> - Field name change and Javadoc wording tweaks. >> - Merge branch 'master' into JDK-8322256 >> - Javadoc wording tweaks. >> - Merge branch 'master' into JDK-8322256 >> - Clarify exceptions: sometimes ZipException, sometimes EOFException. >> - Merge branch 'master' into JDK-8322256 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/75dc2f85...f845a75b > > Hello Archie, sorry it has taken long to review this PR. > > The proposal here is to have `java.util.zip.GZIPInputStream` specify (and improve) how it deals with concatenated GZIP stream(s) and also allow for applications instantiating `GZIPInputStream` to decide whether or not the underlying `InputStream` passed to the `GZIPInputStream` instance is expected to contain a concatenated GZIP stream(s). > > I'll include here the text that I had sent in a private communication to Archie: > > I think this comes down to introducing a new optional boolean parameter to the constructor of GZIPInputStream. > > The boolean when "true" will attempt to read a potential additional GZIP stream after the previous GZIP stream's trailer has been read. In that case we need to handle 2 cases - one where we successfully find the header of the next (concatenated) GZIP stream and the other where we don't find a valid GZIP stream header. In the first case where we do find a header successfully, then we continue reading the stream as usual and return the uncompressed data from the "read()" call. In the case where we fail to find a valid header and yet there were bytes past the previous GZIP stream, then I think the GZIPInputStream.read() should throw an IOException, since that stream no longer represents a GZIP stream (remember, we are talking about this only when the GZIPInputStream was constructed with the new boolean parameter = true). > > Coming to the case where the GZIPInputStream was constructed using boolean = false - In this case when we reach and read the trailer of a GZIP stream, if there is no more bytes, then we consider this a completed GZIP stream and return the uncompressed data. If there is any more bytes past the GZIP stream's trailer, then I think we should throw a IOException (since we aren't expecting any concatenated GZIP stream). > > As for the default value of this optional boolean parameter, I think it should default to "true" implying it will read any concatenated GZIP streams. That would match the current implementation of GZIPInputStream.read() which has the ability to read (valid) GZIP concatenated input stream. > > I think this would then allow us to keep the implementation simple as well as allow the calling application to have control over whether or not the passed should be considered as having a concatenated GZIP stream. This PR is open, but notifications don't seem to reach the mailing lists. I experienced a similar situation a while back where I believe @jaikiran reached out to the Skara team to get that PR out of the silent state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2238816809 From lancea at openjdk.org Fri Jul 19 10:43:30 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 19 Jul 2024 10:43:30 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 21:07:23 GMT, Archie Cobbs wrote: > The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. > > However, while `DeflaterOutputStream` provides constructors that take a custom `Deflater` argument supplied by the caller, `GZIPOutputStream` has no such constructors. > > As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level. > > This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`. I understand the request here, but is there a current use case for needing a custom Deflater? Before adding additional features, I think GZIP could benefit with more test coverage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2238878240 From nbenalla at openjdk.org Fri Jul 19 11:47:43 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 19 Jul 2024 11:47:43 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation Message-ID: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). It's mostly fixing some relative links. If using `{@docroot}` isn't ideal I can change it. Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html 106c106 <

--- >

diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html 99c99 <

--- > 106c106 <

--- > 618c618 <

--- > 755c755 <

--- > 783c783 <

--- > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html 142c142 < the segments allocated by it) becomes unreachable, --- > the segments allocated by it) becomes unreachable, diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html 120c120 < as long as it is reachable. --- > as long as it is reachable. diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html 1420c1420 < kept reachable --- > kept reachable 1833c1833 < unreachable. --- > unreachable. 1899c1899 < unreachable. --- > unreachable. diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html 395c395 < unreachable. The --- > unreachable. The diff -r docs-master/api/java.base/java/net/spi/InetAddressResolver.LookupPolicy.html docs/api/java.base/java/net/spi/InetAddressResolver.LookupPolicy.html 117c117 < System Properties which affect --- > System Properties which affect diff -r docs-master/api/java.base/java/text/MessageFormat.html docs/api/java.base/java/text/MessageFormat.html 433,434c433 < <

--- >

diff -r docs-master/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnFailure.html docs/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnFailure.html 245c245 < Tree Structure section in the class description --- > Tree Structure section in the class description diff -r docs-master/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnSuccess.html docs/api/java.base/java/util/concurrent/StructuredTaskScope.ShutdownOnSuccess.html 242c242 < Tree Structure section in the class description --- > Tree Structure section in the class description diff -r docs-master/api/java.base/javax/security/auth/Subject.html docs/api/java.base/javax/security/auth/Subject.html 207,208c207,208 < whether a security manager is < allowed or disallowed: --- > whether a security manager is > allowed or disallowed: ------------- Commit messages: - (C) - Merge remote-tracking branch 'upstream/master' into fix-broken-links-java-base - remove html warnings, broken links Changes: https://git.openjdk.org/jdk/pull/20251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336039 Stats: 23 lines in 9 files changed: 0 ins; 1 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/20251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20251/head:pull/20251 PR: https://git.openjdk.org/jdk/pull/20251 From aturbanov at openjdk.org Fri Jul 19 12:16:31 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 19 Jul 2024 12:16:31 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: <3p2YR8paCauJdaCur6ZE_G5eOzcV_Dzssfhb3mV7u4w=.928ed8e6-07bc-4db0-bd82-9a7fc22397a2@github.com> On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java line 216: > 214: var started = new CountDownLatch(1); > 215: var entered = new AtomicBoolean(); > 216: Thread vthread = Thread.ofVirtual().unstarted(() -> { Suggestion: Thread vthread = Thread.ofVirtual().unstarted(() -> { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1684290798 From aturbanov at openjdk.org Fri Jul 19 12:19:37 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 19 Jul 2024 12:19:37 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java line 126: > 124: int count = getCount(); > 125: if (count != i * THREADS) { > 126: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count + Suggestion: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count + test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java line 136: > 134: int count = getCount(); > 135: if (count != ITERATIONS * THREADS) { > 136: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count); Suggestion: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count); test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java line 217: > 215: int count = getCount(); > 216: if (count != THREADS * ITERATIONS) { > 217: throw new RuntimeException("RandomDepthTest: Invalid Count " + count); Suggestion: throw new RuntimeException("RandomDepthTest: Invalid Count " + count); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1684293578 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1684293811 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1684293954 From liach at openjdk.org Fri Jul 19 12:20:31 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 12:20:31 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 08:26:46 GMT, Adam Sotona wrote: >> `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. >> `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. >> >> This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. >> >> Relevant test is added. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > nit change Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20241#pullrequestreview-2188091936 From djelinski at openjdk.org Fri Jul 19 12:39:31 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 19 Jul 2024 12:39:31 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: On Fri, 19 Jul 2024 11:11:38 GMT, Nizar Benalla wrote: > Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). > > It's mostly fixing some relative links. > If using `{@docroot}` isn't ideal I can change it. > > Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes > > > diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html > 106c106 > <

> --- >>

> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html > 99c99 > <

> --- >> > 106c106 > <

> --- >> > 618c618 > <

> --- >> > 755c755 > <

> --- >> > 783c783 > <

> --- >> > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html > 142c142 > < the segments allocated by it) becomes unreachable, > --- >> the segments allocated by it) becomes unreachable, > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html > 120c120 > < as long as it is reachable. > --- >> as long as it is reachable. > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html > 1420c1420 > < kept reachable > --- >> kept reachable > 1833c1833 > < unreachable. > --- >> unreachable. > 1899c1899 > < unreachable. > --- >> unreachable. > diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html > 395c395 > < unreachable. The > --- >> These methods behave differently depending on Suggestion: *

These methods behave differently depending on We seem to mix `

References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: On Fri, 19 Jul 2024 11:11:38 GMT, Nizar Benalla wrote: > Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). > > It's mostly fixing some relative links. > If using `{@docroot}` isn't ideal I can change it. > > Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes > > > diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html > 106c106 > <

> --- >>

> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html > 99c99 > <

> --- >> > 106c106 > <

> --- >> > 618c618 > <

> --- >> > 755c755 > <

> --- >> > 783c783 > <

> --- >> > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html > 142c142 > < the segments allocated by it) becomes unreachable, > --- >> the segments allocated by it) becomes unreachable, > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html > 120c120 > < as long as it is reachable. > --- >> as long as it is reachable. > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html > 1420c1420 > < kept reachable > --- >> kept reachable > 1833c1833 > < unreachable. > --- >> unreachable. > 1899c1899 > < unreachable. > --- >> unreachable. > diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html > 395c395 > < unreachable. The > --- >> Tree Structure section in the class description (untested, but should work) Suggestion: * {@linkplain StructuredTaskScope##TreeStructure Tree Structure} section in the class description ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684324692 From jkratochvil at openjdk.org Fri Jul 19 12:48:41 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 19 Jul 2024 12:48:41 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v15] In-Reply-To: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> References: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> Message-ID: <1RNpyynIn1GXmC8CEdFuTeEP2X2V099XZ6HSHiOEhHM=.7be9af67-ddaf-4673-a8c4-50743e6975b2@github.com> On Thu, 18 Jul 2024 14:48:02 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Fix by Severin Gehwolf. >> Testcase by Jan Kratochvil. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > Unify 4 copies of adjust_controller() @tstuefe, @jdksjolen, any time for a review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2239060057 From nbenalla at openjdk.org Fri Jul 19 13:08:06 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 19 Jul 2024 13:08:06 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v2] In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: > Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). > > It's mostly fixing some relative links. > If using `{@docroot}` isn't ideal I can change it. > > Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes > > > diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html > 106c106 > <

> --- >>

> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html > 99c99 > <

> --- >> > 106c106 > <

> --- >> > 618c618 > <

> --- >> > 755c755 > <

> --- >> > 783c783 > <

> --- >> > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html > 142c142 > < the segments allocated by it) becomes unreachable, > --- >> the segments allocated by it) becomes unreachable, > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html > 120c120 > < as long as it is reachable. > --- >> as long as it is reachable. > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html > 1420c1420 > < kept reachable > --- >> kept reachable > 1833c1833 > < unreachable. > --- >> unreachable. > 1899c1899 > < unreachable. > --- >> unreachable. > diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html > 395c395 > < unreachable. The > --- >> Tree Structure section in the class description > > (untested, but should work) > Suggestion: > > * {@linkplain StructuredTaskScope##TreeStructure Tree Structure} section in the class description Fixed in [31649c7](https://github.com/openjdk/jdk/pull/20251/commits/31649c743e709cd67bd132774636e3484939890c), thanks. > src/java.base/share/classes/javax/security/auth/Subject.java line 111: > >> 109: * input type and exceptions thrown are slightly different. >> 110: * >> 111: *

These methods behave differently depending on > > Suggestion: > > *

These methods behave differently depending on > > We seem to mix `

References: Message-ID: On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Use StringBuilder internally for java.text.Format.* formatting Testing tier 1-3 passed. src/java.base/share/classes/java/text/Format.java line 164: > 162: */ > 163: public final String format (Object obj) { > 164: if ("java.text".equals(getClass().getPackageName())) { We can use `==` for performance as getPackageName is interned. src/java.base/share/classes/java/text/SimpleDateFormat.java line 1450: > 1448: //User can set numberFormat with a user-defined NumberFormat which > 1449: //not override format(long, StringBuf, FieldPosition). > 1450: if ("java.text".equals(numberFormat.getClass().getPackageName())) { Same packagename remark ------------- PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2188186196 PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684349563 PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684353454 From asotona at openjdk.org Fri Jul 19 13:12:41 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 13:12:41 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 08:26:46 GMT, Adam Sotona wrote: >> `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. >> `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. >> >> This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. >> >> Relevant test is added. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > nit change Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20241#issuecomment-2239099479 From asotona at openjdk.org Fri Jul 19 13:12:41 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 13:12:41 GMT Subject: Integrated: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 16:23:44 GMT, Adam Sotona wrote: > `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. > `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. > > This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. > > Relevant test is added. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: c25c4896 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/c25c4896ad9ef031e3cddec493aef66ff87c48a7 Stats: 44 lines in 4 files changed: 37 ins; 0 del; 7 mod 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/20241 From liach at openjdk.org Fri Jul 19 13:14:33 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 13:14:33 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v2] In-Reply-To: References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: On Fri, 19 Jul 2024 13:08:06 GMT, Nizar Benalla wrote: >> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). >> >> It's mostly fixing some relative links. >> If using `{@docroot}` isn't ideal I can change it. >> >> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes >> >> >> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html >> 106c106 >> <

>> --- >>>

>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html >> 99c99 >> <

>> --- >>> >> 106c106 >> <

>> --- >>> >> 618c618 >> <

>> --- >>> >> 755c755 >> <

>> --- >>> >> 783c783 >> <

>> --- >>> >> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html >> 142c142 >> < the segments allocated by it) becomes unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > remove docroot based on review src/java.base/share/classes/java/lang/classfile/components/CodeStackTracker.java line 40: > 38: *

> 39: * Sample use: > 40: *

This `

` intends to add a break. So I think you can just remove this new paragraph, like you've done below. src/java.base/share/classes/java/lang/foreign/Arena.java line 64: > 62: * such, the regions of memory backing memory segments allocated with the automatic arena > 63: * are deallocated at some unspecified time after the automatic arena (and all > 64: * the segments allocated by it) becomes unreachable, Suggestion: * the segments allocated by it) becomes {@linkplain java.lang.ref##reachability unreachable}, same for other occurrences. src/java.base/share/classes/java/text/MessageFormat.java line 374: > 372: * In internationalized programs, the message format pattern and other > 373: * static strings will likely be obtained from resource bundles. > 374: *

Same here, just remove `

` instead of adding a closing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684357333 PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684360034 PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684361244 From jpai at openjdk.org Fri Jul 19 13:22:37 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 13:22:37 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v8] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 21:36:54 GMT, Liam Miller-Cushon wrote: >> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. > > Liam Miller-Cushon 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 10 additional commits since the last revision: > > - Add a missing `break` > - Merge branch 'master' into JDK-8328995 > - Merge remote-tracking branch 'origin/master' into JDK-8328995 > - Move test to test/jdk/tools/launcher > - Add some more comments > - Maximum Zip64 extra field length is 32 > - Make cendsk an unsigned short > - Fix disk number size > - Improvements > > * don't rely on variable length arrays > * only run the test of 64 bit machines, since it requires >4GB of heap > - 8328995: launcher can't open jar files where the offset of the manifest is >4GB src/java.base/share/native/libjli/parse_manifest.c line 186: > 184: } > 185: > 186: /** Nit: For the sake of consistency with the rest of the comments in this file, this comment should be a `/*` instead of `/**` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1684376439 From asotona at openjdk.org Fri Jul 19 13:25:31 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 13:25:31 GMT Subject: RFR: 8336777: BufferedMethodBuilder not initialized with static flag In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 22:21:08 GMT, Chen Liang wrote: > `BufferedMethodBuilder` accepts a static flag and passes it to the `CodeBuilder` it creates; yet it does not prevent static flag tampering like `DirectMethodBuilder` does. This patch makes their behaviors consistent. > > Note that the throwing of IAE is provisional; it is open to discussion later. Looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20244#pullrequestreview-2188235046 From duke at openjdk.org Fri Jul 19 13:31:57 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 13:31:57 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat Message-ID: Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. ------------- Commit messages: - copyright 2024 - optimize String.concat Changes: https://git.openjdk.org/jdk/pull/20253/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336831 Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20253/head:pull/20253 PR: https://git.openjdk.org/jdk/pull/20253 From duke at openjdk.org Fri Jul 19 13:31:57 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 13:31:57 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 13:10:43 GMT, Shaojin Wen wrote: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Below are the performance numbers running on a MacBook M1 Pro, which is 8.71% faster -Benchmark (intValue) Mode Cnt Score Error Units -StringConcat.concatMethodConstString 4711 avgt 15 5.499 ? 0.046 ns/op +Benchmark (intValue) Mode Cnt Score Error Units +StringConcat.concatMethodConstString 4711 avgt 15 5.058 ? 0.012 ns/op +8.71% ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2239120831 From asotona at openjdk.org Fri Jul 19 13:33:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 13:33:33 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang wrote: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 302: > 300: } > 301: > 302: public static void writeTypeAnnotation(BufWriterImpl buf, TypeAnnotation ta) { Is there any reason to move writeTypeAnnotation from UnboundAttribute? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1684390757 From liach at openjdk.org Fri Jul 19 13:48:33 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 13:48:33 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation In-Reply-To: References: Message-ID: <_NIaBMC4ojyen8rfaQC1XrPs4SHefLQRjnq9Ujb75gs=.ffe05c46-d2ba-435a-bb51-fca12b407a8e@github.com> On Fri, 19 Jul 2024 13:30:44 GMT, Adam Sotona wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 302: > >> 300: } >> 301: >> 302: public static void writeTypeAnnotation(BufWriterImpl buf, TypeAnnotation ta) { > > Is there any reason to move writeTypeAnnotation from UnboundAttribute? This is for consistency with reading annotations: they are now defined in the same file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1684409764 From asotona at openjdk.org Fri Jul 19 13:54:02 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 13:54:02 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang wrote: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2188296784 From nbenalla at openjdk.org Fri Jul 19 14:05:07 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 19 Jul 2024 14:05:07 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v3] In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: > Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). > > It's mostly fixing some relative links. > If using `{@docroot}` isn't ideal I can change it. > > Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes > > > diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html > 106c106 > <

> --- >>

> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html > 99c99 > <

> --- >> > 106c106 > <

> --- >> > 618c618 > <

> --- >> > 755c755 > <

> --- >> > 783c783 > <

> --- >> > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html > 142c142 > < the segments allocated by it) becomes unreachable, > --- >> the segments allocated by it) becomes unreachable, > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html > 120c120 > < as long as it is reachable. > --- >> as long as it is reachable. > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html > 1420c1420 > < kept reachable > --- >> kept reachable > 1833c1833 > < unreachable. > --- >> unreachable. > 1899c1899 > < unreachable. > --- >> unreachable. > diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html > 395c395 > < unreachable. The > --- >> unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > remove docroot based on review I replaced usages of `href` with `@linkplain` and removed unnecessary `

` tags ------------- PR Comment: https://git.openjdk.org/jdk/pull/20251#issuecomment-2239258426 From acobbs at openjdk.org Fri Jul 19 14:09:32 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 19 Jul 2024 14:09:32 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 10:41:05 GMT, Lance Andersen wrote: > I understand the request here, but is there a current use case for needing a custom Deflater? I think the primary use case is when you want to set a non-default compression level, e.g., "best" or "fast". This is a pretty normal thing to do and matches what people expect from the `gzip(1)` command line flags. Allowing a custom `Deflater` is the simplest way to accomplish this; it also solves some other less common use cases, e.g., you want to set "no compression" for an already compressed file, or you want to keep the `Deflater` open so you can gather stats or whatever. > Before adding additional features, I think GZIP could benefit with more test coverage. Agreed. `GZIPOutputStream` does get some coverage in some of the `GZIPInputStream` tests, and this PR adds more testing, but certainly more is better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2239264081 From jpai at openjdk.org Fri Jul 19 14:18:36 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 14:18:36 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v8] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 21:36:54 GMT, Liam Miller-Cushon wrote: >> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. > > Liam Miller-Cushon 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 10 additional commits since the last revision: > > - Add a missing `break` > - Merge branch 'master' into JDK-8328995 > - Merge remote-tracking branch 'origin/master' into JDK-8328995 > - Move test to test/jdk/tools/launcher > - Add some more comments > - Maximum Zip64 extra field length is 32 > - Make cendsk an unsigned short > - Fix disk number size > - Improvements > > * don't rely on variable length arrays > * only run the test of 64 bit machines, since it requires >4GB of heap > - 8328995: launcher can't open jar files where the offset of the manifest is >4GB src/java.base/share/native/libjli/parse_manifest.c line 507: > 505: || censiz == ZIP64_MAGICVAL > 506: || cenoff == ZIP64_MAGICVAL) > 507: && cenext > 0) { I went through these changes and here's my first round of review. Before the changes proposed in this PR, this part of the code which is responsible for finding and returning a constructed zip entry instance would blindly use the local header offset value from the central directory of the entry being looked up. It would then "seek" to that position and read the metadata of that entry (details like uncompressed length, compressed length, the compression method) and return back that entry instance. Clearly this isn't right when zip64 entries are involved since various details of such an entry can reside in the zip64 extra field block of that entry instead of being in the central directory. This change proposes that this part of the code first identify that a zip64 extra block exists for a particular entry and then read that zip64 block, validate some parts of the zip64 block and if that validation succeeds, then use the entry metadata from the zip64 block for constructing and returning the entry instance. The idea to identify and support zip64 entries in this part of the code I think is agreed as the right one. Coming to the implementation, I think we need to come to an agreement on what we want to do here. Specifically: - What logic do we use to decide when to look for zip64 extra block for an entry? The changes in this PR (at this line here) proposes that we look for zip64 extra block for an entry if any of the compressed size, uncompressed size or the local header offset value is `0xFFFFFFFFL` and the extra field size noted in this central directory entry is greater than 0. This however doesn't match with what we do in the implementation of `java.util.zip.ZipFile` which too does similar checks for zip64 entry presence when parsing the central directory. Very specifically, in the ZipFile where this logic is implemented is here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipFile.java#L1254. That code in the ZipFile has gone through the necessary vetting for dealing with various possibilities with the zip files. I think we should implement that same logic here while checking for zip64 entries. - The next one to decide is what kind of validations do we want to do in this code for zip64 extra field block. I think here too we should match whatever w currently do in the `java.util.zip.ZipFile` implementation, specifically what's being done in the `checkExtraFields` and `checkZip64ExtraFieldValues` methods of that class. - Next, what do we do when these validations fail. Right now in this proposed implementation, we appear to consider some validation failures as the entry being absent. My opinion is that we should be more stricter and fail the jar like we do in the implementation of `ZipFile` for such validation failures. One additional thing that this proposed change does is that it validates that the local header offset determined for an entry (either through the central directory or through the zip64 extra field block) does indeed point to a local header for an entry with the same file name. I don't think we do that in the ZipFile implementation. But I think doing that check in this code is fine. There are few other implementation details that I haven't commented about because they may not matter depending on what conclusions we arrive at for the above few points. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1684450259 From nbenalla at openjdk.org Fri Jul 19 14:20:48 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 19 Jul 2024 14:20:48 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v4] In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com> > Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). > > It's mostly fixing some relative links. > If using `{@docroot}` isn't ideal I can change it. > > Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes > > > diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html > 106c106 > <

> --- >>

> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html > 99c99 > <

> --- >> > 106c106 > <

> --- >> > 618c618 > <

> --- >> > 755c755 > <

> --- >> > 783c783 > <

> --- >> > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html > 142c142 > < the segments allocated by it) becomes unreachable, > --- >> the segments allocated by it) becomes unreachable, > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html > 120c120 > < as long as it is reachable. > --- >> as long as it is reachable. > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html > 1420c1420 > < kept reachable > --- >> kept reachable > 1833c1833 > < unreachable. > --- >> unreachable. > 1899c1899 > < unreachable. > --- >> unreachable. > diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html > 395c395 > < unreachable. The > --- >> unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > use @linkplain instead of href src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2665: > 2663: * garbage collector. A segment scope that is invalidated automatically is an > 2664: * automatic scope. An automatic scope is always {@link #isAlive() alive} > 2665: * as long as it is reachable. Suggestion: * as long as it is {@linkplain java.lang.ref##reachability reachable}. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684450266 From rriggs at openjdk.org Fri Jul 19 14:32:39 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Jul 2024 14:32:39 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 13:03:31 GMT, Chen Liang wrote: >> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: >> >> 8333396: Use StringBuilder internally for java.text.Format.* formatting > > src/java.base/share/classes/java/text/Format.java line 164: > >> 162: */ >> 163: public final String format (Object obj) { >> 164: if ("java.text".equals(getClass().getPackageName())) { > > We can use `==` for performance as getPackageName is interned. Using equals() is fine and the performance is the same. Using "==" may be fewer characters but carries with it the need to understand that the arguments are interned and that's not always obvious or known. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684469032 From rriggs at openjdk.org Fri Jul 19 14:50:32 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Jul 2024 14:50:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > removed a blank line Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20220#pullrequestreview-2188427974 From rriggs at openjdk.org Fri Jul 19 14:50:32 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Jul 2024 14:50:32 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: <-YwiNkhbOyG7emMi9WunX_ijLe9TSjmDpwgyblVPvaY=.09d378e8-c970-44c5-8076-e5dc6831e018@github.com> References: <4vicTmz9bmkIn52hMQlU5150BKwfcYI9eEG56ZtaWh4=.c95b0d47-a69b-41c5-a7df-07ad88d8f760@github.com> <-YwiNkhbOyG7emMi9WunX_ijLe9TSjmDpwgyblVPvaY=.09d378e8-c970-44c5-8076-e5dc6831e018@github.com> Message-ID: On Thu, 18 Jul 2024 21:50:31 GMT, Naoto Sato wrote: >> The `ProcessTools` override is a delegating override; I think it still makes sense and should be kept. > > I think the test tool should not depend on the internal implementation, so I think it should be kept. Its still unnecessary, adds bulk and maintenance overhead that will go unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1684496589 From lancea at openjdk.org Fri Jul 19 15:18:30 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 19 Jul 2024 15:18:30 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 14:07:07 GMT, Archie Cobbs wrote: > > I understand the request here, but is there a current use case for needing a custom Deflater? > > I think the primary use case is when you want to set a non-default compression level, e.g., "best" or "fast". This is a pretty normal thing to do and matches what people expect from the `gzip(1)` command line flags. Allowing a custom `Deflater` is the simplest way to accomplish this; it also solves some other less common use cases, e.g., you want to set "no compression" for an already compressed file, or you want to keep the `Deflater` open so you can gather stats or whatever. thank you Archie. I don't have an issue with the feature request, but given this API has been around for since JDK 1.1 and there has not been a must have push for this enhancement, I would prefer to focus on JDK-8322256 closed out and adding more overall test coverage before tackling this. > > > Before adding additional features, I think GZIP could benefit with more test coverage. > > Agreed. `GZIPOutputStream` does get some coverage in some of the `GZIPInputStream` tests, and this PR adds more testing, but certainly more is better. Yes which why we should look to add additional tests, including more coverage from gzip files created via the gzip command line tool. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2239437543 From rriggs at openjdk.org Fri Jul 19 15:19:34 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Jul 2024 15:19:34 GMT Subject: RFR: 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen wrote: > The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20245#pullrequestreview-2188493177 From lancea at openjdk.org Fri Jul 19 15:21:37 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 19 Jul 2024 15:21:37 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v8] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 14:16:21 GMT, Jaikiran Pai wrote: >> Liam Miller-Cushon 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 10 additional commits since the last revision: >> >> - Add a missing `break` >> - Merge branch 'master' into JDK-8328995 >> - Merge remote-tracking branch 'origin/master' into JDK-8328995 >> - Move test to test/jdk/tools/launcher >> - Add some more comments >> - Maximum Zip64 extra field length is 32 >> - Make cendsk an unsigned short >> - Fix disk number size >> - Improvements >> >> * don't rely on variable length arrays >> * only run the test of 64 bit machines, since it requires >4GB of heap >> - 8328995: launcher can't open jar files where the offset of the manifest is >4GB > > src/java.base/share/native/libjli/parse_manifest.c line 507: > >> 505: || censiz == ZIP64_MAGICVAL >> 506: || cenoff == ZIP64_MAGICVAL) >> 507: && cenext > 0) { > > I went through these changes and here's my first round of review. > > Before the changes proposed in this PR, this part of the code which is responsible for finding and returning a constructed zip entry instance would blindly use the local header offset value from the central directory of the entry being looked up. It would then "seek" to that position and read the metadata of that entry (details like uncompressed length, compressed length, the compression method) and return back that entry instance. Clearly this isn't right when zip64 entries are involved since various details of such an entry can reside in the zip64 extra field block of that entry instead of being in the central directory. > > This change proposes that this part of the code first identify that a zip64 extra block exists for a particular entry and then read that zip64 block, validate some parts of the zip64 block and if that validation succeeds, then use the entry metadata from the zip64 block for constructing and returning the entry instance. > > The idea to identify and support zip64 entries in this part of the code I think is agreed as the right one. > Coming to the implementation, I think we need to come to an agreement on what we want to do here. Specifically: > > - What logic do we use to decide when to look for zip64 extra block for an entry? The changes in this PR (at this line here) proposes that we look for zip64 extra block for an entry if any of the compressed size, uncompressed size or the local header offset value is `0xFFFFFFFFL` and the extra field size noted in this central directory entry is greater than 0. This however doesn't match with what we do in the implementation of `java.util.zip.ZipFile` which too does similar checks for zip64 entry presence when parsing the central directory. Very specifically, in the ZipFile where this logic is implemented is here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipFile.java#L1254. That code in the ZipFile has gone through the necessary vetting for dealing with various possibilities with the zip files. I think we should implement that same logic here while checking for zip64 entries. > - The next one to decide is what kind of validations do we want to do in this code for zip64 extra field block. I th... I have not had an opportunity for a deep dive of the changes in the PR, only a quick skim., but I agree we should add some additional validation similar to what was added to ZipFile ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1684534283 From cushon at openjdk.org Fri Jul 19 15:36:10 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 15:36:10 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v9] In-Reply-To: References: Message-ID: > This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Use /* instead of /** comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18479/files - new: https://git.openjdk.org/jdk/pull/18479/files/172609a3..18661092 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18479/head:pull/18479 PR: https://git.openjdk.org/jdk/pull/18479 From cushon at openjdk.org Fri Jul 19 15:36:13 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 15:36:13 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v8] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 13:19:52 GMT, Jaikiran Pai wrote: >> Liam Miller-Cushon 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 10 additional commits since the last revision: >> >> - Add a missing `break` >> - Merge branch 'master' into JDK-8328995 >> - Merge remote-tracking branch 'origin/master' into JDK-8328995 >> - Move test to test/jdk/tools/launcher >> - Add some more comments >> - Maximum Zip64 extra field length is 32 >> - Make cendsk an unsigned short >> - Fix disk number size >> - Improvements >> >> * don't rely on variable length arrays >> * only run the test of 64 bit machines, since it requires >4GB of heap >> - 8328995: launcher can't open jar files where the offset of the manifest is >4GB > > src/java.base/share/native/libjli/parse_manifest.c line 186: > >> 184: } >> 185: >> 186: /** > > Nit: For the sake of consistency with the rest of the comments in this file, this comment should be a `/*` instead of `/**` Fixed, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1684551384 From asotona at openjdk.org Fri Jul 19 15:37:00 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 15:37:00 GMT Subject: RFR: 8336833: Endless loop in Javap ClassWriter Message-ID: Artificially corrupted class with overflowing max - min values of `tableswitch` instruction cause infinite loop in `jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets` This patch fixes the overflow and adds relevant test. Please review. Thank you, Adam ------------- Commit messages: - 8336833: Endless loop in Javap ClassWriter Changes: https://git.openjdk.org/jdk/pull/20258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20258&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336833 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20258/head:pull/20258 PR: https://git.openjdk.org/jdk/pull/20258 From liach at openjdk.org Fri Jul 19 15:43:37 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 15:43:37 GMT Subject: RFR: 8336833: Endless loop in Javap ClassWriter In-Reply-To: References: Message-ID: <-j_EDYccq84rjJrGIFj13U9NQwoQ9QOCfhjxh4FS8ZQ=.c1c1f66c-7b09-4e2e-b32f-48a8b33ade28@github.com> On Fri, 19 Jul 2024 15:32:24 GMT, Adam Sotona wrote: > Artificially corrupted class with overflowing max - min values of `tableswitch` instruction cause infinite loop in `jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets` > > This patch fixes the overflow and adds relevant test. > > Please review. > > Thank you, > Adam src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 320: > 318: int low = code.classReader.readInt(ap + 4); > 319: int high = code.classReader.readInt(ap + 8); > 320: if (high < low || (long)high - low > code.codeLength >> 2) { Maybe `Integer.toUnsignedLong(high - low)` might be clearer? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20258#discussion_r1684560620 From liach at openjdk.org Fri Jul 19 15:44:34 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 15:44:34 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v4] In-Reply-To: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com> Message-ID: On Fri, 19 Jul 2024 14:20:48 GMT, Nizar Benalla wrote: >> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). >> >> It's mostly fixing some relative links. >> If using `{@docroot}` isn't ideal I can change it. >> >> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes >> >> >> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html >> 106c106 >> <

>> --- >>>

>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html >> 99c99 >> <

>> --- >>> >> 106c106 >> <

>> --- >>> >> 618c618 >> <

>> --- >>> >> 755c755 >> <

>> --- >>> >> 783c783 >> <

>> --- >>> >> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html >> 142c142 >> < the segments allocated by it) becomes unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java > > forgot this one > > Co-authored-by: Chen Liang Lgtm ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2188544805 From shade at openjdk.org Fri Jul 19 15:52:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 Jul 2024 15:52:14 GMT Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3] In-Reply-To: References: Message-ID: <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com> > [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks. > > We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `all` > - [x] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Amend the test case for guaranteing it works under different compilation regimes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20139/files - new: https://git.openjdk.org/jdk/pull/20139/files/79ece901..437f2329 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=01-02 Stats: 36 lines in 1 file changed: 18 ins; 7 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139 PR: https://git.openjdk.org/jdk/pull/20139 From djelinski at openjdk.org Fri Jul 19 15:53:34 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 19 Jul 2024 15:53:34 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v4] In-Reply-To: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com> Message-ID: On Fri, 19 Jul 2024 14:20:48 GMT, Nizar Benalla wrote: >> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). >> >> It's mostly fixing some relative links. >> If using `{@docroot}` isn't ideal I can change it. >> >> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes >> >> >> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html >> 106c106 >> <

>> --- >>>

>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html >> 99c99 >> <

>> --- >>> >> 106c106 >> <

>> --- >>> >> 618c618 >> <

>> --- >>> >> 755c755 >> <

>> --- >>> >> 783c783 >> <

>> --- >>> >> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html >> 142c142 >> < the segments allocated by it) becomes unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java > > forgot this one > > Co-authored-by: Chen Liang Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2188559747 From djelinski at openjdk.org Fri Jul 19 15:53:36 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 19 Jul 2024 15:53:36 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v2] In-Reply-To: References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: On Fri, 19 Jul 2024 13:11:05 GMT, Chen Liang wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> remove docroot based on review > > src/java.base/share/classes/java/lang/foreign/Arena.java line 64: > >> 62: * such, the regions of memory backing memory segments allocated with the automatic arena >> 63: * are deallocated at some unspecified time after the automatic arena (and all >> 64: * the segments allocated by it) becomes unreachable, > > Suggestion: > > * the segments allocated by it) becomes {@linkplain java.lang.ref##reachability unreachable}, > > same for other occurrences. TIL ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1684571249 From asotona at openjdk.org Fri Jul 19 15:53:34 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Jul 2024 15:53:34 GMT Subject: RFR: 8336833: Endless loop in Javap ClassWriter In-Reply-To: <-j_EDYccq84rjJrGIFj13U9NQwoQ9QOCfhjxh4FS8ZQ=.c1c1f66c-7b09-4e2e-b32f-48a8b33ade28@github.com> References: <-j_EDYccq84rjJrGIFj13U9NQwoQ9QOCfhjxh4FS8ZQ=.c1c1f66c-7b09-4e2e-b32f-48a8b33ade28@github.com> Message-ID: On Fri, 19 Jul 2024 15:41:07 GMT, Chen Liang wrote: >> Artificially corrupted class with overflowing max - min values of `tableswitch` instruction cause infinite loop in `jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets` >> >> This patch fixes the overflow and adds relevant test. >> >> Please review. >> >> Thank you, >> Adam > > src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 320: > >> 318: int low = code.classReader.readInt(ap + 4); >> 319: int high = code.classReader.readInt(ap + 8); >> 320: if (high < low || (long)high - low > code.codeLength >> 2) { > > Maybe `Integer.toUnsignedLong(high - low)` might be clearer? I think it is safer to convert to long beforehand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20258#discussion_r1684570869 From liach at openjdk.org Fri Jul 19 16:05:30 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 16:05:30 GMT Subject: RFR: 8336833: Endless loop in Javap ClassWriter In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 15:32:24 GMT, Adam Sotona wrote: > Artificially corrupted class with overflowing max - min values of `tableswitch` instruction cause infinite loop in `jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets` > > This patch fixes the overflow and adds relevant test. > > Please review. > > Thank you, > Adam Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20258#pullrequestreview-2188581388 From bpb at openjdk.org Fri Jul 19 16:34:32 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Jul 2024 16:34:32 GMT Subject: RFR: 8334758: Incorrect note in Javadoc for a few RandomGenerator methods In-Reply-To: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> References: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> Message-ID: On Fri, 12 Jul 2024 06:28:15 GMT, Raffaello Giulietti wrote: > Small corrections to @implSpec notes in a few methods in RandomGenerator. src/java.base/share/classes/java/util/random/RandomGenerator.java line 816: > 814: * distribution in the range 0 (inclusive) > 815: * to {@code bound} (exclusive). > 816: * It assumes the distribution of {@link #nextInt()} to be uniform in turn. Do you need "in turn" here (and in the other changes)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20152#discussion_r1684617106 From rgiulietti at openjdk.org Fri Jul 19 16:50:50 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 19 Jul 2024 16:50:50 GMT Subject: RFR: 8334758: Incorrect note in Javadoc for a few RandomGenerator methods [v2] In-Reply-To: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> References: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> Message-ID: > Small corrections to @implSpec notes in a few methods in RandomGenerator. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Improved wording. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20152/files - new: https://git.openjdk.org/jdk/pull/20152/files/b66988cd..f3f1bd6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20152&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20152&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20152/head:pull/20152 PR: https://git.openjdk.org/jdk/pull/20152 From aph at openjdk.org Fri Jul 19 16:51:01 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 19 Jul 2024 16:51:01 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v3] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: <7Kzb5V0WYTDNKGrZ7ugIELsASZhoMMJn3UTU_QFWq7Q=.7da728cd-061f-498d-a3a4-46e62c6020e8@github.com> > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request incrementally with four additional commits since the last revision: - Review feedback - Review feedback - Review feedback - Cleanup check_klass_subtype_fast_path for AArch64, deleting dead code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19989/files - new: https://git.openjdk.org/jdk/pull/19989/files/bfe9ceed..98f6b2b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=01-02 Stats: 127 lines in 4 files changed: 6 ins; 46 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From alanb at openjdk.org Fri Jul 19 16:59:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Jul 2024 16:59:54 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates [v2] In-Reply-To: References: Message-ID: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 Alan Bateman 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 - Fix typo in comment, missing copyright update, test nits - Merge - Drop JLA updates for this update - Merge - Merge - Update copyright headers - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20143/files - new: https://git.openjdk.org/jdk/pull/20143/files/1fad7dff..2d3bbf46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20143&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20143&range=00-01 Stats: 4362 lines in 184 files changed: 2873 ins; 856 del; 633 mod Patch: https://git.openjdk.org/jdk/pull/20143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20143/head:pull/20143 PR: https://git.openjdk.org/jdk/pull/20143 From bpb at openjdk.org Fri Jul 19 17:03:32 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Jul 2024 17:03:32 GMT Subject: RFR: 8334758: Incorrect note in Javadoc for a few RandomGenerator methods [v2] In-Reply-To: References: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> Message-ID: On Fri, 19 Jul 2024 16:50:50 GMT, Raffaello Giulietti wrote: >> Small corrections to @implSpec notes in a few methods in RandomGenerator. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Improved wording. Looks fine but maybe a second Reviewer should agree? ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20152#pullrequestreview-2188720979 From rgiulietti at openjdk.org Fri Jul 19 17:11:31 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 19 Jul 2024 17:11:31 GMT Subject: RFR: 8334758: Incorrect note in Javadoc for a few RandomGenerator methods [v2] In-Reply-To: References: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> Message-ID: <7LGjoWueswv2PyxnIuRUOxpU8XORDzSJy07K0AKy3pQ=.d51760c0-e692-41e2-91c3-f3828b2f38ba@github.com> On Fri, 19 Jul 2024 16:50:50 GMT, Raffaello Giulietti wrote: >> Small corrections to @implSpec notes in a few methods in RandomGenerator. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Improved wording. I guess that the approval of the CSR, once done, would "de-facto" count as a 2nd review? After all, this is a "CSR only" change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20152#issuecomment-2239698670 From naoto at openjdk.org Fri Jul 19 17:12:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 19 Jul 2024 17:12:32 GMT Subject: RFR: 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat In-Reply-To: References: Message-ID: <03vQdyS2YilbQPW7gaLOvrYirfr6fJiq2oDNGt-82lA=.609db38a-4118-4632-adcb-53752ae019c9@github.com> On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen wrote: > The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20245#pullrequestreview-2188736912 From liach at openjdk.org Fri Jul 19 17:17:31 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 17:17:31 GMT Subject: RFR: 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat In-Reply-To: References: Message-ID: <3_mApjCLauB3HwDzTBDa3eeqGjpLNzWNz3xl8Bcu7B8=.ac0b5bf2-cce3-4276-9201-8426b3bb08f2@github.com> On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen wrote: > The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder Tier 1-3 tests come back all passing as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20245#issuecomment-2239708288 From iris at openjdk.org Fri Jul 19 17:21:32 2024 From: iris at openjdk.org (Iris Clark) Date: Fri, 19 Jul 2024 17:21:32 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2188754909 From liach at openjdk.org Fri Jul 19 17:30:33 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 17:30:33 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 13:10:43 GMT, Shaojin Wen wrote: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Changes requested by liach (Reviewer). src/java.base/share/classes/java/lang/StringConcatHelper.java line 372: > 370: } > 371: byte coder = (byte) (s1.coder() | s2.coder()); > 372: int len = s1.length() + s2.length(); mix checks against length overflow but this algorithm does not. src/java.base/share/classes/java/lang/StringConcatHelper.java line 373: > 371: byte coder = (byte) (s1.coder() | s2.coder()); > 372: int len = s1.length() + s2.length(); > 373: byte[] buf = (byte[]) UNSAFE.allocateUninitializedArray(byte.class, len << coder); This adds maintenance burden in the long run if we are to move away from this API; recommended still sharing `StringConcatHelper.newArray`. ------------- PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2188370752 PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1684460929 PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1684528936 From liach at openjdk.org Fri Jul 19 17:38:30 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 17:38:30 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 13:10:43 GMT, Shaojin Wen wrote: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Also beware of #19927: it simplifies the prepend part. How does that patch run in your benchmark? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2239735711 From bpb at openjdk.org Fri Jul 19 18:25:31 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Jul 2024 18:25:31 GMT Subject: RFR: 8334758: Incorrect note in Javadoc for a few RandomGenerator methods [v2] In-Reply-To: <7LGjoWueswv2PyxnIuRUOxpU8XORDzSJy07K0AKy3pQ=.d51760c0-e692-41e2-91c3-f3828b2f38ba@github.com> References: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> <7LGjoWueswv2PyxnIuRUOxpU8XORDzSJy07K0AKy3pQ=.d51760c0-e692-41e2-91c3-f3828b2f38ba@github.com> Message-ID: On Fri, 19 Jul 2024 17:08:38 GMT, Raffaello Giulietti wrote: > I guess that the approval of the CSR, once done, would "de-facto" count as a 2nd review? I agree. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20152#issuecomment-2239863660 From duke at openjdk.org Fri Jul 19 19:18:43 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 19:18:43 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: References: Message-ID: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: share newArray ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20253/files - new: https://git.openjdk.org/jdk/pull/20253/files/a0fccb70..38a6f560 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=00-01 Stats: 14 lines in 1 file changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20253/head:pull/20253 PR: https://git.openjdk.org/jdk/pull/20253 From eirbjo at gmail.com Fri Jul 19 19:22:22 2024 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 19 Jul 2024 21:22:22 +0200 Subject: java.util.zip.ZipError seems unused In-Reply-To: <2E5AB0C6-9664-44B6-9513-41B1288B0E09@oracle.com> References: <2E5AB0C6-9664-44B6-9513-41B1288B0E09@oracle.com> Message-ID: Thanks Lance, I have filed the following enhancement request to track this: https://bugs.openjdk.org/browse/JDK-8336843 Eirik. On Sun, Jun 30, 2024 at 2:54?PM Lance Andersen wrote: > Hi Eirik, > > The removal of ZipError from ZipFile/ZipFileSystem/ZipFileSystemProvider > occurred via 8145260 and 8037394 for JDK 9 > > The test should also be re-written at this point > > Jai or I can make a pass to see if there are any external usages via a > corpus search but I tend to doubt it > > On Jun 30, 2024, at 3:20?AM, Eirik Bj?rsn?s wrote: > > Hi! > > The java.util.zip.ZipError class seems unused in OpenJDK. I assume this is > legacy from the native ZIP implementation in Java 8. > > This exception class extends InternalError and seems to have been added in > Java 6 to help compatibility with existing code catching InternalError > (JDK-4615343) > > This change also introduced the TestZipError test, which verified that > ZipError was thrown while enumerating a ZIP file which was changed after > being opened. The reimplementation of the ZIP implementation to Java > (JDK-8145260) updated this test to expect a ZipException instead of the > ZipError. > > Given that this class has now fallen out of use in OpenJDK, should we: > > 1: Deprecate it > 2: Deprecate it for removal > 3: Do nothing, keeping it around has a low cost > 4: Something else > > It would also be useful if someone with access to a large code corpus > could search for usages of this class so we could assess compatibility > concerns of removing it. > > Thanks, > Eirik. > > > [image: oracle_sig_logo.gif] > > > > > > > Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From duke at openjdk.org Fri Jul 19 19:26:32 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 19:26:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 19:18:43 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > share newArray I have changed it to a shared newArray, including out of bounds checking, The performance improvement is still the same as before. -Benchmark (intValue) Mode Cnt Score Error Units (master) -StringConcat.concatMethodConstString 4711 avgt 15 5.437 ? 0.073 ns/op +Benchmark (intValue) Mode Cnt Score Error Units (38a6f5602f0f1f4a9eec4b7f0ac1b5c4e661f667) +StringConcat.concatMethodConstString 4711 avgt 15 5.027 ? 0.080 ns/op +8.15% ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2239974521 From cushon at openjdk.org Fri Jul 19 19:39:58 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 19:39:58 GMT Subject: RFR: 8336844: ZipConstants64 defines duplicate constants ZIP64_EXTID and EXTID_ZIP64 Message-ID: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. ------------- Commit messages: - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64. Changes: https://git.openjdk.org/jdk/pull/20264/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20264&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336844 Stats: 10 lines in 6 files changed: 0 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20264/head:pull/20264 PR: https://git.openjdk.org/jdk/pull/20264 From duke at openjdk.org Fri Jul 19 20:16:32 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 20:16:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 17:35:45 GMT, Chen Liang wrote: > Also beware of #19927: it simplifies the prepend part. How does that patch run in your benchmark? The performance comparison I made is based on the latest master branch ([c25c4896ad9ef031e3cddec493aef66ff87c48a7](https://github.com/openjdk/jdk/commit/c25c4896ad9ef031e3cddec493aef66ff87c48a7)), after #19927. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240044327 From liach at openjdk.org Fri Jul 19 20:38:32 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 20:38:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 19:18:43 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > share newArray src/java.base/share/classes/java/lang/StringConcatHelper.java line 371: > 369: return new String(s1); > 370: } > 371: byte coder = (byte) (s1.coder() | s2.coder()); Suggestion: int coder = s1.coder() | s2.coder(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1684935704 From liach at openjdk.org Fri Jul 19 20:46:31 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 20:46:31 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 19:18:43 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > share newArray As annoying and risky as this first appeared, this patch is actually in quite good shape: The usage of `getBytes` is similar to those in StringUTF16, and there's no reason to further complicate this by splitting the handling into StringLatin1 and StringUTF16. ? Another question for you: can you check out the original form over here too? https://github.com/openjdk/jdk/commit/781fb29580b08fa659019a2da09488ee4711c017#diff-f8131d8a48caf7cfc908417fad241393c2ef55408172e9a28dcaa14b1d73e1fbL1968-L1981 `simpleConcat` is required to create new String objects and `String.concat` can just return the argument/original when one part is not empty. Is there any value to extract a common `doConcat` handling both non-empty strings, called by both methods after handling the empty cases? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240077201 From naoto at openjdk.org Fri Jul 19 20:49:38 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 19 Jul 2024 20:49:38 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Use StringBuilder internally for java.text.Format.* formatting LGTM. Thanks for the changes. src/java.base/share/classes/java/text/CompactNumberFormat.java line 583: > 581: && ((BigInteger) number).bitLength() < 64)) { > 582: return format(((Number) number).longValue(), toAppendTo, > 583: fieldPosition); This is a prime example for switch pattern match, but probably for another day. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2189197549 PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684957942 From liach at openjdk.org Fri Jul 19 20:56:37 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 20:56:37 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Use StringBuilder internally for java.text.Format.* formatting Looks good indeed! Thanks for your hard work. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19513#pullrequestreview-2189218782 From duke at openjdk.org Fri Jul 19 20:58:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 20:58:31 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: References: Message-ID: <6dpf5LDKHl3PYD4IcuIuZcq6FabmjarzRuDYzkaEwH4=.d3b257b6-04ec-4586-9582-624d241dcf16@github.com> On Fri, 19 Jul 2024 20:18:04 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> share newArray > > src/java.base/share/classes/java/lang/StringConcatHelper.java line 371: > >> 369: return new String(s1); >> 370: } >> 371: byte coder = (byte) (s1.coder() | s2.coder()); > > Suggestion: > > int coder = s1.coder() | s2.coder(); Converting coder to int type requires processing when calling new String(byte[], byte) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1684964122 From liach at openjdk.org Fri Jul 19 20:58:31 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 20:58:31 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: <6dpf5LDKHl3PYD4IcuIuZcq6FabmjarzRuDYzkaEwH4=.d3b257b6-04ec-4586-9582-624d241dcf16@github.com> References: <6dpf5LDKHl3PYD4IcuIuZcq6FabmjarzRuDYzkaEwH4=.d3b257b6-04ec-4586-9582-624d241dcf16@github.com> Message-ID: On Fri, 19 Jul 2024 20:55:03 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/StringConcatHelper.java line 371: >> >>> 369: return new String(s1); >>> 370: } >>> 371: byte coder = (byte) (s1.coder() | s2.coder()); >> >> Suggestion: >> >> int coder = s1.coder() | s2.coder(); > > Converting coder to int type requires processing when calling new String(byte[], byte) You are right, I ignored that `coder` is reused again below. My bad! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1684964634 From cushon at openjdk.org Fri Jul 19 21:10:33 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 19 Jul 2024 21:10:33 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v8] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 15:18:26 GMT, Lance Andersen wrote: >> src/java.base/share/native/libjli/parse_manifest.c line 507: >> >>> 505: || censiz == ZIP64_MAGICVAL >>> 506: || cenoff == ZIP64_MAGICVAL) >>> 507: && cenext > 0) { >> >> I went through these changes and here's my first round of review. >> >> Before the changes proposed in this PR, this part of the code which is responsible for finding and returning a constructed zip entry instance would blindly use the local header offset value from the central directory of the entry being looked up. It would then "seek" to that position and read the metadata of that entry (details like uncompressed length, compressed length, the compression method) and return back that entry instance. Clearly this isn't right when zip64 entries are involved since various details of such an entry can reside in the zip64 extra field block of that entry instead of being in the central directory. >> >> This change proposes that this part of the code first identify that a zip64 extra block exists for a particular entry and then read that zip64 block, validate some parts of the zip64 block and if that validation succeeds, then use the entry metadata from the zip64 block for constructing and returning the entry instance. >> >> The idea to identify and support zip64 entries in this part of the code I think is agreed as the right one. >> Coming to the implementation, I think we need to come to an agreement on what we want to do here. Specifically: >> >> - What logic do we use to decide when to look for zip64 extra block for an entry? The changes in this PR (at this line here) proposes that we look for zip64 extra block for an entry if any of the compressed size, uncompressed size or the local header offset value is `0xFFFFFFFFL` and the extra field size noted in this central directory entry is greater than 0. This however doesn't match with what we do in the implementation of `java.util.zip.ZipFile` which too does similar checks for zip64 entry presence when parsing the central directory. Very specifically, in the ZipFile where this logic is implemented is here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/ZipFile.java#L1254. That code in the ZipFile has gone through the necessary vetting for dealing with various possibilities with the zip files. I think we should implement that same logic here while checking for zip64 entries. >> - The next one to decide is what kind of validations do we want to do in this code fo... > > I have not had an opportunity for a deep dive of the changes in the PR, only a quick skim., but I agree we should add some additional validation similar to what was added to ZipFile Thanks for the reviews! I have some initial notes on the questions raised: I reviewed how `ZipFile` validates the extra fields in [`checkExtraFields`](https://github.com/openjdk/jdk/blob/c25c4896ad9ef031e3cddec493aef66ff87c48a7/src/java.base/share/classes/java/util/zip/ZipFile.java#L1254-L1255) if `jdk.util.zip.disableZip64ExtraFieldValidation` is enabled, and how the values are read and used by `ZipEntry` in [`setExtra0`](https://github.com/openjdk/jdk/blob/c25c4896ad9ef031e3cddec493aef66ff87c48a7/src/java.base/share/classes/java/util/zip/ZipEntry.java#L558-L585). `zip_util.c` also handles zip64 extra fields [here](https://github.com/openjdk/jdk/blob/c25c4896ad9ef031e3cddec493aef66ff87c48a7/src/java.base/share/native/libzip/zip_util.c#L1048-L1061). It looks for a zip64 extra field if extra fields are present, and if any of the size/offset/length are set to the magic values. It does not appear to do any of the additional validation performed by `ZipFile`. I think there are some questions to consider about the approach: * Should all of the zip implementations being doing that validation, including `zip_util.c`? One of the last rounds of substantial changes to `parse_manifest`'s zip implementation in [JDK-8073158](https://bugs.openjdk.org/browse/JDK-8073158) the [review thread](https://mail.openjdk.org/pipermail/core-libs-dev/2015-March/032546.html) mentioned that it would be nice to have a single c zip implementation. At that point there were three including pack200, and now we're down to two, but consolidating `zip_util.c` and `parse_manifest.c` still seems like a big job. * Should the validation be configurable, via `jdk.util.zip.disableZip64ExtraFieldValidation` or a separate option? There are uses of `jdk.util.zip.disableZip64ExtraFieldValidation` in the wild ([github search](https://github.com/search?type=code&q=jdk.util.zip.disableZip64ExtraFieldValidation)), adding that validation could cause the launcher to start rejecting jars that are currently accepted. * Regarding what to do if the validation fails, `parse_manifest` currently takes the approach that if it sees something that looks like a zip64 end header but that fails checks, it could e.g. be seeing non-zip64 data from the last entry (see [here](https://github.com/openjdk/jdk/blob/c25c4896ad9ef031e3cddec493aef66ff87c48a7/src/java.base/share/native/libjli/parse_manifest.c#L172-L173)). Failing instead of ignoring ill-formed zip64 data is a departure from that approach. I wonder if the use-cases for `parse_manifest` and `ZipFile` are slightly different here, and it's more important for `ZipFile` to be hardened? If an untrusted jar is being launched by the launcher, hardening the launcher's zip implementation may not provide meaningful guarantees. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1684972451 From duke at openjdk.org Fri Jul 19 21:13:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 21:13:31 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: References: Message-ID: <-y2J32uO1V9buAZCjZLY7Gz1BFSfB21T1wkHJrrvRSc=.aa215a03-6003-41a6-995f-7764b9d9683c@github.com> On Fri, 19 Jul 2024 20:43:42 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> share newArray > > As annoying and risky as this first appeared, this patch is actually in quite good shape: The usage of `getBytes` is similar to those in StringUTF16, and there's no reason to further complicate this by splitting the handling into StringLatin1 and StringUTF16. ? > > Another question for you: can you check out the original form over here too? https://github.com/openjdk/jdk/commit/781fb29580b08fa659019a2da09488ee4711c017#diff-f8131d8a48caf7cfc908417fad241393c2ef55408172e9a28dcaa14b1d73e1fbL1968-L1981 > > `simpleConcat` is required to create new String objects and `String.concat` can just return the argument/original when one part is not empty. Is there any value to extract a common `doConcat` handling both non-empty strings, called by both methods after handling the empty cases? @liach is this what you want to change it to? class String { public String concat(String str) { if (str.isEmpty()) { return this; } return StringConcatHelper.doConcat(this, str); } } class StringConcatHelper { @ForceInline static String simpleConcat(Object first, Object second) { String s1 = stringOf(first); String s2 = stringOf(second); if (s1.isEmpty()) { // newly created string required, see JLS 15.18.1 return new String(s2); } if (s2.isEmpty()) { // newly created string required, see JLS 15.18.1 return new String(s1); } return doConcat(s1, s2); } @ForceInline static String doConcat(String s1, String s2) { byte coder = (byte) (s1.coder() | s2.coder()); int newLength = (s1.length() + s2.length()) << coder; byte[] buf = newArray(newLength); s1.getBytes(buf, 0, coder); s2.getBytes(buf, s1.length(), coder); return new String(buf, coder); } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240106042 From duke at openjdk.org Fri Jul 19 21:13:36 2024 From: duke at openjdk.org (duke) Date: Fri, 19 Jul 2024 21:13:36 GMT Subject: Withdrawn: 8331342: Convert Base64 tests to JUnit In-Reply-To: <9b7rZt1fLHoDtfpK78fcKL2EVEh_HocxFC4j5_tSXx4=.00a33121-882b-4198-9415-271eac5f9c51@github.com> References: <9b7rZt1fLHoDtfpK78fcKL2EVEh_HocxFC4j5_tSXx4=.00a33121-882b-4198-9415-271eac5f9c51@github.com> Message-ID: On Tue, 21 May 2024 22:56:45 GMT, Justin Lu wrote: > Please review this test-only clean up PR which converts the java.util.Base64 tests to run under JUnit. > > In general, this allows for the tests to run independently, separates the data providers from the tests, as well being able to utilize the built in JUnit utility test methods to reduce boilerplate testing code. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19337 From naoto at openjdk.org Fri Jul 19 21:21:44 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 19 Jul 2024 21:21:44 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21] In-Reply-To: References: Message-ID: <0515kIRPIKqztCAVemcPP3IktMRIKy2iax-a-MLAq-4=.f0424cba-5e86-485c-8939-f97879f19f33@github.com> On Fri, 19 Jul 2024 20:46:37 GMT, Naoto Sato wrote: >> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: >> >> 8333396: Use StringBuilder internally for java.text.Format.* formatting > > src/java.base/share/classes/java/text/CompactNumberFormat.java line 583: > >> 581: && ((BigInteger) number).bitLength() < 64)) { >> 582: return format(((Number) number).longValue(), toAppendTo, >> 583: fieldPosition); > > This is a prime example for switch pattern match, but probably for another day. Filed: https://bugs.openjdk.org/browse/JDK-8336847 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1684986049 From liach at openjdk.org Fri Jul 19 21:25:40 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 21:25:40 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v2] In-Reply-To: References: Message-ID: <0EnTu6ygonh-O8enMzhh3rPYSxRC2ORdSq3kHB2Y_N4=.20b3b713-6c33-4011-bbce-8457c03de6e5@github.com> On Fri, 19 Jul 2024 19:18:43 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > share newArray Yep. I think this looks cleaner and avoids redundant checks on the `String.concat` path. What do you think? Is this slower according to your benchmarks? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240166555 From liach at openjdk.org Fri Jul 19 21:28:50 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 21:28:50 GMT Subject: RFR: 8336777: BufferedMethodBuilder not initialized with static flag In-Reply-To: References: Message-ID: <4eEF93DuMnFBD7MxtOGroOFJdoDMLHOdWODDr999P04=.2c6ee9ee-b201-40ac-a516-3dd27fd1f936@github.com> On Thu, 18 Jul 2024 22:21:08 GMT, Chen Liang wrote: > `BufferedMethodBuilder` accepts a static flag and passes it to the `CodeBuilder` it creates; yet it does not prevent static flag tampering like `DirectMethodBuilder` does. This patch makes their behaviors consistent. > > Note that the throwing of IAE is provisional; it is open to discussion later. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20244#issuecomment-2240168417 From liach at openjdk.org Fri Jul 19 21:28:50 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 21:28:50 GMT Subject: Integrated: 8336777: BufferedMethodBuilder not initialized with static flag In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 22:21:08 GMT, Chen Liang wrote: > `BufferedMethodBuilder` accepts a static flag and passes it to the `CodeBuilder` it creates; yet it does not prevent static flag tampering like `DirectMethodBuilder` does. This patch makes their behaviors consistent. > > Note that the throwing of IAE is provisional; it is open to discussion later. This pull request has now been integrated. Changeset: 3ade2b61 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/3ade2b6114bbe81eb03e3a49c08b5401f70a2367 Stats: 102 lines in 6 files changed: 91 ins; 0 del; 11 mod 8336777: BufferedMethodBuilder not initialized with static flag Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20244 From duke at openjdk.org Fri Jul 19 21:33:09 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 21:33:09 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v3] In-Reply-To: References: Message-ID: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: extract a common doConcat handling both non-empty strings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20253/files - new: https://git.openjdk.org/jdk/pull/20253/files/38a6f560..a509b7cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=01-02 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20253/head:pull/20253 PR: https://git.openjdk.org/jdk/pull/20253 From liach at openjdk.org Fri Jul 19 21:38:07 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 21:38:07 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v4] In-Reply-To: <958Stt5UAe_cOdPd3ofBV5oUFZHpwha7GOw2wrCT01w=.1b17b794-7f90-413a-b3b1-791855843b68@github.com> References: <958Stt5UAe_cOdPd3ofBV5oUFZHpwha7GOw2wrCT01w=.1b17b794-7f90-413a-b3b1-791855843b68@github.com> Message-ID: On Fri, 19 Jul 2024 21:34:36 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > handle null argument src/java.base/share/classes/java/lang/String.java line 2990: > 2988: return this; > 2989: } > 2990: return StringConcatHelper.doConcat(this, str == null ? "null" : str); Suggestion: if (isEmpty()) { return str; } return StringConcatHelper.doConcat(this, str); `str.isEmpty()` already does the null check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1685008791 From duke at openjdk.org Fri Jul 19 21:38:07 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 21:38:07 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v4] In-Reply-To: References: Message-ID: <958Stt5UAe_cOdPd3ofBV5oUFZHpwha7GOw2wrCT01w=.1b17b794-7f90-413a-b3b1-791855843b68@github.com> > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: handle null argument ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20253/files - new: https://git.openjdk.org/jdk/pull/20253/files/a509b7cd..9b39c4c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20253/head:pull/20253 PR: https://git.openjdk.org/jdk/pull/20253 From liach at openjdk.org Fri Jul 19 21:42:09 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Jul 2024 21:42:09 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:33:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > extract a common doConcat handling both non-empty strings This patch looks ideal to me; but other reviewers may have different opinions on this review. I am ready to answer their questions for you. I will approve your patch once you fixed the null and empty check in `String.concat` and the builds look good. Don't change your patch too often, as that means previous build results will be invalid. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240220709 From duke at openjdk.org Fri Jul 19 21:42:09 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 21:42:09 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/java/lang/String.java Co-authored-by: Chen Liang - add comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20253/files - new: https://git.openjdk.org/jdk/pull/20253/files/9b39c4c7..69901157 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=03-04 Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20253/head:pull/20253 PR: https://git.openjdk.org/jdk/pull/20253 From duke at openjdk.org Fri Jul 19 21:48:49 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 21:48:49 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: <-fFEhlvC8IgKuNmJ4iYtiSm_S4-bXg8TsSL3Zw0Ybng=.cc4b3701-0e5d-4747-aa57-0cb4f388905b@github.com> On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments Below are the performance numbers of the latest version running on a MacBook M1 Pro, which is 9.19% faster -Benchmark (intValue) Mode Cnt Score Error Units (base c25c4896ad9ef031e3cddec493aef66ff87c48a7) -StringConcat.concatMethodConstString 4711 avgt 15 5.440 ? 0.075 ns/op +Benchmark (intValue) Mode Cnt Score Error Units (current 69901157e4dae9018abd727956f60fd11b8fa252) +StringConcat.concatMethodConstString 4711 avgt 15 4.982 ? 0.019 ns/op +9.19% ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240251072 From rriggs at openjdk.org Fri Jul 19 21:48:49 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Jul 2024 21:48:49 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments I'll take a look at this next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240253021 From duke at openjdk.org Fri Jul 19 21:52:33 2024 From: duke at openjdk.org (duke) Date: Fri, 19 Jul 2024 21:52:33 GMT Subject: RFR: 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen wrote: > The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder @wenshao Your change (at version db3027b03030304dbec990c943eff0f037363e37) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20245#issuecomment-2240263706 From rriggs at openjdk.org Fri Jul 19 22:00:41 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Jul 2024 22:00:41 GMT Subject: RFR: 8336706: Optimize LocalDate.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 05:21:36 GMT, Shaojin Wen wrote: > class LocalDate { > public String toString() { > if (absYear < 1000) { > if (yearValue < 0) { > buf.append(yearValue - 10000).deleteCharAt(1); > } else { > buf.append(yearValue + 10000).deleteCharAt(0); > } > // ... > } > } > > Currently, LocalDate.toString causes an extra memory copy when processing years < 1000. This can be replaced by using StringBuilder.repeat, which is more concise and has better performance. lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20229#pullrequestreview-2189421346 From duke at openjdk.org Fri Jul 19 22:09:48 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 22:09:48 GMT Subject: Integrated: 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 23:36:37 GMT, Shaojin Wen wrote: > The StringBuilder.repeat method was added in JDK 21, which can be used to make some minor optimizations to existing code, including DateTimeFormatterBuilder This pull request has now been integrated. Changeset: e3acf4c6 Author: Shaojin Wen Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/e3acf4c627c3c75f9a2ef29647daa6f4746fdc62 Stats: 12 lines in 1 file changed: 2 ins; 4 del; 6 mod 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat Reviewed-by: liach, rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/20245 From redestad at openjdk.org Fri Jul 19 22:31:40 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 19 Jul 2024 22:31:40 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments FWIW one of the ideas when implementing `StringConcatHelper.simpleConcat` was that by using the primitives used by the `StringConcatFactory` as straightforwardly as possible the method acts as a documentation-of-sorts or guide to understand how the `SCF` expression trees are built up. It's not perfect, though. Concatenation of a `String` + constant would be handled differently for one. So perhaps the value as a guide is not high. I'm also experimenting with replacing the MH-based strategy with spinning hidden, shareable classes instead. In that case we might actually be better off getting rid of the `long indexCoder` hacks and generate code more similar to the `doConcat` you've come up with here. The main benefit of combining `coder` and `index/length` into a single `long` was to reduce the MH combinator overheads, but if we're spinning code with access to optimized primitives then that isn't really needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240412866 From duke at openjdk.org Fri Jul 19 22:32:40 2024 From: duke at openjdk.org (ExE Boss) Date: Fri, 19 Jul 2024 22:32:40 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors [v3] In-Reply-To: References: Message-ID: <3PS0qc9e3pT_8Hl4tSe5177klP4aUMs_LFVAO7Yl3iQ=.a28f9f4d-bdd9-44ac-b2e4-622bc58a5d16@github.com> On Fri, 19 Jul 2024 08:26:46 GMT, Adam Sotona wrote: >> `ClassFile.verify()` should always return list of verification errors and never throw an exception, even for corrupted classes. >> `BoundAttribute` initializations of `LocalVariableTable` and `LocalVariableTypeTable` attributes do not expect invalid possible locations and cause `ClassCastException`. >> >> This patch fixes `BoundAttribute` to throw `IllegalArgumentException` for invalid `LocalVariableTable` and `LocalVariableTypeTable` attributes locations. And makes `VerifierImpl` a bit more resilient to exceptions thrown from the verifier initialization. >> >> Relevant test is added. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > nit change src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 138: > 136: return VerifierImpl.verify(model, classHierarchyResolverOption().classHierarchyResolver(), null); > 137: } catch (IllegalArgumentException verifierInitializationError) { > 138: return List.of(new VerifyError(verifierInitializationError.getMessage())); Note?that the?list returned by?`VerifierImpl.verify(?)` is?mutable, whereas?`List.of(?)` is?unmodifiable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20241#discussion_r1685063956 From duke at openjdk.org Fri Jul 19 22:52:32 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 22:52:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: <_aI0Bcdy2HcYt3M879eNvAXkNI5F69QmgypOYGkxS6U=.f722fa82-ef4e-4aa1-bd83-980bc44de47b@github.com> On Fri, 19 Jul 2024 22:28:40 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/lang/String.java >> >> Co-authored-by: Chen Liang >> - add comments > > FWIW one of the ideas when implementing `StringConcatHelper.simpleConcat` was that by using the primitives used by the `StringConcatFactory` as straightforwardly as possible the method acts as a documentation-of-sorts or guide to understand how the `SCF` expression trees are built up. It's not perfect, though. Concatenation of a `String` + constant would be handled differently for one. So perhaps the value as a guide is not high. > > I'm also experimenting with replacing the MH-based strategy with spinning hidden, shareable classes instead. In that case we might actually be better off getting rid of the `long indexCoder` hacks and generate code more similar to the `doConcat` you've come up with here. The main benefit of combining `coder` and `index/length` into a single `long` was to reduce the MH combinator overheads, but if we're spinning code with access to optimized primitives then that isn't really needed. @cl4es Is it your idea to provide some String + primitive doConcat method and use it in StringConcatFactory to generate MH? doConcat(String,boolean) doConcat(String,char) doConcat(String,int) doConcat(String,long) doConcat(boolean, String) doConcat(char, String) doConcat(int, String) doConcat(long, String) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240494811 From duke at openjdk.org Fri Jul 19 23:09:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 19 Jul 2024 23:09:31 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v4] In-Reply-To: References: Message-ID: On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen wrote: >> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. >> >> >> Improved performance includes the following: >> >> ## 1. Write directly during the parse process to reduce object allocation. >> >> In the current Formatter implementation, some objects do not need to be allocated, such as: >> >> >> class Formatter { >> public Formatter format(Locale l, String format, Object ... args) { >> List fsa = parse(format); >> // ... >> } >> >> static List parse(String s) { >> ArrayList al = new ArrayList<>(); >> >> while (i < max) { >> int n = s.indexOf('%', i); >> if (n < 0) { >> // >> al.add(new FixedString(s, i, max)); >> } >> } >> } >> } >> >> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. >> >> ## 2. Fast path print >> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. >> >> ## 3. String.format directly calls j.u.Formatter >> String.format directly calls j.u.Formatter via SharedSecrets to improve performance > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Implementing JavaUtilFormatterAccess using anonymous class This PR has a lot of changes, which is a lot of work for review, but it can significantly improve the performance of most String.format scenarios. String.format is widely used, so it is meaningful. Can someone help me review and finish it? Thanks @cl4es @liach ------------- PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2240562362 From acobbs at openjdk.org Fri Jul 19 23:18:31 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 19 Jul 2024 23:18:31 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 09:56:46 GMT, Eirik Bj?rsn?s wrote: > The term "extra" here feels somewhat open to interpretation. Specifically, "extra" sounds like something that is out of the ordinary, but not uncommon or wrong. It could be used when describing an optional feature in a format specification. > > The API description referes to "unexpected data". Perhaps the word "unexpected" is a more precise and descriptive term to use in this option? So ignoreUnexpectedBytes or ignoreUnexpectedData. This is a good point.. because it's actually a bit subtle what kind of data is being referred to here as being "ignored". Even "unexpected" doesn't quite capture it. To be precise, here's what bytes the `ignoreExtraBytes` parameter is going to cause to be ignored: * In the case `allowConcatenation == false`, it really does refer to "extra" or "extraneous" data, that is: one or more bytes having any value appearing _after_ the end of the GZIP trailer frame. * In the case `allowConcatenation == true`, it means a truncated or invalid GZIP _header frame_ appearing after the end of any GZIP trailer frame. The second case means "unexpected" seems wrong because why would unexpected data in a header frame be treated any differently from unexpected data any other frame (which of course is not going to be ignored but instead will trigger an exception)? So maybe this is just more evidence that we shouldn't use boolean parameters - because they're not really orthogonal. What about something like: public enum ConcatPolicy { DISALLOW_STRICT, // one GZIP stream, nothing else DISALLOW_LENIENT, // one GZIP stream, ignore any extra byte(s) ALLOW_STRICT, // N GZIP streams, nothing else ALLOW_LENIENT; // N GZIP streams, stop at, and ignore, an invalid header frame } The legacy behavior would of course correspond to `ALLOW_LENIENT`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1685106562 From duke at openjdk.org Fri Jul 19 23:26:31 2024 From: duke at openjdk.org (duke) Date: Fri, 19 Jul 2024 23:26:31 GMT Subject: RFR: 8336706: Optimize LocalDate.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 05:21:36 GMT, Shaojin Wen wrote: > class LocalDate { > public String toString() { > if (absYear < 1000) { > if (yearValue < 0) { > buf.append(yearValue - 10000).deleteCharAt(1); > } else { > buf.append(yearValue + 10000).deleteCharAt(0); > } > // ... > } > } > > Currently, LocalDate.toString causes an extra memory copy when processing years < 1000. This can be replaced by using StringBuilder.repeat, which is more concise and has better performance. @wenshao Your change (at version af224217897a610d520c07f2805d91d6e41a9cba) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20229#issuecomment-2240626945 From redestad at openjdk.org Fri Jul 19 23:52:32 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 19 Jul 2024 23:52:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments No, my idea is to rework and have SCF spin hidden classes using the new classfile API which will emit code or less in the style you are doing here for `simpleConcat`, but generalized. This may or may not work out beautifully. I'm coming back from a short vacation now and will work on having something to present on this topic at JVMLS two and a half weeks from now. FTR I don't mind if you get this optimization in here. I'll just rebase my prototype, and it shouldn't alter things too much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240728186 From jpai at openjdk.org Sat Jul 20 01:36:32 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 20 Jul 2024 01:36:32 GMT Subject: RFR: 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> Message-ID: On Fri, 19 Jul 2024 19:35:14 GMT, Liam Miller-Cushon wrote: > This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). > > I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. > > I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. Hello Liam, the changes look fine to me. Choosing `EXTID_ZIP64` constant in preference of the other seems OK too, since that constant is more closer in code location with the other extra field header ids. Some of these files require a copyright year update. Please update those before integrating. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2189609923 From cushon at openjdk.org Sat Jul 20 02:18:11 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sat, 20 Jul 2024 02:18:11 GMT Subject: RFR: 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID [v2] In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> Message-ID: > This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). > > I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. > > I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. Liam Miller-Cushon 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: - Merge remote-tracking branch 'origin/master' into zip64_extid - Update copyright year - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20264/files - new: https://git.openjdk.org/jdk/pull/20264/files/3b975c24..48bb222e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20264&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20264&range=00-01 Stats: 889 lines in 46 files changed: 673 ins; 101 del; 115 mod Patch: https://git.openjdk.org/jdk/pull/20264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20264/head:pull/20264 PR: https://git.openjdk.org/jdk/pull/20264 From cushon at openjdk.org Sat Jul 20 02:18:12 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sat, 20 Jul 2024 02:18:12 GMT Subject: RFR: 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> Message-ID: On Fri, 19 Jul 2024 19:35:14 GMT, Liam Miller-Cushon wrote: > This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). > > I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. > > I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. I updated the copyright dates. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20264#issuecomment-2240861834 From liach at openjdk.org Sat Jul 20 04:46:31 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Jul 2024 04:46:31 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: <_aI0Bcdy2HcYt3M879eNvAXkNI5F69QmgypOYGkxS6U=.f722fa82-ef4e-4aa1-bd83-980bc44de47b@github.com> References: <_aI0Bcdy2HcYt3M879eNvAXkNI5F69QmgypOYGkxS6U=.f722fa82-ef4e-4aa1-bd83-980bc44de47b@github.com> Message-ID: <9EWTtJ58SYiHYg8wE1NnR-KzICOVzeWBo6ogKLEzaIs=.0e57eeef-aae8-406f-ae48-269d739fc36e@github.com> On Fri, 19 Jul 2024 22:49:41 GMT, Shaojin Wen wrote: >> FWIW one of the ideas when implementing `StringConcatHelper.simpleConcat` was that by using the primitives used by the `StringConcatFactory` as straightforwardly as possible the method acts as a documentation-of-sorts or guide to understand how the `SCF` expression trees are built up. It's not perfect, though. Concatenation of a `String` + constant would be handled differently for one. So perhaps the value as a guide is not high. >> >> I'm also experimenting with replacing the MH-based strategy with spinning hidden, shareable classes instead. In that case we might actually be better off getting rid of the `long indexCoder` hacks and generate code more similar to the `doConcat` you've come up with here. The main benefit of combining `coder` and `index/length` into a single `long` was to reduce the MH combinator overheads, but if we're spinning code with access to optimized primitives then that isn't really needed. > > @cl4es Is it your idea to provide some String + primitive doConcat method and use it in StringConcatFactory to generate MH? > > > doConcat(String,boolean) > doConcat(String,char) > doConcat(String,int) > doConcat(String,long) > doConcat(boolean, String) > doConcat(char, String) > doConcat(int, String) > doConcat(long, String) @wenshao We note that we only need to update coder if we are concating a String; primitives are always Latin1. So coder can be one of the 3 cases: 1. Latin1, when all constant Strings are Latin1 and all arguments are primitive (even though floating point needs conversion to strings) 2. UTF16, when any constant String is UTF16 3. On-demand detection, when all constant strings are Latin1 but some arguments are Strings. Using these clues, we might be able to generate more efficient bytecode, which is also free from MethodHandle tree's trouble of inlining when the size is too huge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240914855 From liach at openjdk.org Sat Jul 20 04:49:38 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Jul 2024 04:49:38 GMT Subject: RFR: 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors [v3] In-Reply-To: <3PS0qc9e3pT_8Hl4tSe5177klP4aUMs_LFVAO7Yl3iQ=.a28f9f4d-bdd9-44ac-b2e4-622bc58a5d16@github.com> References: <3PS0qc9e3pT_8Hl4tSe5177klP4aUMs_LFVAO7Yl3iQ=.a28f9f4d-bdd9-44ac-b2e4-622bc58a5d16@github.com> Message-ID: On Fri, 19 Jul 2024 22:30:00 GMT, ExE Boss wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> nit change > > src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 138: > >> 136: return VerifierImpl.verify(model, classHierarchyResolverOption().classHierarchyResolver(), null); >> 137: } catch (IllegalArgumentException verifierInitializationError) { >> 138: return List.of(new VerifyError(verifierInitializationError.getMessage())); > > Note?that the?list returned by?`VerifierImpl.verify(?)` is?mutable, whereas?`List.of(?)` is?unmodifiable. Good observation; we should check that all collection-returning APIs in ClassFile API are immutable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20241#discussion_r1685246312 From jpai at openjdk.org Sat Jul 20 06:30:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 20 Jul 2024 06:30:31 GMT Subject: RFR: 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID [v2] In-Reply-To: References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> Message-ID: On Sat, 20 Jul 2024 02:18:11 GMT, Liam Miller-Cushon wrote: >> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). >> >> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. >> >> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. > > Liam Miller-Cushon 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: > > - Merge remote-tracking branch 'origin/master' into zip64_extid > - Update copyright year > - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64. The changes look good to me. Although a trivial change, it would be good to wait for Lance to review this before integrating. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2189766637 From duke at openjdk.org Sat Jul 20 06:30:32 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 20 Jul 2024 06:30:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: <7iutnLeeYG_QG3RhPNqiYg24Kn8U4iUn0F836kYIpeI=.59de5071-4648-4307-ace2-ef15cf703816@github.com> On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments Now StringCconcatFactory constructs MethodHandle through StringConcatHelper.lookupStatic, so it can access the private methods of StringConcatHelper. If code is generated through ClassFile, how to access the private methods of classes such as String/StringConcatHelper? I made a try and found it was wrong: Exception in thread "main" java.lang.IllegalAccessError: failed to access class java.lang.StringConcatHelper from class jdk.tools.jlink.internal.Utils$$StringConcat/0x00000070000d2000 (java.lang.StringConcatHelper is in module java.base of loader 'bootstrap'; jdk.tools.jlink.internal.Utils$$StringConcat/0x00000070000d2000 is in module jdk.jlink of loader 'app') at jdk.jlink/jdk.tools.jlink.internal.Utils.getPathMatcher(Utils.java:96) at jdk.jlink/jdk.tools.jmod.JmodTask$PathMatcherConverter.convert(JmodTask.java:1256) at jdk.jlink/jdk.tools.jmod.JmodTask$PathMatcherConverter.convert(JmodTask.java:1252) at jdk.internal.opt/jdk.internal.joptsimple.internal.Reflection.convertWith(Reflection.java:154) at jdk.internal.opt/jdk.internal.joptsimple.AbstractOptionSpec.convertWith(AbstractOptionSpec.java:120) at jdk.internal.opt/jdk.internal.joptsimple.ArgumentAcceptingOptionSpec.convert(ArgumentAcceptingOptionSpec.java:308) at jdk.internal.opt/jdk.internal.joptsimple.OptionSet.valuesOf(OptionSet.java:253) at jdk.jlink/jdk.tools.jmod.JmodTask.handleOptions(JmodTask.java:1490) at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:181) at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:35) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240950163 From vtewari at openjdk.org Sat Jul 20 06:41:32 2024 From: vtewari at openjdk.org (Vyom Tewari) Date: Sat, 20 Jul 2024 06:41:32 GMT Subject: RFR: 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID [v2] In-Reply-To: References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> Message-ID: On Sat, 20 Jul 2024 02:18:11 GMT, Liam Miller-Cushon wrote: >> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). >> >> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. >> >> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. > > Liam Miller-Cushon 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: > > - Merge remote-tracking branch 'origin/master' into zip64_extid > - Update copyright year > - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64. Looks OK to me. ------------- Marked as reviewed by vtewari (Committer). PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2189770126 From liach at openjdk.org Sat Jul 20 06:44:34 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Jul 2024 06:44:34 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: <7iutnLeeYG_QG3RhPNqiYg24Kn8U4iUn0F836kYIpeI=.59de5071-4648-4307-ace2-ef15cf703816@github.com> References: <7iutnLeeYG_QG3RhPNqiYg24Kn8U4iUn0F836kYIpeI=.59de5071-4648-4307-ace2-ef15cf703816@github.com> Message-ID: On Sat, 20 Jul 2024 06:28:12 GMT, Shaojin Wen wrote: > If code is generated through ClassFile, how to access the private methods of classes such as String/StringConcatHelper? In that case, you have to encode those methods as live `MethodHandle` objects, passed to the generated class with `defineHiddenClassWithClassData` (just pass the class data object) They can be retrieved in generated code with a CONDY using `MethodHandles.classData`. (This is how the MethodHandle LambdaForm classes referred to other MethodHandles) ---- You don't really need to worry about experimenting with bytecode generation right now. This patch as is is very good, and tier 1-3 tests pass. Bytecode gen is aimed at more complex scenarios with multiple constants and various types of arguments instead of this simple concat case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240961431 From duke at openjdk.org Sat Jul 20 06:56:35 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 20 Jul 2024 06:56:35 GMT Subject: Integrated: 8336706: Optimize LocalDate.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 05:21:36 GMT, Shaojin Wen wrote: > class LocalDate { > public String toString() { > if (absYear < 1000) { > if (yearValue < 0) { > buf.append(yearValue - 10000).deleteCharAt(1); > } else { > buf.append(yearValue + 10000).deleteCharAt(0); > } > // ... > } > } > > Currently, LocalDate.toString causes an extra memory copy when processing years < 1000. This can be replaced by using StringBuilder.repeat, which is more concise and has better performance. This pull request has now been integrated. Changeset: 491b9f5e Author: Shaojin Wen Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/491b9f5efc01fa36fb3c174e130b46bc69c8d707 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod 8336706: Optimize LocalDate.toString with StringBuilder.repeat Reviewed-by: liach, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/20229 From duke at openjdk.org Sat Jul 20 13:14:32 2024 From: duke at openjdk.org (Brett Okken) Date: Sat, 20 Jul 2024 13:14:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments src/java.base/share/classes/java/lang/StringConcatHelper.java line 387: > 385: byte[] buf = newArray(newLength); > 386: s1.getBytes(buf, 0, coder); > 387: s2.getBytes(buf, s1.length(), coder); Does s1 length need to be shifted by coder for dstBegin? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1685431381 From duke at openjdk.org Sat Jul 20 13:18:36 2024 From: duke at openjdk.org (Brett Okken) Date: Sat, 20 Jul 2024 13:18:36 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 13:11:33 GMT, Brett Okken wrote: >> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/lang/String.java >> >> Co-authored-by: Chen Liang >> - add comments > > src/java.base/share/classes/java/lang/StringConcatHelper.java line 387: > >> 385: byte[] buf = newArray(newLength); >> 386: s1.getBytes(buf, 0, coder); >> 387: s2.getBytes(buf, s1.length(), coder); > > Does s1 length need to be shifted by coder for dstBegin? Nope - I see the index is char based https://github.com/openjdk/jdk/blob/69901157e4dae9018abd727956f60fd11b8fa252/src/java.base/share/classes/java/lang/String.java#L4821C15-L4821C23 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1685432480 From liach at openjdk.org Sat Jul 20 13:21:32 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Jul 2024 13:21:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 13:16:16 GMT, Brett Okken wrote: >> src/java.base/share/classes/java/lang/StringConcatHelper.java line 387: >> >>> 385: byte[] buf = newArray(newLength); >>> 386: s1.getBytes(buf, 0, coder); >>> 387: s2.getBytes(buf, s1.length(), coder); >> >> Does s1 length need to be shifted by coder for dstBegin? > > Nope - I see the index is char based > > https://github.com/openjdk/jdk/blob/69901157e4dae9018abd727956f60fd11b8fa252/src/java.base/share/classes/java/lang/String.java#L4821C15-L4821C23 No; in StringUTF16 we abstract away array indices with char index, like in putChar. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1685433034 From alanb at openjdk.org Sat Jul 20 15:12:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 20 Jul 2024 15:12:32 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v4] In-Reply-To: <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> <8S0p9Esmhvv8SRYrWogY9jP-J5o9YcYVEo8-3pMS4Ag=.8bca55f2-eb29-40dc-90cc-8dbfdd359166@github.com> Message-ID: On Fri, 19 Jul 2024 14:20:48 GMT, Nizar Benalla wrote: >> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). >> >> It's mostly fixing some relative links. >> If using `{@docroot}` isn't ideal I can change it. >> >> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes >> >> >> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html >> 106c106 >> <

>> --- >>>

>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html >> 99c99 >> <

>> --- >>> >> 106c106 >> <

>> --- >>> >> 618c618 >> <

>> --- >>> >> 755c755 >> <

>> --- >>> >> 783c783 >> <

>> --- >>> >> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html >> 142c142 >> < the segments allocated by it) becomes unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java > > forgot this one > > Co-authored-by: Chen Liang src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1200: > 1198: *

Construction captures the current thread's {@linkplain ScopedValue scoped > 1199: * value} bindings for inheritance by threads started in the task scope. The > 1200: * {@linkplain StructuredTaskScope##TreeStructure Tree Structure} section in the class description You can drop the changes to STS if you want as we have an update coming that replaces these paragraphs/links. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20251#discussion_r1685465093 From liach at openjdk.org Sat Jul 20 21:23:32 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Jul 2024 21:23:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments Forgot to leave an approval after the tests pass. Sorry! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2190061839 From liach at openjdk.org Sat Jul 20 23:12:59 2024 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Jul 2024 23:12:59 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v3] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge BoundAttributeTest - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage The rest of Writable in annotations can be removed in later cleanup - Fix up usages of Util.write - Hide writeTo from all class file elements To consider the fate of WritableElement later! ------------- Changes: https://git.openjdk.org/jdk/pull/20205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=02 Stats: 458 lines in 49 files changed: 99 ins; 198 del; 161 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From 1dropaflame at gmail.com Sun Jul 21 02:44:07 2024 From: 1dropaflame at gmail.com (Anil) Date: Sat, 20 Jul 2024 21:44:07 -0500 Subject: want to try out small idea; where is the implementing class for Stream interface? Message-ID: Hi, I had a small idea on debugging of streams and was trying to implement it to see if it works. I am able to build the OpenJDK (on Windows 11, Cygwin64). However, I am unable to find the implementing class of java.util.Stream. Can you please help? thanks, Anil Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sun Jul 21 03:38:52 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Sat, 20 Jul 2024 22:38:52 -0500 Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: Hi Anil, are you using intellij and setting up the project with idea.sh? Idea has a bug where its indexing breaks completely; you need to type something in the code, like a typo in method name, to force it to refresh. On Sat, Jul 20, 2024, 9:45?PM Anil <1dropaflame at gmail.com> wrote: > Hi, > I had a small idea on debugging of streams and was trying to implement it > to see if it works. > I am able to build the OpenJDK (on Windows 11, Cygwin64). > However, I am unable to find the implementing class of java.util.Stream. > Can you please help? > thanks, > Anil Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sun Jul 21 06:52:09 2024 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 21 Jul 2024 08:52:09 +0200 (CEST) Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: <20240721065209.2936F66279F@dd33810.kasserver.com> Anil wrote on 21. July 2024 04:44 (GMT +02:00): > However, I am unable to find the implementing class of java.util.Stream. You find the package in Java.base module: https://github.com/openjdk/jdk/tree/master/src/java.base/share/classes/java/util/stream Gru? Bernd ? https://bernd.eckenfels.net From duke at openjdk.org Sun Jul 21 07:53:45 2024 From: duke at openjdk.org (duke) Date: Sun, 21 Jul 2024 07:53:45 GMT Subject: Withdrawn: 8327858: Improve spliterator and forEach for single-element immutable collections In-Reply-To: References: Message-ID: On Wed, 20 Sep 2023 04:52:31 GMT, Chen Liang wrote: > Please review this patch that: > 1. Implemented `forEach` to optimize for 1 or 2 element collections. > 2. Implemented `spliterator` to optimize for a single element. > > The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15834 From lancea at openjdk.org Sun Jul 21 12:28:36 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 21 Jul 2024 12:28:36 GMT Subject: RFR: 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID [v2] In-Reply-To: References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> Message-ID: On Sat, 20 Jul 2024 02:18:11 GMT, Liam Miller-Cushon wrote: >> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). >> >> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. >> >> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. > > Liam Miller-Cushon 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: > > - Merge remote-tracking branch 'origin/master' into zip64_extid > - Update copyright year > - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64. The change looks fine. ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2190317457 From duke at openjdk.org Sun Jul 21 12:36:01 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 21 Jul 2024 12:36:01 GMT Subject: RFR: 8336856: Optimize String Concat Message-ID: The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 ------------- Depends on: https://git.openjdk.org/jdk/pull/20253 Commit messages: - optimize string concat Changes: https://git.openjdk.org/jdk/pull/20273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336856 Stats: 393 lines in 5 files changed: 117 ins; 76 del; 200 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From duke at openjdk.org Sun Jul 21 12:46:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 21 Jul 2024 12:46:34 GMT Subject: RFR: 8336856: Optimize String Concat In-Reply-To: References: Message-ID: On Sun, 21 Jul 2024 12:25:36 GMT, Shaojin Wen wrote: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Here are the performance numbers running on a MacBook M1 Pro, In the scenario of concat two ints, such as `StringConcat.concatConstIntConstInt`, the performance is improved by 10.98% -Benchmark (intValue) Mode Cnt Score Error Units (master c25c4896ad9ef031e3cddec493aef66ff87c48a7) -StringConcat.concatConstInt 4711 avgt 15 6.283 ? 0.007 ns/op -StringConcat.concatConstIntConstInt 4711 avgt 15 15.164 ? 0.428 ns/op +Benchmark (intValue) Mode Cnt Score Error Units ( 227158a7879023cf495c8f1e3704d7e665fcb3bb ) +StringConcat.concatConstInt 4711 avgt 15 6.115 ? 0.062 ns/op +2.74% +StringConcat.concatConstIntConstInt 4711 avgt 15 13.663 ? 0.413 ns/op +10.98% ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2241598444 From redestad at openjdk.org Sun Jul 21 13:01:30 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 21 Jul 2024 13:01:30 GMT Subject: RFR: 8336856: Optimize String Concat In-Reply-To: References: Message-ID: On Sun, 21 Jul 2024 12:25:36 GMT, Shaojin Wen wrote: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 This reverts startup optimizations which are important for the overall performance of the current MH-based implementation. I did not suggest splitting apart length and coder in the context of this current implementation, but that in a non-MH-based implementation that combination trick makes little sense. I am trying to find time to work out the kinks of a bytecode-spinning solution and would appreciate it if we leave the venerable `StringConcatFactory` alone for the time being - at least until after JVMLS (Aug 5-7). (I noticed in some tests that splitting apart like this seem to only affect M1/aarch64, not x64, suggesting some JIT compiler deficiency on aarch64. Perhaps that would be a useful side track to explore.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2241602473 From duke at openjdk.org Sun Jul 21 13:34:05 2024 From: duke at openjdk.org (Technici4n) Date: Sun, 21 Jul 2024 13:34:05 GMT Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt Message-ID: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> Hi, Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example. There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2] [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html ------------- Commit messages: - 8316882: Do not close ZipFileSystem on interrupt Changes: https://git.openjdk.org/jdk/pull/20274/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20274&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316882 Stats: 69 lines in 4 files changed: 68 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20274.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20274/head:pull/20274 PR: https://git.openjdk.org/jdk/pull/20274 From alanb at openjdk.org Sun Jul 21 16:24:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 21 Jul 2024 16:24:30 GMT Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt In-Reply-To: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> Message-ID: On Sun, 21 Jul 2024 13:29:36 GMT, Technici4n wrote: > Hi, > > Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example. > > There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2] > > [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html > [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html Did you check with Lance before taking this? Asking because in the discussion threads cited we didn't come to a conclusion on this topic yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20274#issuecomment-2241702813 From duke at openjdk.org Sun Jul 21 16:34:31 2024 From: duke at openjdk.org (Technici4n) Date: Sun, 21 Jul 2024 16:34:31 GMT Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt In-Reply-To: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> Message-ID: On Sun, 21 Jul 2024 13:29:36 GMT, Technici4n wrote: > Hi, > > Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example. > > There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2] > > [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html > [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html Oh, I missed the assignment and did not check with @LanceAndersen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20274#issuecomment-2241705889 From 1dropaflame at gmail.com Sun Jul 21 19:23:23 2024 From: 1dropaflame at gmail.com (Anil) Date: Sun, 21 Jul 2024 14:23:23 -0500 Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: Chen, Thanks for your reply. Yes, I am using IntelliJ Community Edition (on Windows 11, Cygwin64). I did not set up the project - I just opened the package in IJ C:\Users\Anil\OpenJDK\jdk\src\java.base\share\classes\java\util\stream Is there something different I should be doing? thanks, Anil On Sat, Jul 20, 2024 at 10:39?PM Chen Liang wrote: > Hi Anil, are you using intellij and setting up the project with idea.sh? > Idea has a bug where its indexing breaks completely; you need to type > something in the code, like a typo in method name, to force it to refresh. > > On Sat, Jul 20, 2024, 9:45?PM Anil <1dropaflame at gmail.com> wrote: > >> Hi, >> I had a small idea on debugging of streams and was trying to implement it >> to see if it works. >> I am able to build the OpenJDK (on Windows 11, Cygwin64). >> However, I am unable to find the implementing class of java.util.Stream. >> Can you please help? >> thanks, >> Anil Philip >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbenalla at openjdk.org Sun Jul 21 21:15:03 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sun, 21 Jul 2024 21:15:03 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v5] In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com> > Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). > > It's mostly fixing some relative links. > If using `{@docroot}` isn't ideal I can change it. > > Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes > > > diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html > 106c106 > <

> --- >>

> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html > 99c99 > <

> --- >> > 106c106 > <

> --- >> > 618c618 > <

> --- >> > 755c755 > <

> --- >> > 783c783 > <

> --- >> > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html > 142c142 > < the segments allocated by it) becomes unreachable, > --- >> the segments allocated by it) becomes unreachable, > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html > 120c120 > < as long as it is reachable. > --- >> as long as it is reachable. > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html > 1420c1420 > < kept reachable > --- >> kept reachable > 1833c1833 > < unreachable. > --- >> unreachable. > 1899c1899 > < unreachable. > --- >> unreachable. > diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html > 395c395 > < unreachable. The > --- >> unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > undo changes to StructuredTaskScope Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2190420126 From liangchenblue at gmail.com Sun Jul 21 23:46:28 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Sun, 21 Jul 2024 18:46:28 -0500 Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: Please refer to the "Intellij Idea" section on the ide doc: https://github.com/openjdk/jdk/blob/master/doc/ide.md#intellij-idea In short, in `jdk`, you need to run the `bin/idea.sh` with cygwin after you've done `make images` once. Then the root `jdk` directory will be recognized by idea as an idea project. Note that the guide asks to set the SDK to your images/jdk in the project. Due to problems within Intellij, you should unset the JDK, so the files won't show up a "package xxx already exists in java.base" error. You should set the language level to `X-Experimental features` to mute the warnings about some API usages. And then, you can navigate JDK code as in any other project, such as double-shift and search `Stream` to find the `java.util.stream.Stream` class. And once you are there, you may encounter the bug I've described, that actually used methods will appear as "unused": you will have to type something in one of the method names, like change `filter` to `filter1` so Intellij idea does a reindex and you can find usages of other methods/overrides of the interface. Regards, liach On Sun, Jul 21, 2024 at 2:23?PM Anil <1dropaflame at gmail.com> wrote: > Chen, > Thanks for your reply. > Yes, I am using IntelliJ Community Edition (on Windows 11, Cygwin64). > I did not set up the project - I just opened the package in IJ > C:\Users\Anil\OpenJDK\jdk\src\java.base\share\classes\java\util\stream > Is there something different I should be doing? > thanks, > Anil > > > On Sat, Jul 20, 2024 at 10:39?PM Chen Liang > wrote: > >> Hi Anil, are you using intellij and setting up the project with idea.sh? >> Idea has a bug where its indexing breaks completely; you need to type >> something in the code, like a typo in method name, to force it to refresh. >> >> On Sat, Jul 20, 2024, 9:45?PM Anil <1dropaflame at gmail.com> wrote: >> >>> Hi, >>> I had a small idea on debugging of streams and was trying to implement >>> it to see if it works. >>> I am able to build the OpenJDK (on Windows 11, Cygwin64). >>> However, I am unable to find the implementing class of java.util.Stream. >>> Can you please help? >>> thanks, >>> Anil Philip >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jul 22 02:00:39 2024 From: duke at openjdk.org (duke) Date: Mon, 22 Jul 2024 02:00:39 GMT Subject: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21] In-Reply-To: References: Message-ID: <9L0V9K3Mhv0yvJwvteR8jJPWkHH8bfg6uf1NuQ-3CGE=.4ecc2b4f-94e1-46c1-8b59-3173e7b4f40b@github.com> On Mon, 15 Jul 2024 02:30:54 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. >> The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. >> So I added support for some new methods that accept StringBuilder which is lock-free. >> >> ### Benchmark testcase >> >> @BenchmarkMode(Mode.AverageTime) >> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class JmhDecimalFormat { >> >> private DecimalFormat format; >> >> @Setup(Level.Trial) >> public void setup() { >> format = new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testNewAndFormat() throws InterruptedException { >> new DecimalFormat("#0.00000").format(9524234.1236457); >> } >> >> @Benchmark >> public void testNewOnly() throws InterruptedException { >> new DecimalFormat("#0.00000"); >> } >> >> @Benchmark >> public void testFormatOnly() throws InterruptedException { >> format.format(9524234.1236457); >> } >> } >> >> >> ### Test result >> #### Current JDK before optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op >> >> >> >> #### Current JDK after optimize >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op >> >> >> ### JDK 11 >> >> Benchmark Mode Cnt Score Error Units >> JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op >> JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op >> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op > > lingjun-cg has updated the pull request incrementally with one additional commit since the last revision: > > 8333396: Use StringBuilder internally for java.text.Format.* formatting @lingjun-cg Your change (at version 350085bd835798147bbf2b494e49615536dcc8c4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2241903106 From duke at openjdk.org Mon Jul 22 02:04:07 2024 From: duke at openjdk.org (lingjun-cg) Date: Mon, 22 Jul 2024 02:04:07 GMT Subject: Integrated: 8333396: Use StringBuilder internally for java.text.Format.* formatting In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 04:18:20 GMT, lingjun-cg wrote: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic instructions. But when run with JDK 11, there is no such problem. The reason is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and StringBuffer itself contains many synchronized methods. > So I added support for some new methods that accept StringBuilder which is lock-free. > > ### Benchmark testcase > > @BenchmarkMode(Mode.AverageTime) > @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class JmhDecimalFormat { > > private DecimalFormat format; > > @Setup(Level.Trial) > public void setup() { > format = new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testNewAndFormat() throws InterruptedException { > new DecimalFormat("#0.00000").format(9524234.1236457); > } > > @Benchmark > public void testNewOnly() throws InterruptedException { > new DecimalFormat("#0.00000"); > } > > @Benchmark > public void testFormatOnly() throws InterruptedException { > format.format(9524234.1236457); > } > } > > > ### Test result > #### Current JDK before optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 642.099 ? 1.253 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 989.307 ? 3.676 ns/op > JmhDecimalFormat.testNewOnly avgt 50 303.381 ? 5.252 ns/op > > > > #### Current JDK after optimize > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 351.499 ? 0.761 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly avgt 50 364.214 ? 1.191 ns/op > JmhDecimalFormat.testNewAndFormat avgt 50 658.699 ? 2.311 ns/op > JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op This pull request has now been integrated. Changeset: 4da99158 Author: lingjun.cg URL: https://git.openjdk.org/jdk/commit/4da99158754c25c5d0650f2d042aad3e94a9b0c5 Stats: 765 lines in 16 files changed: 692 ins; 1 del; 72 mod 8333396: Use StringBuilder internally for java.text.Format.* formatting Reviewed-by: naoto, liach, jlu ------------- PR: https://git.openjdk.org/jdk/pull/19513 From ecki at zusammenkunft.net Mon Jul 22 03:06:36 2024 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 22 Jul 2024 05:06:36 +0200 (CEST) Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: <20240721065209.2936F66279F@dd33810.kasserver.com> Message-ID: <20240722030636.BCC37662996@dd33810.kasserver.com> I think StreamSupport has most of the glue code used by the collections, and ReferencePipeline must of the stream implementations, for example the reduce here makes use of the ReduceOps operation class! https://github.com/openjdk/jdk/blob/4da99158754c25c5d0650f2d042aad3e94a9b0c5/src/java.base/share/classes/java/util/stream/ReferencePipeline.java#L696 The special things with steams is, that the Stream class only sets up the evaluation pipeline. Gruss Bernd Anil wrote on 21. July 2024 21:19 (GMT +02:00): > As mentioned in my post, I know where the package is, but I cannot find > the > implementing classes. > For instance, where is this implemented? > > T reduce(T identity, BinaryOperator accumulator); > > > > On Sun, Jul 21, 2024, 1:52?AM Bernd Eckenfels > wrote: > >> Anil wrote on 21. July 2024 04:44 (GMT +02:00): >> > However, I am unable to find the implementing class of >> java.util.Stream. >> >> You find the package in Java.base module: >> >> >> https://github.com/openjdk/jdk/tree/master/src/java.base/share/classes/java/util/stream >> >> >> Gru? >> Bernd >> ? >> https://bernd.eckenfels.net >> > Gru? Bernd ? https://bernd.eckenfels.net From jkarthikeyan at openjdk.org Mon Jul 22 03:37:52 2024 From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan) Date: Mon, 22 Jul 2024 03:37:52 GMT Subject: RFR: 8336860: x86: Change integer src operand for CMoveL of 0 and 1 to long Message-ID: Hi all, This patch fixes `cmovL_imm_01*` instructions matching against an integer immediate 1 instead of a long immediate 1. I noticed while looking at the backend implementation of CMove that the rules specify `immI_1` instead of `immL1`, which means that the instructions can't be matched and instead falls through to the base case. I added a small benchmark and got these results (time unit changed from us to ns for clarity): Baseline Patch Improvement Benchmark (size) Mode Cnt Score Error Units Score Error Units Longs.cmovConstant01 500 avgt 15 133.254 ? 14.804 ns/op 97.845 ? 2.486 ns/op (+ 30.64%) Thoughts and reviews would be appreciated! ------------- Commit messages: - x86: Fix integer operand for CMoveL of 0 and 1 Changes: https://git.openjdk.org/jdk/pull/20275/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20275&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336860 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20275.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20275/head:pull/20275 PR: https://git.openjdk.org/jdk/pull/20275 From duke at openjdk.org Mon Jul 22 07:26:32 2024 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 22 Jul 2024 07:26:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: <7iutnLeeYG_QG3RhPNqiYg24Kn8U4iUn0F836kYIpeI=.59de5071-4648-4307-ace2-ef15cf703816@github.com> Message-ID: On Sat, 20 Jul 2024 06:41:25 GMT, Chen Liang wrote: > > If code is generated through ClassFile, how to access the private methods of classes such as String/StringConcatHelper? > > In that case, you have to encode those methods as live `MethodHandle` objects, passed to the generated class with `defineHiddenClassWithClassData` (just pass the class data object) They can be retrieved in generated code with a CONDY using `MethodHandles.classData`. (This is how the MethodHandle LambdaForm classes referred to other MethodHandles) > > You don't really need to worry about experimenting with bytecode generation right now. This patch as is is very good, and tier 1-3 tests pass. Bytecode gen is aimed at more complex scenarios with multiple constants and various types of arguments instead of this simple concat case. @liach Can you give a sample code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2242267516 From asotona at openjdk.org Mon Jul 22 07:36:34 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 22 Jul 2024 07:36:34 GMT Subject: Integrated: 8336833: Endless loop in Javap ClassWriter In-Reply-To: References: Message-ID: <0AZrvgj8qfXBn2POR-egsMxRdYInz0jWMf-erf7Mf7U=.4247f0df-bc1a-4ecd-a7b1-ef3fd2edb018@github.com> On Fri, 19 Jul 2024 15:32:24 GMT, Adam Sotona wrote: > Artificially corrupted class with overflowing max - min values of `tableswitch` instruction cause infinite loop in `jdk.internal.classfile.impl.CodeImpl::inflateJumpTargets` > > This patch fixes the overflow and adds relevant test. > > Please review. > > Thank you, > Adam This pull request has now been integrated. Changeset: 0db6c15e Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/0db6c15efe255bd313fb2b827d2ee05171e62ae9 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod 8336833: Endless loop in Javap ClassWriter Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/20258 From sgehwolf at openjdk.org Mon Jul 22 09:17:46 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 22 Jul 2024 09:17:46 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v15] In-Reply-To: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> References: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> Message-ID: On Thu, 18 Jul 2024 14:48:02 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Fix by Severin Gehwolf. >> Testcase by Jan Kratochvil. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > Unify 4 copies of adjust_controller() This patch seems OK (though, I'm biased). Please clean up the test. src/hotspot/os/linux/cgroupUtil_linux.cpp line 64: > 62: return cpu->adjust_controller(cpu_total); > 63: } > 64: return cpu; I guess an alternative - and maybe more readable solution - would be to inline `cpu->adjust_controller()` and `mem->adjust_controller()` code here. We have cg version agnostic api to query the limits. We'd just need accessors for `cgroup_path()` and a setter, `set_cgroup_path()` in `CgroupCpuController/CgroupMemoryController` impls. test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 28: > 26: * @key cgroups > 27: * @requires os.family == "linux" > 28: * @requires vm.flagless If you really want to keep that test, then we should add support for the `libcg` dependency in `jtreg-ext` lib so that we can write `requires os.family == "linux" & dep.libcgroup` or some such. ------------- PR Review: https://git.openjdk.org/jdk/pull/17198#pullrequestreview-2191041991 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1686225373 PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1686230300 From djelinski at openjdk.org Mon Jul 22 11:32:34 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 22 Jul 2024 11:32:34 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v5] In-Reply-To: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com> Message-ID: On Sun, 21 Jul 2024 21:15:03 GMT, Nizar Benalla wrote: >> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). >> >> It's mostly fixing some relative links. >> If using `{@docroot}` isn't ideal I can change it. >> >> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes >> >> >> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html >> 106c106 >> <

>> --- >>>

>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html >> 99c99 >> <

>> --- >>> >> 106c106 >> <

>> --- >>> >> 618c618 >> <

>> --- >>> >> 755c755 >> <

>> --- >>> >> 783c783 >> <

>> --- >>> >> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html >> 142c142 >> < the segments allocated by it) becomes unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > undo changes to StructuredTaskScope Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20251#pullrequestreview-2191324725 From weijun at openjdk.org Mon Jul 22 12:42:48 2024 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Jul 2024 12:42:48 GMT Subject: RFR: 8334394: Race condition in Class::protectionDomain [v3] In-Reply-To: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> Message-ID: > Make sure `pd` is always the same object when `getProtectionDomain0` is null. Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: - var to real type - rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19752/files - new: https://git.openjdk.org/jdk/pull/19752/files/4ce5bc24..ed2ba88a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19752&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19752&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19752/head:pull/19752 PR: https://git.openjdk.org/jdk/pull/19752 From weijun at openjdk.org Mon Jul 22 12:42:48 2024 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Jul 2024 12:42:48 GMT Subject: RFR: 8334394: Race condition in Class::protectionDomain [v2] In-Reply-To: References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> Message-ID: On Tue, 16 Jul 2024 12:59:36 GMT, Alan Bateman wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> explain why the test is related to the fix > > test/jdk/java/lang/Class/ProtectionDomainRace.java line 61: > >> 59: private static volatile Throwable failed = null; >> 60: public static void main(String[] args) throws Throwable { >> 61: var ac = (PrivilegedAction) () -> null; > > Did you mean to name the PrivilegedAction "ac"? It might be more readable to change this line to `PrivilegedAction pa = () -> null;`. Done. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19752#discussion_r1686482409 From nbenalla at openjdk.org Mon Jul 22 13:05:36 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 22 Jul 2024 13:05:36 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v5] In-Reply-To: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com> Message-ID: On Sun, 21 Jul 2024 21:15:03 GMT, Nizar Benalla wrote: >> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). >> >> It's mostly fixing some relative links. >> If using `{@docroot}` isn't ideal I can change it. >> >> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes >> >> >> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html >> 106c106 >> <

>> --- >>>

>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html >> 99c99 >> <

>> --- >>> >> 106c106 >> <

>> --- >>> >> 618c618 >> <

>> --- >>> >> 755c755 >> <

>> --- >>> >> 783c783 >> <

>> --- >>> >> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html >> 142c142 >> < the segments allocated by it) becomes unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > undo changes to StructuredTaskScope thank you for the reviews, again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20251#issuecomment-2242906326 From duke at openjdk.org Mon Jul 22 13:05:36 2024 From: duke at openjdk.org (duke) Date: Mon, 22 Jul 2024 13:05:36 GMT Subject: RFR: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation [v5] In-Reply-To: <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> <-DneQHYwTV_UUaxjCNnmMYwUaDfDDxobcJZFLFs50FA=.b2460ecd-ff48-4ef9-a3ef-c8841bc193fc@github.com> Message-ID: On Sun, 21 Jul 2024 21:15:03 GMT, Nizar Benalla wrote: >> Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). >> >> It's mostly fixing some relative links. >> If using `{@docroot}` isn't ideal I can change it. >> >> Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes >> >> >> diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html >> 106c106 >> <

>> --- >>>

>> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html >> 99c99 >> <

>> --- >>> >> 106c106 >> <

>> --- >>> >> 618c618 >> <

>> --- >>> >> 755c755 >> <

>> --- >>> >> 783c783 >> <

>> --- >>> >> diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html >> 142c142 >> < the segments allocated by it) becomes unreachable, >> --- >>> the segments allocated by it) becomes unreachable, >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html >> 120c120 >> < as long as it is reachable. >> --- >>> as long as it is reachable. >> diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html >> 1420c1420 >> < kept reachable >> --- >>> kept reachable >> 1833c1833 >> < unreachable. >> --- >>> unreachable. >> 1899c1899 >> < unreachable. >> --- >>> unreachable. >> diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html >> 395c395 >> ... > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > undo changes to StructuredTaskScope @nizarbenalla Your change (at version 4d5d878491c820db275c7a41611c91cead6fe968) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20251#issuecomment-2242907908 From jpai at openjdk.org Mon Jul 22 13:24:33 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 22 Jul 2024 13:24:33 GMT Subject: RFR: 8334394: Race condition in Class::protectionDomain [v3] In-Reply-To: References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> Message-ID: <_tNMopDhtImce2_4JKw2Mi-nKEX5_KNDsucPVum5eY4=.56dfafef-3907-43aa-b24a-42c1eeabf516@github.com> On Mon, 22 Jul 2024 12:42:48 GMT, Weijun Wang wrote: >> Make sure `pd` is always the same object when `getProtectionDomain0` is null. > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - var to real type > - rename Still looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19752#pullrequestreview-2191565356 From liach at openjdk.org Mon Jul 22 13:27:35 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Jul 2024 13:27:35 GMT Subject: RFR: 8334394: Race condition in Class::protectionDomain [v3] In-Reply-To: References: <8ZugA7PIqsuyhCGgC2ON9QOJNVJnsJHRs3sTN03hfyk=.ec0feeb7-179c-4ca3-aa25-23dc0f03c9a6@github.com> Message-ID: On Mon, 22 Jul 2024 12:42:48 GMT, Weijun Wang wrote: >> Make sure `pd` is always the same object when `getProtectionDomain0` is null. > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - var to real type > - rename Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19752#pullrequestreview-2191574416 From nbenalla at openjdk.org Mon Jul 22 13:29:37 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 22 Jul 2024 13:29:37 GMT Subject: Integrated: 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation In-Reply-To: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> References: <3rr7MfwSBJckc8jtupdyayndHVVsrhvIouG8-bVnVWQ=.5acbb773-c493-4430-b473-952e95de0f6d@github.com> Message-ID: On Fri, 19 Jul 2024 11:11:38 GMT, Nizar Benalla wrote: > Can I get a review for this change that fixes some broken links in javadoc comments? The new docs are hosted [here](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8336039-warnings-links/). > > It's mostly fixing some relative links. > If using `{@docroot}` isn't ideal I can change it. > > Here is the result of running `diff -r docs-master docs` on the docs from master vs and after these changes > > > diff -r docs-master/api/java.base/java/lang/classfile/components/CodeStackTracker.html docs/api/java.base/java/lang/classfile/components/CodeStackTracker.html > 106c106 > <

> --- >>

> diff -r docs-master/api/java.base/java/lang/classfile/package-summary.html docs/api/java.base/java/lang/classfile/package-summary.html > 99c99 > <

> --- >> > 106c106 > <

> --- >> > 618c618 > <

> --- >> > 755c755 > <

> --- >> > 783c783 > <

> --- >> > diff -r docs-master/api/java.base/java/lang/foreign/Arena.html docs/api/java.base/java/lang/foreign/Arena.html > 142c142 > < the segments allocated by it) becomes unreachable, > --- >> the segments allocated by it) becomes unreachable, > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.Scope.html docs/api/java.base/java/lang/foreign/MemorySegment.Scope.html > 120c120 > < as long as it is reachable. > --- >> as long as it is reachable. > diff -r docs-master/api/java.base/java/lang/foreign/MemorySegment.html docs/api/java.base/java/lang/foreign/MemorySegment.html > 1420c1420 > < kept reachable > --- >> kept reachable > 1833c1833 > < unreachable. > --- >> unreachable. > 1899c1899 > < unreachable. > --- >> unreachable. > diff -r docs-master/api/java.base/java/lang/foreign/SymbolLookup.html docs/api/java.base/java/lang/foreign/SymbolLookup.html > 395c395 > < unreachable. The > --- >> 160: memory_max_filename = isCgroup2 ? "memory.max" : "memory.limit_in_bytes"; > 161: Files.writeString(Path.of(sysFsCgroup + "/" + CGROUP_OUTER + "/" + memory_max_filename), "" + MEMORY_MAX_OUTER); This logic doesn't seem to detect `cgv1` and `cgv2` correctly. When I run this on a cgv1 system (hybrid) then I get a failure that looks like this: ----------System.err:(33/2506)---------- -------------------------------------------------------------------------------- command: cgdelete -r -g memory:jdktest150899 -------------------------------------------------------------------------------- stdout -------------------------------------------------------------------------------- stderr cgdelete: cannot remove group 'jdktest150899': No such file or directory -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- command: cgcreate -g memory:jdktest150899/inner -------------------------------------------------------------------------------- stdout -------------------------------------------------------------------------------- stderr -------------------------------------------------------------------------------- isCgroup2 = true -------------------------------------------------------------------------------- cgroup2 mount point: /sys/fs/cgroup/unified java.nio.file.NoSuchFileException: /sys/fs/cgroup/unified/jdktest150899/memory.max at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:262) at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:482) at java.base/java.nio.file.Files.newOutputStream(Files.java:228) at java.base/java.nio.file.Files.write(Files.java:3516) at java.base/java.nio.file.Files.writeString(Files.java:3738) at java.base/java.nio.file.Files.writeString(Files.java:3678) at NestedCgroup$Test.(NestedCgroup.java:161) at NestedCgroup$TestTwoLimits.(NestedCgroup.java:190) at NestedCgroup.main(NestedCgroup.java:221) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:588) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575) JavaTest Message: Test threw exception: java.nio.file.NoSuchFileException: /sys/fs/cgroup/unified/jdktest150899/memory.max JavaTest Message: shutting down test I suggest to use code similar to other tests which use the metrics API to figure out which cgroup version is in use. For example `TestMemoryWithCgroupV1` has this code snippet which should work just fine here as well: Metrics metrics = Metrics.systemMetrics(); if (metrics == null) { System.out.println("TEST PASSED!!!"); return; } if ("cgroupv1".equals(metrics.getProvider())) { // cg v1 branch } else { // cg v2 branch } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1686587070 From aph at openjdk.org Mon Jul 22 14:03:34 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 14:03:34 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v3] In-Reply-To: <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Thu, 11 Jul 2024 22:53:42 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 1410: >> >>> 1408: return nullptr; >>> 1409: } else if (num_extra_slots == 0) { >>> 1410: if (num_extra_slots == 0 && interfaces->length() <= 1) { >> >> Since `secondary_supers` are hashed unconditionally now, is `interfaces->length() <= 1` check still needed? > > Also, `num_extra_slots == 0` check is redundant. > Since `secondary_supers` are hashed unconditionally now, is `interfaces->length() <= 1` check still needed? I don't think so, no. Our incoming `transitive_interfaces` is formed by concatenating the interface lists of our superclasses and superinterfaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1686607068 From lancea at openjdk.org Mon Jul 22 14:09:31 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 22 Jul 2024 14:09:31 GMT Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt In-Reply-To: References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com> Message-ID: On Sun, 21 Jul 2024 16:32:09 GMT, Technici4n wrote: > Oh, I missed the assignment and did not check with @LanceAndersen. I don't have a problem with you or someone else taking ownership of this issue once the discussion that Alan points out comes to a conclusion. Until the overall path forward is agreed, I would suggest that we hold off on any changes to ZipFS ------------- PR Comment: https://git.openjdk.org/jdk/pull/20274#issuecomment-2243055981 From aph at openjdk.org Mon Jul 22 14:18:33 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 14:18:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v3] In-Reply-To: <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Fri, 5 Jul 2024 22:30:09 GMT, Vladimir Ivanov wrote: >> Andrew Haley has updated the pull request incrementally with four additional commits since the last revision: >> >> - Review feedback >> - Review feedback >> - Review feedback >> - Cleanup check_klass_subtype_fast_path for AArch64, deleting dead code > > src/hotspot/share/oops/klass.cpp line 175: > >> 173: if (secondary_supers()->at(i) == k) { >> 174: if (UseSecondarySupersCache) { >> 175: ((Klass*)this)->set_secondary_super_cache(k); > > Does it make sense to assert `UseSecondarySupersCache` in `Klass::set_secondary_super_cache()`? I kinda hate this because we're casting away `const`, which is UB. I think I'd just take it out, but once I do that, I don't think anything sets `_secondary_super_cache`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1686631030 From liach at openjdk.org Mon Jul 22 14:30:35 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Jul 2024 14:30:35 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: <7iutnLeeYG_QG3RhPNqiYg24Kn8U4iUn0F836kYIpeI=.59de5071-4648-4307-ace2-ef15cf703816@github.com> Message-ID: On Mon, 22 Jul 2024 07:24:08 GMT, Shaojin Wen wrote: >>> If code is generated through ClassFile, how to access the private methods of classes such as String/StringConcatHelper? >> >> In that case, you have to encode those methods as live `MethodHandle` objects, passed to the generated class with `defineHiddenClassWithClassData` (just pass the class data object) >> They can be retrieved in generated code with a CONDY using `MethodHandles.classData`. (This is how the MethodHandle LambdaForm classes referred to other MethodHandles) >> >> ---- >> >> You don't really need to worry about experimenting with bytecode generation right now. This patch as is is very good, and tier 1-3 tests pass. Bytecode gen is aimed at more complex scenarios with multiple constants and various types of arguments instead of this simple concat case. > >> > If code is generated through ClassFile, how to access the private methods of classes such as String/StringConcatHelper? >> >> In that case, you have to encode those methods as live `MethodHandle` objects, passed to the generated class with `defineHiddenClassWithClassData` (just pass the class data object) They can be retrieved in generated code with a CONDY using `MethodHandles.classData`. (This is how the MethodHandle LambdaForm classes referred to other MethodHandles) >> >> You don't really need to worry about experimenting with bytecode generation right now. This patch as is is very good, and tier 1-3 tests pass. Bytecode gen is aimed at more complex scenarios with multiple constants and various types of arguments instead of this simple concat case. > > @liach Can you give a sample code? @wenshao Answered at https://github.com/openjdk/jdk/pull/20273#issuecomment-2243101199 since this question is more closely related to that patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2243102417 From liach at openjdk.org Mon Jul 22 14:30:34 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Jul 2024 14:30:34 GMT Subject: RFR: 8336856: Optimize String Concat In-Reply-To: References: Message-ID: On Sun, 21 Jul 2024 12:25:36 GMT, Shaojin Wen wrote: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 For the question [here](https://github.com/openjdk/jdk/pull/20253#issuecomment-2242267516): 1. A sample of loading an otherwise inaccessible method handle from class data: https://github.com/openjdk/jdk/blob/c3226aaeb810521257e961be5763552c86ee5651/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L517-L518 2. In offline discussion with Claes, we are thinking of generating direct bytecode to avoid the overhead of creating a lot of intermediate method handles. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2243101199 From rriggs at openjdk.org Mon Jul 22 14:39:33 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 22 Jul 2024 14:39:33 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v4] In-Reply-To: References: Message-ID: <6b4c8DgAevLYWryQiG9bhGlmVdddapMQEgoCqORbbEU=.d7dd2b19-0f89-46f2-992b-e45f923fe84a@github.com> On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen wrote: >> String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. >> >> >> Improved performance includes the following: >> >> ## 1. Write directly during the parse process to reduce object allocation. >> >> In the current Formatter implementation, some objects do not need to be allocated, such as: >> >> >> class Formatter { >> public Formatter format(Locale l, String format, Object ... args) { >> List fsa = parse(format); >> // ... >> } >> >> static List parse(String s) { >> ArrayList al = new ArrayList<>(); >> >> while (i < max) { >> int n = s.indexOf('%', i); >> if (n < 0) { >> // >> al.add(new FixedString(s, i, max)); >> } >> } >> } >> } >> >> In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. >> >> ## 2. Fast path print >> Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. >> >> ## 3. String.format directly calls j.u.Formatter >> String.format directly calls j.u.Formatter via SharedSecrets to improve performance > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Implementing JavaUtilFormatterAccess using anonymous class Re-designing the formatting implementation should wait for the re-emergence of the templates project and implementation. It has similar performance goals and it would be beneficial to have a single implementation of the lower levels to avoid code duplication and take advantage of the optimizations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2243122522 From aph at openjdk.org Mon Jul 22 14:59:33 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 14:59:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v3] In-Reply-To: <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Thu, 11 Jul 2024 23:07:43 GMT, Vladimir Ivanov wrote: >> Andrew Haley has updated the pull request incrementally with four additional commits since the last revision: >> >> - Review feedback >> - Review feedback >> - Review feedback >> - Cleanup check_klass_subtype_fast_path for AArch64, deleting dead code > > src/hotspot/share/oops/klass.inline.hpp line 117: > >> 115: } >> 116: >> 117: inline bool Klass::search_secondary_supers(Klass *k) const { > > I see you moved `Klass::search_secondary_supers` in `klass.inline.hpp`, but I'm not sure how it interacts with `Klass::is_subtype_of` (the sole caller) being declared in `klass.hpp`. > > Will the inlining still happen if `Klass::is_subtype_of()` callers include `klass.hpp`? Presumably this question applies to every function in `klass.inline.hpp`? Practically everything does `#include "oops/klass.inline.hpp"`. It's inlined in about 120 files, as far as I can see everywhere such queries are made. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1686697935 From aph at openjdk.org Mon Jul 22 15:08:44 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 15:08:44 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v3] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Thu, 18 Jul 2024 20:11:03 GMT, Vladimir Ivanov wrote: > Alternatively, `Klass::is_subtype_of()` can unconditionally perform linear search over secondary_supers array. > > Even though I very much like to see table lookup written in C++ (accompanying heavily optimized platform-specific MacroAssembler variants), it would make C++ runtime even simpler. It would, but there is something to be said for being able to provide a fast "no" answer for interface membership. I'll agree it's probably not a huge difference. I guess `is_cloneable_fast()` exists only because searching the interfaces is slow. Also, if table lookup is written in C++ but not used, it will rot. Also also, `Klass::is_subtype_of()` is used for C1 runtime. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1686707925 From duke at openjdk.org Mon Jul 22 15:21:34 2024 From: duke at openjdk.org (David M. Lloyd) Date: Mon, 22 Jul 2024 15:21:34 GMT Subject: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 18:34:00 GMT, Roger Riggs wrote: > Is there a high level description of how these methods would be used? They would be used identically to how the `readObjectForSerialization` and `writeObjectForSerialization` methods are used. The caller would pass the object as a pseudo-"receiver" and the OIS/OOS, and it would be as if the caller had called a method handle to a `readObject` or `writeObject` that writes or reads the serializable fields of the object based on acquiring a `GetField`/`PutField` object. > There seems to be a lot of generation of code that duplicates what OIS/OOS already do and that seems unnecessary. The current iteration simulates the behavior described above by generating methods that exactly and literally implements the behavior as specified. That said, I agree that there could possibly be a way to reuse OIS/OOS code for this instead, so that the method works *as if* it had been generated (but instead would be a stub which calls the relevant OIS/OOS method(s) with the appropriate arguments). It might require some small refactoring. My initial thought was to avoid touching that code as much as possible, but I can look into reusing the existing `Unsafe`-based code more and see what that would look like. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2243219626 From aph at openjdk.org Mon Jul 22 16:39:33 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 16:39:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v3] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Mon, 22 Jul 2024 15:03:12 GMT, Andrew Haley wrote: >> Alternatively, `Klass::is_subtype_of()` can unconditionally perform linear search over secondary_supers array. >> >> Even though I very much like to see table lookup written in C++ (accompanying heavily optimized platform-specific MacroAssembler variants), it would make C++ runtime even simpler. > >> Alternatively, `Klass::is_subtype_of()` can unconditionally perform linear search over secondary_supers array. >> >> Even though I very much like to see table lookup written in C++ (accompanying heavily optimized platform-specific MacroAssembler variants), it would make C++ runtime even simpler. > > It would, but there is something to be said for being able to provide a fast "no" answer for interface membership. I'll agree it's probably not a huge difference. I guess `is_cloneable_fast()` exists only because searching the interfaces is slow. > Also, if table lookup is written in C++ but not used, it will rot. > Also also, `Klass::is_subtype_of()` is used for C1 runtime. Thinking about it some more, I don't really mind. There may be some virtue to moving lookup_secondary_supers_table() to a comment in the back end(s), and the expansion of population_count() is rather bloaty. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1686835253 From liach at openjdk.org Mon Jul 22 16:42:06 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Jul 2024 16:42:06 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v2] In-Reply-To: References: Message-ID: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. 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: - Update to the specification per Alex feedback - Merge branch 'fix/cf-apis' of https://github.com/liachmodded/jdk into fix/typeanno-model - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/752451a7..877b9384 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=00-01 Stats: 605 lines in 40 files changed: 515 ins; 31 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From aph at openjdk.org Mon Jul 22 16:50:47 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 16:50:47 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Review comments - Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19989/files - new: https://git.openjdk.org/jdk/pull/19989/files/98f6b2b7..c252efcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=02-03 Stats: 41 lines in 10 files changed: 9 ins; 17 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From aph at openjdk.org Mon Jul 22 16:50:48 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 16:50:48 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Thu, 11 Jul 2024 23:57:27 GMT, Vladimir Ivanov wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - Review comments >> - Review comments > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4810: > >> 4808: Label* L_success, >> 4809: Label* L_failure) { >> 4810: // NB! Callers may assume that, when temp2_reg is a valid register, > > Oh, that's a subtle point... Can we make it more evident at call sites? Done. I think the only code that still depends on it is the C2 pattern that uses check_klass_subtype_slow_path_linear in x86_32.ad and x86_64.ad. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1686845837 From duke at openjdk.org Mon Jul 22 16:52:06 2024 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 22 Jul 2024 16:52:06 GMT Subject: RFR: 8336856: Optimize String Concat [v2] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: non-MH-based implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/227158a7..c9acbe93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=00-01 Stats: 897 lines in 4 files changed: 206 ins; 686 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From aph at openjdk.org Mon Jul 22 17:10:33 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 17:10:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: On Mon, 22 Jul 2024 16:50:47 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Review comments > - Review comments All done apart from the questions of: 1. Should `Klass::linear_search_secondary_supers() const` call `set_secondary_super_cache()`? (Strong no from me. It's UB.) 2. Should we use a straight linear search for secondary C++ supers in the runtime, i.e.not changing it for now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2243430000 From sgehwolf at openjdk.org Mon Jul 22 17:18:09 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 22 Jul 2024 17:18:09 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics Message-ID: 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 proposed 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: - [ ] GHA - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems - [x] Some manual testing using systemd slices ------------- Depends on: https://git.openjdk.org/jdk/pull/17198 Commit messages: - 8336881: [Linux] Support for hierarchical limits for Metrics Changes: https://git.openjdk.org/jdk/pull/20280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336881 Stats: 1511 lines in 24 files changed: 1260 ins; 152 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280 From sgehwolf at openjdk.org Mon Jul 22 17:18:09 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 22 Jul 2024 17:18:09 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:56:00 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 proposed 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: > > - [ ] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices Note for reviewers. I'll be away until early August, so my responses might be delayed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2243438170 From aph at openjdk.org Mon Jul 22 17:19:46 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Jul 2024 17:19:46 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: <6P17gX_V6nL3hsgbuPrGN4Y8nzyoQMs3fTLaiRaOzwA=.e3eb0ea0-d41c-4222-a1f3-65f9075dbb4d@github.com> > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19989/files - new: https://git.openjdk.org/jdk/pull/19989/files/c252efcb..02cfd130 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=03-04 Stats: 18 lines in 6 files changed: 1 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From naoto at openjdk.org Mon Jul 22 17:20:42 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 22 Jul 2024 17:20:42 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote: >> Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > removed a blank line Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20220#issuecomment-2243443539 From naoto at openjdk.org Mon Jul 22 17:20:43 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 22 Jul 2024 17:20:43 GMT Subject: RFR: 8336479: Provide Process.waitFor(Duration) [v5] In-Reply-To: References: <4vicTmz9bmkIn52hMQlU5150BKwfcYI9eEG56ZtaWh4=.c95b0d47-a69b-41c5-a7df-07ad88d8f760@github.com> <-YwiNkhbOyG7emMi9WunX_ijLe9TSjmDpwgyblVPvaY=.09d378e8-c970-44c5-8076-e5dc6831e018@github.com> Message-ID: On Fri, 19 Jul 2024 14:47:09 GMT, Roger Riggs wrote: >> I think the test tool should not depend on the internal implementation, so I think it should be kept. > > Its still unnecessary, adds bulk and maintenance overhead that will go unused. I will leave it as is for now, as it is consistent with other `waitFor` overrides. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20220#discussion_r1686879438 From naoto at openjdk.org Mon Jul 22 17:20:44 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 22 Jul 2024 17:20:44 GMT Subject: Integrated: 8336479: Provide Process.waitFor(Duration) In-Reply-To: References: Message-ID: <6U8yDDrlyKfW31vGj9jjeH4_FFtflaHldr13m1Xa2zU=.dbe025cc-dbc8-4f61-a0fd-e4a4e6d5cf6e@github.com> On Wed, 17 Jul 2024 17:36:29 GMT, Naoto Sato wrote: > Proposing a new overload method for `Process#waitFor()` which takes a `Duration` for the timeout value. This will reduce the possibility for making mistakes with the `TimeUnit` in the other overload method. A corresponding CSR has also been drafted. This pull request has now been integrated. Changeset: c1c97042 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/c1c9704268e9e651cd82c8550913d8ac60aa494a Stats: 115 lines in 3 files changed: 113 ins; 0 del; 2 mod 8336479: Provide Process.waitFor(Duration) Reviewed-by: liach, jpai, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/20220 From cushon at openjdk.org Mon Jul 22 17:23:34 2024 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 22 Jul 2024 17:23:34 GMT Subject: Integrated: 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com> Message-ID: <5FxLuelH1WYNHvkVOgyvfVxwWL_ts-A28QkAWRtw3Mc=.2a98c664-c484-483b-8df6-65d48acee574@github.com> On Fri, 19 Jul 2024 19:35:14 GMT, Liam Miller-Cushon wrote: > This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3). > > I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that. > > I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants. This pull request has now been integrated. Changeset: 8438c585 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/8438c5853f4ae5cef4e861cd0b3952371c886f45 Stats: 12 lines in 6 files changed: 0 ins; 2 del; 10 mod 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID Reviewed-by: jpai, vtewari, lancea ------------- PR: https://git.openjdk.org/jdk/pull/20264 From eirbjo at openjdk.org Mon Jul 22 18:11:33 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 22 Jul 2024 18:11:33 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 23:16:07 GMT, Archie Cobbs wrote: >> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 143: >> >>> 141: * @param allowConcatenation true to allow multiple concatenated compressed data streams, >>> 142: * or false to expect exactly one compressed data stream >>> 143: * @param ignoreExtraBytes true to tolerate and ignore extra bytes, false to throw >> >> The term "extra" here feels somewhat open to interpretation. Specifically, "extra" sounds like something that is out of the ordinary, but not uncommon or wrong. It could be used when describing an optional feature in a format specification. >> >> The API description referes to "unexpected data". Perhaps the word "unexpected" is a more precise and descriptive term to use in this option? So `ignoreUnexpectedBytes` or `ignoreUnexpectedData`. >> >> I think my eyebrows would be raised more when seeing someone ignoring 'unexpected data' rather than when ignoring 'extra data'. >> >> I know this might smell of bikeshedding, but naming is important (and hard!). > >> The term "extra" here feels somewhat open to interpretation. Specifically, "extra" sounds like something that is out of the ordinary, but not uncommon or wrong. It could be used when describing an optional feature in a format specification. >> >> The API description referes to "unexpected data". Perhaps the word "unexpected" is a more precise and descriptive term to use in this option? So ignoreUnexpectedBytes or ignoreUnexpectedData. > > This is a good point.. because it's actually a bit subtle what kind of data is being referred to here as being "ignored". Even "unexpected" doesn't quite capture it. > > To be precise, here's what bytes the `ignoreExtraBytes` parameter is going to cause to be ignored: > * In the case `allowConcatenation == false`, it really does refer to "extra" or "extraneous" data, that is: one or more bytes having any value appearing _after_ the end of the GZIP trailer frame. > * In the case `allowConcatenation == true`, it means a truncated or invalid GZIP _header frame_ appearing after the end of any GZIP trailer frame. > > The second case means "unexpected" seems wrong because why would unexpected data in a header frame be treated any differently from unexpected data any other frame (which of course is not going to be ignored but instead will trigger an exception)? > > So maybe this is just more evidence that we shouldn't use boolean parameters - because they're not really orthogonal. > > What about something like: > > > public enum ConcatPolicy { > DISALLOW_STRICT, // one GZIP stream, nothing else > DISALLOW_LENIENT, // one GZIP stream, ignore any extra byte(s) > ALLOW_STRICT, // N GZIP streams, nothing else > ALLOW_LENIENT; // N GZIP streams, stop at, and ignore, an invalid header frame > } > > The legacy behavior would of course correspond to `ALLOW_LENIENT`. Another thought: Are we sure we would want to introduce a new mode now which does _not_ allow concatenation, but _does_ ignore trailing data? If the ignore mode is really discouraged, why open a new mode of config allowing it? In other words, could we instead (at least conceptually) have the policies LEGACY, SINGLE_STREAM, CONCATENATED_STREAM where the latter two always reject trailing data? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1686942202 From acobbs at openjdk.org Mon Jul 22 19:26:34 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 22 Jul 2024 19:26:34 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 18:08:52 GMT, Eirik Bj?rsn?s wrote: >>> The term "extra" here feels somewhat open to interpretation. Specifically, "extra" sounds like something that is out of the ordinary, but not uncommon or wrong. It could be used when describing an optional feature in a format specification. >>> >>> The API description referes to "unexpected data". Perhaps the word "unexpected" is a more precise and descriptive term to use in this option? So ignoreUnexpectedBytes or ignoreUnexpectedData. >> >> This is a good point.. because it's actually a bit subtle what kind of data is being referred to here as being "ignored". Even "unexpected" doesn't quite capture it. >> >> To be precise, here's what bytes the `ignoreExtraBytes` parameter is going to cause to be ignored: >> * In the case `allowConcatenation == false`, it really does refer to "extra" or "extraneous" data, that is: one or more bytes having any value appearing _after_ the end of the GZIP trailer frame. >> * In the case `allowConcatenation == true`, it means a truncated or invalid GZIP _header frame_ appearing after the end of any GZIP trailer frame. >> >> The second case means "unexpected" seems wrong because why would unexpected data in a header frame be treated any differently from unexpected data any other frame (which of course is not going to be ignored but instead will trigger an exception)? >> >> So maybe this is just more evidence that we shouldn't use boolean parameters - because they're not really orthogonal. >> >> What about something like: >> >> >> public enum ConcatPolicy { >> DISALLOW_STRICT, // one GZIP stream, nothing else >> DISALLOW_LENIENT, // one GZIP stream, ignore any extra byte(s) >> ALLOW_STRICT, // N GZIP streams, nothing else >> ALLOW_LENIENT; // N GZIP streams, stop at, and ignore, an invalid header frame >> } >> >> The legacy behavior would of course correspond to `ALLOW_LENIENT`. > > Another thought: > > Are we sure we would want to introduce a new mode now which does _not_ allow concatenation, but _does_ ignore trailing data? > > If the ignore mode is really discouraged, why open a new mode of config allowing it? > > In other words, could we instead (at least conceptually) have the policies LEGACY, SINGLE_STREAM, CONCATENATED_STREAM where the latter two always reject trailing data? > Are we sure we would want to introduce a new mode now which does not allow concatenation, but does ignore trailing data? I don't see it as necessary. It's certainly not a case that anyone is currently relying on. So it's fine with me to omit it. If are calling this a "concatenated stream policy" then we could have: public enum ConcatPolicy { DISALLOW, ALLOW, ALLOW_LENIENT; } (I'm avoiding `LEGACY` which makes sense today but might make less sense N years from now.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1687042483 From acobbs at openjdk.org Mon Jul 22 20:49:03 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 22 Jul 2024 20:49:03 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v6] In-Reply-To: References: Message-ID: > `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. > > There are several issues with this: > > 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. > 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). > 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. > > On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). > > So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Change concatenation policy config from booleans to new ConcatPolicy enum. - Merge branch 'master' into JDK-8322256 - Bump @since from 23 to 24. - Merge branch 'master' into JDK-8322256 - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. - Simplify code by eliminating an impossible case. - Field name change and Javadoc wording tweaks. - Merge branch 'master' into JDK-8322256 - Javadoc wording tweaks. - Merge branch 'master' into JDK-8322256 - ... and 4 more: https://git.openjdk.org/jdk/compare/388fcf03...bb78bd08 ------------- Changes: https://git.openjdk.org/jdk/pull/18385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=05 Stats: 383 lines in 2 files changed: 357 ins; 13 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/18385.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385 PR: https://git.openjdk.org/jdk/pull/18385 From naoto at openjdk.org Mon Jul 22 22:15:00 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 22 Jul 2024 22:15:00 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() Message-ID: This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/20285/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20285&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336679 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20285/head:pull/20285 PR: https://git.openjdk.org/jdk/pull/20285 From duke at openjdk.org Mon Jul 22 22:34:01 2024 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 22 Jul 2024 22:34:01 GMT Subject: RFR: 8336856: Optimize String Concat [v3] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: non-MH-based implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/c9acbe93..94709c0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=01-02 Stats: 68 lines in 1 file changed: 34 ins; 15 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From bpb at openjdk.org Mon Jul 22 22:40:30 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 22 Jul 2024 22:40:30 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 22:10:07 GMT, Naoto Sato wrote: > This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20285#pullrequestreview-2192656420 From liach at openjdk.org Mon Jul 22 22:56:35 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Jul 2024 22:56:35 GMT Subject: Integrated: 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved In-Reply-To: References: Message-ID: <8h44uBzzSDQzXzRRhyW50669-1eNWdgUQ2LHXCDpAWw=.d4e6ee67-3242-4acd-bf1f-a0cbbea414ed@github.com> On Tue, 2 Jul 2024 16:20:54 GMT, Chen Liang wrote: > Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc` specification. This pull request has now been integrated. Changeset: 96e4a187 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/96e4a1876a3ab0819c017ba9b634711fe19e58c3 Stats: 26 lines in 2 files changed: 15 ins; 0 del; 11 mod 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/19991 From liach at openjdk.org Mon Jul 22 22:57:39 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Jul 2024 22:57:39 GMT Subject: Integrated: 8335922: Incorrect @Stable usage of LambdaForm$Name.index In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 01:45:57 GMT, Chen Liang wrote: > The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. On a strategic view, this index field should just become final so that `Name` becomes eligible for value class migration once valhalla comes. This patch makes the `index` field final and updates the usages correspondingly. This pull request has now been integrated. Changeset: aabec4a9 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/aabec4a947ed2a808a1443fa6b2dabedd8c2dd9f Stats: 51 lines in 1 file changed: 4 ins; 28 del; 19 mod 8335922: Incorrect @Stable usage of LambdaForm$Name.index Reviewed-by: jvernee, shade ------------- PR: https://git.openjdk.org/jdk/pull/20178 From duke at openjdk.org Tue Jul 23 02:09:37 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 02:09:37 GMT Subject: RFR: 8336856: Optimize String Concat [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 22:34:01 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > non-MH-based implementation It is now implemented based on bytecode-spinning. Private member access is implemented by StringConcatHelp lookup, but there are several strange errors in the build, and I don't know why. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2244113274 From darcy at openjdk.org Tue Jul 23 02:26:31 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 Jul 2024 02:26:31 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v2] In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote: >> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. >> >> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Reduce changes src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 255: > 253: } > 254: > 255: @Stable Please add a textual description of the semantics of this array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20168#discussion_r1687337615 From duke at openjdk.org Tue Jul 23 02:37:09 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 02:37:09 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v3] In-Reply-To: References: Message-ID: > Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. > > The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: add description for DECIMAL_DIGITS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20168/files - new: https://git.openjdk.org/jdk/pull/20168/files/e2cbf4a0..19d6f04b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=01-02 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168 PR: https://git.openjdk.org/jdk/pull/20168 From duke at openjdk.org Tue Jul 23 02:48:56 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 02:48:56 GMT Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong [v4] In-Reply-To: References: Message-ID: > Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method. > > The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: add description for DECIMAL_DIGITS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20168/files - new: https://git.openjdk.org/jdk/pull/20168/files/19d6f04b..73d5e6a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20168&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20168/head:pull/20168 PR: https://git.openjdk.org/jdk/pull/20168 From liach at openjdk.org Tue Jul 23 04:15:50 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 04:15:50 GMT Subject: RFR: 8336934: Clean up JavaLangReflectAccess Message-ID: Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`. ------------- Commit messages: - 8336934: Clean up JavaLangReflectAccess Changes: https://git.openjdk.org/jdk/pull/20290/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20290&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336934 Stats: 185 lines in 6 files changed: 19 ins; 147 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/20290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20290/head:pull/20290 PR: https://git.openjdk.org/jdk/pull/20290 From liach at openjdk.org Tue Jul 23 04:49:55 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 04:49:55 GMT Subject: RFR: 8336927: Missing equals and hashCode in java.lang.classfile.Annotation Message-ID: Convert `AnnotationImpl` to a record so it comes with proper `equals` and `hashCode` implementations. This also fixes the comparison for annotation-valued annotation element values. ------------- Commit messages: - 8336927: Missing equals and hashCode in java.lang.classfile.Annotation Changes: https://git.openjdk.org/jdk/pull/20291/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20291&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336927 Stats: 43 lines in 2 files changed: 23 ins; 14 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20291.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20291/head:pull/20291 PR: https://git.openjdk.org/jdk/pull/20291 From sundar at openjdk.org Tue Jul 23 05:01:05 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Tue, 23 Jul 2024 05:01:05 GMT Subject: RFR: 8204582: Extra spaces in jlink documentation make it incorrect. Message-ID: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> removed extra whitespaces ------------- Commit messages: - 8204582: Extra spaces in jlink documentation make it incorrect Changes: https://git.openjdk.org/jdk/pull/20292/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20292&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8204582 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20292.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20292/head:pull/20292 PR: https://git.openjdk.org/jdk/pull/20292 From liach at openjdk.org Tue Jul 23 05:02:38 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:02:38 GMT Subject: RFR: 8335938: Review XxxBuilder.original and XxxModel.parent [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 15:16:23 GMT, Chen Liang wrote: >> Remove unused `Class/Field/Method/CodeBuilder.original()`, and make `Field/Method/CodeModel.parent()` return present only if it's bound (i.e. not buffered transformed). See the CSR for details. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/builder-original > - 8335938: Review XxxBuilder.original and XxxModel.parent Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20177#issuecomment-2244254775 From liach at openjdk.org Tue Jul 23 05:02:39 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:02:39 GMT Subject: Integrated: 8335938: Review XxxBuilder.original and XxxModel.parent In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:33:51 GMT, Chen Liang wrote: > Remove unused `Class/Field/Method/CodeBuilder.original()`, and make `Field/Method/CodeModel.parent()` return present only if it's bound (i.e. not buffered transformed). See the CSR for details. This pull request has now been integrated. Changeset: 22914e07 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/22914e0774f5bb8ded3d825bea1dc312b12d4d4a Stats: 93 lines in 12 files changed: 1 ins; 81 del; 11 mod 8335938: Review XxxBuilder.original and XxxModel.parent Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20177 From liach at openjdk.org Tue Jul 23 05:07:44 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:07:44 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v4] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Chen Liang 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 branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge BoundAttributeTest - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis - 2 test failures - Web review cleanup - Remove WritableElement and reduce Writable usage The rest of Writable in annotations can be removed in later cleanup - Fix up usages of Util.write - ... and 1 more: https://git.openjdk.org/jdk/compare/22914e07...5ce1943a ------------- Changes: https://git.openjdk.org/jdk/pull/20205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=03 Stats: 457 lines in 49 files changed: 99 ins; 198 del; 160 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From liach at openjdk.org Tue Jul 23 05:07:44 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:07:44 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v3] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 23:12:59 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge BoundAttributeTest > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-apis > - 2 test failures > - Web review cleanup > - Remove WritableElement and reduce Writable usage > > The rest of Writable in annotations can be removed in later cleanup > - Fix up usages of Util.write > - Hide writeTo from all class file elements > > To consider the fate of WritableElement later! Re-requesting a review: there was a conflict with #20244 in implements list of `DirectMethodBuilder`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20205#issuecomment-2244260340 From alanb at openjdk.org Tue Jul 23 05:09:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Jul 2024 05:09:30 GMT Subject: RFR: 8204582: Extra spaces in jlink documentation make it incorrect. In-Reply-To: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> References: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> Message-ID: <8XsXUvrTs-u6o7iF-yFHd3A2KcHFx-n7JQotDMj8hNQ=.cfbbd91c-46f2-49ae-9562-3b100be079f1@github.com> On Tue, 23 Jul 2024 04:55:16 GMT, Athijegannathan Sundararajan wrote: > removed extra whitespaces Are you going to update --limit-modules too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20292#issuecomment-2244261704 From liach at openjdk.org Tue Jul 23 05:40:05 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 05:40:05 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v5] In-Reply-To: References: Message-ID: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix test compile errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20205/files - new: https://git.openjdk.org/jdk/pull/20205/files/5ce1943a..09a6f60a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20205&range=03-04 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20205/head:pull/20205 PR: https://git.openjdk.org/jdk/pull/20205 From asotona at openjdk.org Tue Jul 23 07:04:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 23 Jul 2024 07:04:33 GMT Subject: RFR: 8336927: Missing equals and hashCode in java.lang.classfile.Annotation In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 04:44:57 GMT, Chen Liang wrote: > Convert `AnnotationImpl` to a record so it comes with proper `equals` and `hashCode` implementations. This also fixes the comparison for annotation-valued annotation element values. Looks good to me, thanks for the fix. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20291#pullrequestreview-2193137329 From asotona at openjdk.org Tue Jul 23 07:06:34 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 23 Jul 2024 07:06:34 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 05:40:05 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix test compile errors Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20205#pullrequestreview-2193140947 From rgiulietti at openjdk.org Tue Jul 23 07:46:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 23 Jul 2024 07:46:37 GMT Subject: Integrated: 8334758: Incorrect note in Javadoc for a few RandomGenerator methods In-Reply-To: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> References: <22beVoDBRKPuiojwzpCpSggUTGO5wHkY9hM3HDvQnk8=.7c0f6f26-2686-41a3-9638-2a2983324e81@github.com> Message-ID: On Fri, 12 Jul 2024 06:28:15 GMT, Raffaello Giulietti wrote: > Small corrections to @implSpec notes in a few methods in RandomGenerator. This pull request has now been integrated. Changeset: 4c7b3e7f Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/4c7b3e7fc39a06e208ea1668095d055457549d63 Stats: 28 lines in 1 file changed: 0 ins; 5 del; 23 mod 8334758: Incorrect note in Javadoc for a few RandomGenerator methods Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/20152 From duke at openjdk.org Tue Jul 23 09:05:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 09:05:31 GMT Subject: RFR: 8336856: Optimize String Concat In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 14:27:39 GMT, Chen Liang wrote: > For the question [here](https://github.com/openjdk/jdk/pull/20253#issuecomment-2242267516): > > 1. A sample of loading an otherwise inaccessible method handle from class data: https://github.com/openjdk/jdk/blob/c3226aaeb810521257e961be5763552c86ee5651/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L517-L518 > 2. In offline discussion with Claes, we are thinking of generating direct bytecode to avoid the overhead of creating a lot of intermediate method handles. The ClassData of LambdaMetafactory has only one MethodHandle, but multiple MethodHandles are needed here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2244656110 From sundar at openjdk.org Tue Jul 23 09:42:52 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Tue, 23 Jul 2024 09:42:52 GMT Subject: RFR: 8204582: Extra spaces in jlink documentation make it incorrect. [v2] In-Reply-To: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> References: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> Message-ID: > removed extra whitespaces Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: removed space in --limit-modules option as well (review comment) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20292/files - new: https://git.openjdk.org/jdk/pull/20292/files/fca7463c..0230e181 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20292&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20292&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20292.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20292/head:pull/20292 PR: https://git.openjdk.org/jdk/pull/20292 From kevinw at openjdk.org Tue Jul 23 10:18:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Jul 2024 10:18:38 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates [v2] In-Reply-To: References: Message-ID: <4woQIJpyoBiLAqvN91yvDmPnC3kg6UyWqrYg9RzkHxk=.fd3a39f8-3101-4b46-95cc-fb14cef83312@github.com> On Fri, 19 Jul 2024 16:59:54 GMT, Alan Bateman wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > Alan Bateman 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 > - Fix typo in comment, missing copyright update, test nits > - Merge > - Drop JLA updates for this update > - Merge > - Merge > - Update copyright headers > - Initial commit The JMX/ThreadMXBean test updates look good to me. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20143#pullrequestreview-2193566771 From duke at openjdk.org Tue Jul 23 10:19:47 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 10:19:47 GMT Subject: RFR: 8336856: Optimize String Concat [v4] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - reduce change & refactor - fix TRUSTED not work ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/94709c0d..750123a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=02-03 Stats: 43 lines in 5 files changed: 17 ins; 17 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From alanb at openjdk.org Tue Jul 23 10:38:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Jul 2024 10:38:31 GMT Subject: RFR: 8204582: Extra spaces in jlink documentation make it incorrect. [v2] In-Reply-To: References: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> Message-ID: On Tue, 23 Jul 2024 09:42:52 GMT, Athijegannathan Sundararajan wrote: >> removed extra whitespaces > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > removed space in --limit-modules option as well (review comment) Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20292#pullrequestreview-2193606376 From redestad at openjdk.org Tue Jul 23 11:53:38 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 23 Jul 2024 11:53:38 GMT Subject: RFR: 8335182: Consolidate and streamline String concat code shapes [v3] In-Reply-To: References: Message-ID: <_T01ceorVZswQ5-AmwqH7fA5O83M9uNUQEnXmxPwLJ8=.926d95c5-1f6b-488e-9ae7-dbcea66acab1@github.com> On Tue, 9 Jul 2024 21:16:33 GMT, Claes Redestad wrote: >> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape >> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. >> >> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements): >> >> >> Name Cnt Base Error Test Error Unit Change >> StringConcat.concat13String 50 66.380 ? 0.189 53.017 ? 0.241 ns/op 1.25x (p = 0.000*) >> StringConcat.concat4String 50 13.620 ? 0.053 12.382 ? 0.089 ns/op 1.10x (p = 0.000*) >> StringConcat.concat6String 50 17.168 ? 0.070 16.046 ? 0.064 ns/op 1.07x (p = 0.000*) >> StringConcat.concatConst2String 50 9.820 ? 0.081 8.158 ? 0.041 ns/op 1.20x (p = 0.000*) >> StringConcat.concatConst4String 50 14.938 ? 0.124 12.800 ? 0.049 ns/op 1.17x (p = 0.000*) >> StringConcat.concatConst6Object 50 56.115 ? 0.288 54.046 ? 0.214 ns/op 1.04x (p = 0.000*) >> StringConcat.concatConst6String 50 19.032 ? 0.073 16.213 ? 0.093 ns/op 1.17x (p = 0.000*) >> StringConcat.concatConstBoolByte 50 8.486 ? 0.066 8.556 ? 0.050 ns/op 0.99x (p = 0.004*) >> StringConcat.concatConstInt 50 8.942 ? 0.052 7.677 ? 0.029 ns/op 1.16x (p = 0.000*) >> StringConcat.concatConstIntConstInt 50 12.883 ? 0.070 12.431 ? 0.070 ns/op 1.04x (p = 0.000*) >> StringConcat.concatConstString 50 7.523 ? 0.050 7.486 ? 0.044 ns/op 1.00x (p = 0.058 ) >> StringConcat.concatConstStringConstInt 50 11.961 ? 0.032 11.699 ? 0.049 ns/op 1.02x (p = 0.000*) >> StringConcat.concatEmptyConstInt 50 7.778 ? 0.038 7.723 ? 0.037 ns/op 1.01x (p = 0.000*) >> StringConcat.concatEmptyConstString 50 3.506 ? 0.026 3.505 ? 0.015 ns/op 1.00x (p = 0.930 ) >> StringConcat.concatEmptyLeft 50 3.573 ? 0.075 3.518 ? 0.057 ns/op 1.02x (p = 0.044 ) >> StringConcat.concatEmptyRight 50 3.713 ? 0.049 3.622 ? 0.053 ns/op 1.02x (p = 0.000*) >> StringConcat.concatMethodConstString 50 7.418 ? 0.030 7.478 ? 0.066 ns/op 0.99x (p... > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Excess blankspace Thanks for reviews and patience - went on vacation for a couple of weeks and didn't want to integrate this and leave any bug trail for others to deal with. Back part-time for a while so let's go! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19927#issuecomment-2245022856 From redestad at openjdk.org Tue Jul 23 11:53:39 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 23 Jul 2024 11:53:39 GMT Subject: Integrated: 8335182: Consolidate and streamline String concat code shapes In-Reply-To: References: Message-ID: On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad wrote: > This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape > (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions. > > Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements): > > > Name Cnt Base Error Test Error Unit Change > StringConcat.concat13String 50 66.380 ? 0.189 53.017 ? 0.241 ns/op 1.25x (p = 0.000*) > StringConcat.concat4String 50 13.620 ? 0.053 12.382 ? 0.089 ns/op 1.10x (p = 0.000*) > StringConcat.concat6String 50 17.168 ? 0.070 16.046 ? 0.064 ns/op 1.07x (p = 0.000*) > StringConcat.concatConst2String 50 9.820 ? 0.081 8.158 ? 0.041 ns/op 1.20x (p = 0.000*) > StringConcat.concatConst4String 50 14.938 ? 0.124 12.800 ? 0.049 ns/op 1.17x (p = 0.000*) > StringConcat.concatConst6Object 50 56.115 ? 0.288 54.046 ? 0.214 ns/op 1.04x (p = 0.000*) > StringConcat.concatConst6String 50 19.032 ? 0.073 16.213 ? 0.093 ns/op 1.17x (p = 0.000*) > StringConcat.concatConstBoolByte 50 8.486 ? 0.066 8.556 ? 0.050 ns/op 0.99x (p = 0.004*) > StringConcat.concatConstInt 50 8.942 ? 0.052 7.677 ? 0.029 ns/op 1.16x (p = 0.000*) > StringConcat.concatConstIntConstInt 50 12.883 ? 0.070 12.431 ? 0.070 ns/op 1.04x (p = 0.000*) > StringConcat.concatConstString 50 7.523 ? 0.050 7.486 ? 0.044 ns/op 1.00x (p = 0.058 ) > StringConcat.concatConstStringConstInt 50 11.961 ? 0.032 11.699 ? 0.049 ns/op 1.02x (p = 0.000*) > StringConcat.concatEmptyConstInt 50 7.778 ? 0.038 7.723 ? 0.037 ns/op 1.01x (p = 0.000*) > StringConcat.concatEmptyConstString 50 3.506 ? 0.026 3.505 ? 0.015 ns/op 1.00x (p = 0.930 ) > StringConcat.concatEmptyLeft 50 3.573 ? 0.075 3.518 ? 0.057 ns/op 1.02x (p = 0.044 ) > StringConcat.concatEmptyRight 50 3.713 ? 0.049 3.622 ? 0.053 ns/op 1.02x (p = 0.000*) > StringConcat.concatMethodConstString 50 7.418 ? 0.030 7.478 ? 0.066 ns/op 0.99x (p = 0.005*) > StringConcat.concatMix4String ... This pull request has now been integrated. Changeset: e83b4b23 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/e83b4b236eca48d0b75094006f7f888398194fe4 Stats: 566 lines in 6 files changed: 412 ins; 114 del; 40 mod 8335182: Consolidate and streamline String concat code shapes Reviewed-by: liach, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/19927 From redestad at openjdk.org Tue Jul 23 12:08:33 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 23 Jul 2024 12:08:33 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:42:09 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments This change seems reasonable, and we will need the `newArray(int)` method in future work. This patch dials back on the idea that `simpleConcat` is an "explainer" for what `StringConcatFactory` is doing, but as it was already imprecise in that regard we should favor simplicity and performance here. src/java.base/share/classes/java/lang/String.java line 2991: > 2989: } > 2990: if (isEmpty()) { > 2991: return str; This case should probably be reflected more precisely in the specification, or do `return new String(str);` to avoid changing semantics for this corner-case. ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2193780530 PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1687937671 From liach at openjdk.org Tue Jul 23 12:14:34 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 12:14:34 GMT Subject: RFR: 8335939: Hide element writing across the ClassFile API [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 05:40:05 GMT, Chen Liang wrote: >> `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) >> >> Removal details: >> - `LocalVariable/LocalVariableType.writeTo` >> - `WritableElement` >> - In `BufWriter`: >> - `writeList(List)` >> - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` >> - `writeBytes(BufWriter other)` >> - `ClassReader.compare`: Avoid reading from `BufWriter` >> >> Future implementation cleanup out of scope of this patch: >> - Annotation writing can be upgraded and move away from `Util.Writable` >> - The writing of CP indices and attributes can move to their dedicated methods >> - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix test compile errors Thanks for the reviews! Tier 1 to 3 passes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20205#issuecomment-2245075547 From liach at openjdk.org Tue Jul 23 12:14:36 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 12:14:36 GMT Subject: Integrated: 8335939: Hide element writing across the ClassFile API In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 23:50:17 GMT, Chen Liang wrote: > `WritableElement` has always been one of the biggest peculiarities of ClassFile API: it exposes element writing yet has no corresponding reading ability exposed. Its existence creates a lot of API noise, increasing maintenance cost in the long run. (This is an iceberg whose tip was exposed in #14705) > > Removal details: > - `LocalVariable/LocalVariableType.writeTo` > - `WritableElement` > - In `BufWriter`: > - `writeList(List)` > - `writeListIndices`: Hidden as we are not exposing `BoundAttribute.readEntryList` > - `writeBytes(BufWriter other)` > - `ClassReader.compare`: Avoid reading from `BufWriter` > > Future implementation cleanup out of scope of this patch: > - Annotation writing can be upgraded and move away from `Util.Writable` > - The writing of CP indices and attributes can move to their dedicated methods > - reading of entry list can pair up with writing of entry list in ClassReader/BufWriter in future addition This pull request has now been integrated. Changeset: a2a236f9 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/a2a236f9041083e4b8f11e068da0031dd5f52c2b Stats: 461 lines in 50 files changed: 101 ins; 198 del; 162 mod 8335939: Hide element writing across the ClassFile API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20205 From duke at openjdk.org Tue Jul 23 12:16:00 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 12:16:00 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v6] In-Reply-To: References: Message-ID: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - merge from master - Merge remote-tracking branch 'upstream/master' into optim_simple_concat_202407 # Conflicts: # src/java.base/share/classes/java/lang/StringConcatHelper.java - Update src/java.base/share/classes/java/lang/String.java Co-authored-by: Chen Liang - add comments - handle null argument - extract a common doConcat handling both non-empty strings - share newArray - copyright 2024 - optimize String.concat ------------- Changes: https://git.openjdk.org/jdk/pull/20253/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=05 Stats: 36 lines in 2 files changed: 20 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/20253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20253/head:pull/20253 PR: https://git.openjdk.org/jdk/pull/20253 From liach at openjdk.org Tue Jul 23 12:16:01 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 12:16:01 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 12:01:51 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/lang/String.java >> >> Co-authored-by: Chen Liang >> - add comments > > src/java.base/share/classes/java/lang/String.java line 2991: > >> 2989: } >> 2990: if (isEmpty()) { >> 2991: return str; > > This case should probably be reflected more precisely in the specification, or do `return new String(str);` to avoid changing semantics for this corner-case. The spec for concat only asked for equal representation instead of the existence of a new identity. Thus this should be fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1687954730 From duke at openjdk.org Tue Jul 23 12:17:35 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 12:17:35 GMT Subject: RFR: 8336856: Optimize String Concat [v4] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 10:19:47 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - reduce change & refactor > - fix TRUSTED not work The bytecode-spinning-based implementation is working, except for one test (java/lang/String/concat/WithSecurityManager.java) which fails. I have verified that this test fails in the generate branch, and the reason needs to be analyzed. Now: 1. Keep the implementation of unaryConcat and simpleConcat, which is the same as before in simple scenarios. 2. When the number of parameters is less than HIGH_ARITY_THRESHOLD, use the acceptInlineCopy implementation based on bytecode-spinning, and when the number of parameters is greater than HIGH_ARITY_THRESHOLD, use the original generate path 3. Access private methods through the TRUSTED Mode of MethodHandles.Lookup.IMPL_LOOKUP. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2245083720 From duke at openjdk.org Tue Jul 23 12:22:57 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 12:22:57 GMT Subject: RFR: 8336856: Optimize String Concat [v5] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge remote-tracking branch 'origin/optim_simple_concat_202407' into optim_concat_factory_202407 # Conflicts: # src/java.base/share/classes/java/lang/StringConcatHelper.java # src/java.base/share/classes/java/lang/System.java # src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java - reduce change & refactor - fix TRUSTED not work - non-MH-based implementation - non-MH-based implementation - optimize string concat ------------- Changes: https://git.openjdk.org/jdk/pull/20273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=04 Stats: 923 lines in 6 files changed: 247 ins; 598 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From sundar at openjdk.org Tue Jul 23 12:25:37 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Tue, 23 Jul 2024 12:25:37 GMT Subject: Integrated: 8204582: Extra spaces in jlink documentation make it incorrect. In-Reply-To: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> References: <2M6LLfJdCaznumP5Kx-0IqO-TwRgw62dNxYTWXPb6DE=.5e718dc6-cdf3-4cc8-b526-eb5948ed92c3@github.com> Message-ID: <2xdlZMt22QrSpqyvk99V1qGN9odo_qAlooopP_i0OoI=.b6472e83-be60-42c9-a850-9e08746549ef@github.com> On Tue, 23 Jul 2024 04:55:16 GMT, Athijegannathan Sundararajan wrote: > removed extra whitespaces This pull request has now been integrated. Changeset: 0e555b5d Author: Athijegannathan Sundararajan URL: https://git.openjdk.org/jdk/commit/0e555b5ded819cc3b363673320dc848c321861ce Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8204582: Extra spaces in jlink documentation make it incorrect. Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/20292 From liach at openjdk.org Tue Jul 23 12:37:35 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 12:37:35 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v6] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 12:16:00 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - merge from master > - Merge remote-tracking branch 'upstream/master' into optim_simple_concat_202407 > > # Conflicts: > # src/java.base/share/classes/java/lang/StringConcatHelper.java > - Update src/java.base/share/classes/java/lang/String.java > > Co-authored-by: Chen Liang > - add comments > - handle null argument > - extract a common doConcat handling both non-empty strings > - share newArray > - copyright 2024 > - optimize String.concat Merge conflict fix looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2193860085 From coleenp at openjdk.org Tue Jul 23 12:37:42 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 12:37:42 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: <7MDa4Z7FtvI5TG3rARV50PQckm3MSqOzBefku_lFwyc=.ead08ce2-1850-4803-a2eb-bd22cdcdd221@github.com> On Mon, 15 Jul 2024 00:44:02 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 1090: >> >>> 1088: >>> 1089: // Step 2 >>> 1090: // If we were to use wait() instead of waitUninterruptibly() then >> >> This is a nice correction (even though, the actual call below is wait_uninterruptibly() ;-) ), but seems totally unrelated. > > I was thinking it was referring to `ObjectSynchronizer::waitUninterruptibly` added the same commit as the comment b3bf31a0a08da679ec2fd21613243fb17b1135a9 git backout restored the old wrong comment. We should fix this separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1687985648 From redestad at openjdk.org Tue Jul 23 12:40:35 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 23 Jul 2024 12:40:35 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 12:12:41 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/String.java line 2991: >> >>> 2989: } >>> 2990: if (isEmpty()) { >>> 2991: return str; >> >> This case should probably be reflected more precisely in the specification, or do `return new String(str);` to avoid changing semantics for this corner-case. > > The spec for concat only asked for equal representation instead of the existence of a new identity. Thus this should be fine. Yes, this isn't beholden to JLS 15.18.1, and it's already specified that `foo.concat("")` returns `foo` - so why shouldn't `"".concat(foo)` return `foo`? But still it's an observable semantic change so some care needs to be taken - possibly even a CSR is warranted. Doing `return new String(str)` to retain behavior avoids that headache for a fringe case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1687990148 From duke at openjdk.org Tue Jul 23 12:56:07 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 12:56:07 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: References: Message-ID: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: reduce change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20253/files - new: https://git.openjdk.org/jdk/pull/20253/files/61d6b644..a2be39af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20253&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20253/head:pull/20253 PR: https://git.openjdk.org/jdk/pull/20253 From duke at openjdk.org Tue Jul 23 12:56:07 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 12:56:07 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 12:37:40 GMT, Claes Redestad wrote: >> The spec for concat only asked for equal representation instead of the existence of a new identity. Thus this should be fine. > > Yes, this isn't beholden to JLS 15.18.1, and it's already specified that `foo.concat("")` returns `foo` - so why shouldn't `"".concat(foo)` return `foo`? But still it's an observable semantic change so some care needs to be taken - possibly even a CSR is warranted. Doing `return new String(str)` to retain behavior avoids that headache for a fringe case. Adding isEmpty check is not related to this PR and should be a new PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1688007455 From duke at openjdk.org Tue Jul 23 12:57:52 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 12:57:52 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v15] In-Reply-To: References: Message-ID: > After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. > > This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: replace unsafe with putChar ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19626/files - new: https://git.openjdk.org/jdk/pull/19626/files/7563577c..9d9c8eb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=13-14 Stats: 27 lines in 1 file changed: 0 ins; 18 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/19626.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626 PR: https://git.openjdk.org/jdk/pull/19626 From redestad at openjdk.org Tue Jul 23 13:09:33 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 23 Jul 2024 13:09:33 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> References: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> Message-ID: On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > reduce change Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2193939149 From redestad at openjdk.org Tue Jul 23 13:09:34 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 23 Jul 2024 13:09:34 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 12:49:52 GMT, Shaojin Wen wrote: >> Yes, this isn't beholden to JLS 15.18.1, and it's already specified that `foo.concat("")` returns `foo` - so why shouldn't `"".concat(foo)` return `foo`? But still it's an observable semantic change so some care needs to be taken - possibly even a CSR is warranted. Doing `return new String(str)` to retain behavior avoids that headache for a fringe case. > > Adding isEmpty check is not related to this PR and should be a new PR. Thanks. Removing this check will make the `"".append(foo)` edge case a little bit slower (likely inconsequential), but removes a branch and might thus even be an optimization in the common case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20253#discussion_r1688032897 From liach at openjdk.org Tue Jul 23 13:17:32 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 13:17:32 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> References: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> Message-ID: On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > reduce change Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2193958048 From jkratochvil at openjdk.org Tue Jul 23 13:22:54 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 23 Jul 2024 13:22:54 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v16] In-Reply-To: References: Message-ID: > The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 117 commits: - Fix testcase compatibility with Alpine Linux 3.20.1 - Merge branch 'master' into master-cgroup - Unify 4 copies of adjust_controller() - Fix a needless whitespace change - Merge branch 'master-jdk-8322420_cgroup_hierarchy_walk_init-test' into master-cgroup - +test - Merge branch 'master' into master-jdk-8322420_cgroup_hierarchy_walk_init - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init - 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected - ... and 107 more: https://git.openjdk.org/jdk/compare/aabec4a9...219c343d ------------- Changes: https://git.openjdk.org/jdk/pull/17198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=15 Stats: 561 lines in 10 files changed: 490 ins; 52 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From liach at openjdk.org Tue Jul 23 13:24:37 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 13:24:37 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 21:46:07 GMT, Roger Riggs wrote: >> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/lang/String.java >> >> Co-authored-by: Chen Liang >> - add comments > > I'll take a look at this next week. Please hold off a few hours before integration: I will see if @RogerRiggs has any concerns, and I will run the CI tests for your patch again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2245240546 From liach at openjdk.org Tue Jul 23 13:28:40 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 13:28:40 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v15] In-Reply-To: References: Message-ID: <5QHigWHpug0lKFJajoXsKh_y8TN1AkHxFvnaUIOa51Q=.7f78826a-e6de-429e-a333-baf6dd4ff5dc@github.com> On Tue, 23 Jul 2024 12:57:52 GMT, Shaojin Wen wrote: >> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. >> >> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > replace unsafe with putChar Changes requested by liach (Reviewer). src/java.base/share/classes/java/lang/StringLatin1.java line 832: > 830: static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) { > 831: assert index >= 0 && index + 3 < length(val) : "Trusted caller missed bounds check"; > 832: // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores. `StringLatin1` has no `putChar` method. I think you can just convert this to explicit array stores for the merge store optimization. ------------- PR Review: https://git.openjdk.org/jdk/pull/19626#pullrequestreview-2193985500 PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1688061453 From redestad at openjdk.org Tue Jul 23 13:38:33 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 23 Jul 2024 13:38:33 GMT Subject: RFR: 8336856: Optimize String Concat [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 12:22:57 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'origin/optim_simple_concat_202407' into optim_concat_factory_202407 > > # Conflicts: > # src/java.base/share/classes/java/lang/StringConcatHelper.java > # src/java.base/share/classes/java/lang/System.java > # src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java > - reduce change & refactor > - fix TRUSTED not work > - non-MH-based implementation > - non-MH-based implementation > - optimize string concat While a reasonable start I'd suggest: - adding a flag to switch over to the new implementation and leaving the existing strategy in place initially, then when we have something that is superior in every way we can clean out the old strategy - AFAICT this mimics the `SimpleStringBuilderStrategy` and generates and installs a new class for each expression. This is likely fine for high-arity concatenations which are likely to be one-of-a-kind (the sort of expressions the `SimpleStringBuilderStrategy` was brought back to life for), but could generate a proliferation of classes for low-arity expressions. Instead we probably need to aim for sharing - such shareable classes could be made simpler if we put them in java.lang so that they can link directly with package private methods in `StringConcatHelper` and `String` rather than using trusted `MethodHandles` to cross such boundaries Again: I am working on and have a prototype for this which I aim to present and discuss in two weeks as JVMLS. I appreciate the effort here, but I'll need to focus on my talk and prototype for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2245279590 From liach at openjdk.org Tue Jul 23 13:42:36 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 13:42:36 GMT Subject: RFR: 8336856: Optimize String Concat In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 09:02:48 GMT, Shaojin Wen wrote: > The ClassData of LambdaMetafactory has only one MethodHandle, but multiple MethodHandles are needed here. In these cases, we pass a `List.of(methodHandles)`, and call extra `.constantInstruction(index).invokeinterface(CD_List, "get", MTD_Object_int)` to retrieve them. Note that you can also replace the dynamic constant `BSM_CLASS_DATA` with `BSM_CLASS_DATA_AT`, but `classDataAt` uses unnecessary constant pool entries and is really only recommended for passing to boostrap method arguments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2245288491 From duke at openjdk.org Tue Jul 23 13:44:36 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 13:44:36 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v15] In-Reply-To: <5QHigWHpug0lKFJajoXsKh_y8TN1AkHxFvnaUIOa51Q=.7f78826a-e6de-429e-a333-baf6dd4ff5dc@github.com> References: <5QHigWHpug0lKFJajoXsKh_y8TN1AkHxFvnaUIOa51Q=.7f78826a-e6de-429e-a333-baf6dd4ff5dc@github.com> Message-ID: On Tue, 23 Jul 2024 13:25:16 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> replace unsafe with putChar > > src/java.base/share/classes/java/lang/StringLatin1.java line 832: > >> 830: static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) { >> 831: assert index >= 0 && index + 3 < length(val) : "Trusted caller missed bounds check"; >> 832: // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores. > > `StringLatin1` has no `putChar` method. I think you can just convert this to explicit array stores for the merge store optimization. explicit array stores has the overhead of boundary checking. If putCharsAt of StringLatin1 is not implemented based on Unsafe, the performance will be worse than StringUTF16. Of course, this is a common problem. StringUTF16.putChar is equivalent to Unsafe.putChar, without boundary checking. I found in many test scenarios that the UTF16 version performs better than the StringLatin1 version. We may need to change some StringLatin1 related implementations to use Unsafe, otherwise users will turn off COMPACT_STRINGS to improve performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1688091826 From liach at openjdk.org Tue Jul 23 13:51:41 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 13:51:41 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v15] In-Reply-To: References: <5QHigWHpug0lKFJajoXsKh_y8TN1AkHxFvnaUIOa51Q=.7f78826a-e6de-429e-a333-baf6dd4ff5dc@github.com> Message-ID: <1U6SxE7Px2sJkm8bMXuMPXNvpSSMYWxhlc9pLZGlYXY=.ac3af497-ccf2-46ce-8908-d924da8754a1@github.com> On Tue, 23 Jul 2024 13:42:20 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/StringLatin1.java line 832: >> >>> 830: static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) { >>> 831: assert index >= 0 && index + 3 < length(val) : "Trusted caller missed bounds check"; >>> 832: // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores. >> >> `StringLatin1` has no `putChar` method. I think you can just convert this to explicit array stores for the merge store optimization. > > explicit array stores has the overhead of boundary checking. If putCharsAt of StringLatin1 is not implemented based on Unsafe, the performance will be worse than StringUTF16. > > Of course, this is a common problem. StringUTF16.putChar is equivalent to Unsafe.putChar, without boundary checking. I found in many test scenarios that the UTF16 version performs better than the StringLatin1 version. > > We may need to change some StringLatin1 related implementations to use Unsafe, otherwise users will turn off COMPACT_STRINGS to improve performance. Thank you for telling what the blocking issue is here. Does C2 not merge the bound checks when it does the merge stores? Interesting, and I think a fix from their side should be the way to go. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1688102742 From rriggs at openjdk.org Tue Jul 23 14:36:36 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 23 Jul 2024 14:36:36 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> References: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> Message-ID: On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > reduce change looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2194181255 From rgiulietti at openjdk.org Tue Jul 23 14:45:38 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 23 Jul 2024 14:45:38 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 17:22:50 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Conditions' order reversed in MBI.ulongSqrt() AFAIU, in the Bertot, Magaud, Zimmermann paper there is just one "denormalization" step in the wrapper, before returning the final result to the client. Here, there seems to be a denormalization before returning from each recursive invocation with a length > 2 in `sqrtRemZimmermann()`, and one final denormalization in `sqrtRem()`. If my understanding is correct, I wonder if the scheme on the paper has been considered as an alternative, and if so, what the advantages of this PR code are. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2245451597 From duke at openjdk.org Tue Jul 23 14:47:48 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 14:47:48 GMT Subject: RFR: 8336856: Optimize String Concat [v6] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: 1. reduce change 2. add flag GENERATE_INLINE_COPY ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/54744017..4c2a96fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=04-05 Stats: 907 lines in 5 files changed: 761 ins; 35 del; 111 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From duke at openjdk.org Tue Jul 23 15:03:36 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 23 Jul 2024 15:03:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 14:42:36 GMT, Raffaello Giulietti wrote: > AFAIU, in the Bertot, Magaud, Zimmermann paper there is just one "denormalization" step in the wrapper, before returning the final result to the client. > > Here, there seems to be a denormalization before returning from each recursive invocation with a length > 2 in `sqrtRemZimmermann()`, and one final denormalization in `sqrtRem()`. > > If my understanding is correct, I wonder if the scheme on the paper has been considered as an alternative, and if so, what the advantages of this PR code are. @rgiulietti As I had already pointed out previously, the pseudocode in the paper assumes that the input is normalized, but the argument provided in the recursive invocation of the pseudocode could be not normalized, therefore actually also the algorithm in the paper requires that normalization must be performed at each invocation. The normalization performed in `sqrtRem()`, together with that in `sqrtRemZimmermann()`, guarantees that the assumpion L/4 <= N' in the paper's pseudocode is satisfied (in the paper of Bertot, Magaud, Zimmermann the assuption is incorrectly reported as L/4 < N', but in the original paper of Zimmermann is a_3 >= b/4 correctly). ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2245497277 From duke at openjdk.org Tue Jul 23 15:09:47 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 15:09:47 GMT Subject: RFR: 8336856: Optimize String Concat [v7] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix WithSecurityManager error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/4c2a96fc..72d31662 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=05-06 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From rgiulietti at openjdk.org Tue Jul 23 15:19:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 23 Jul 2024 15:19:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 17:22:50 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Conditions' order reversed in MBI.ulongSqrt() AFAIU, the wrapper performs the normalization, invokes the core algorithm, and does the denormalization just before returning the final result. There's no mention that normalization/denormalization need to be performed at each recursive call. The C code in ?5.1 assumes a normalized input and, as far as I can see, does not perform any denormalization. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2245535146 From rgiulietti at openjdk.org Tue Jul 23 15:22:36 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 23 Jul 2024 15:22:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: <53ftvg3_BujXQwi45uB2vWi5cvUU4fPptDhQSu-hzyU=.459cc7cb-9aa7-4662-8519-09e70ff50966@github.com> On Thu, 18 Jul 2024 17:22:50 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Conditions' order reversed in MBI.ulongSqrt() To clarify, the PR's code seems correct, but I wonder if it can be made simpler. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2245543222 From liach at openjdk.org Tue Jul 23 15:43:42 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 15:43:42 GMT Subject: RFR: 8336927: Missing equals and hashCode in java.lang.classfile.Annotation [v2] In-Reply-To: References: Message-ID: > Convert `AnnotationImpl` to a record so it comes with proper `equals` and `hashCode` implementations. This also fixes the comparison for annotation-valued annotation element values. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/anno-hash-equals - 8336927: Missing equals and hashCode in java.lang.classfile.Annotation ------------- Changes: https://git.openjdk.org/jdk/pull/20291/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20291&range=01 Stats: 42 lines in 2 files changed: 23 ins; 14 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20291.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20291/head:pull/20291 PR: https://git.openjdk.org/jdk/pull/20291 From liach at openjdk.org Tue Jul 23 15:43:58 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 15:43:58 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v3] In-Reply-To: References: Message-ID: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - SealedGraph now redundant - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation ------------- Changes: https://git.openjdk.org/jdk/pull/20247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=02 Stats: 245 lines in 20 files changed: 81 ins; 115 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From liach at openjdk.org Tue Jul 23 15:43:58 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 15:43:58 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v2] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:42:06 GMT, Chen Liang wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. Unfortunately had to force push: the old commit histories now cause conflicts, so I had squashed them into one and applied onto the latest master. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2245592977 From liach at openjdk.org Tue Jul 23 15:56:33 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 15:56:33 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> References: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> Message-ID: On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > reduce change Tier 1-3 tests pass. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2245625185 From duke at openjdk.org Tue Jul 23 16:05:36 2024 From: duke at openjdk.org (fabioromano1) Date: Tue, 23 Jul 2024 16:05:36 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 15:16:27 GMT, Raffaello Giulietti wrote: > AFAIU, the wrapper performs the normalization, invokes the core algorithm, and does the denormalization just before returning the final result. There's no mention that normalization/denormalization need to be performed at each recursive call. The C code in ?5.1 assumes a normalized input and, as far as I can see, does not perform any denormalization. @rgiulietti In the C code in ?5.1, the length of N is assumed to be `2*n`. The value passed in the recursive invocation is `h = n - l`, with `l = n / 2`. Therefore, if ` n` is odd, then `h == (n / 2) + 1`, so the normalization is implicitly performed in the lines 10-11. I don't know the reason why the unnormalization is not performed, but in theory, according to ?3.2, it should be carried out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2245645051 From kdriver at openjdk.org Tue Jul 23 16:36:06 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 16:36:06 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) Message-ID: Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). ------------- Commit messages: - refactor to change getInstance parameter type and deriveX methods parameter type - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - code review comment - minor code-review comments - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - Merge remote-tracking branch 'origin/master' into kdf-jep-wip - ... and 98 more: https://git.openjdk.org/jdk/compare/c740e1e3...12f71f86 Changes: https://git.openjdk.org/jdk/pull/20301/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331008 Stats: 2314 lines in 15 files changed: 2313 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From kdriver at openjdk.org Tue Jul 23 16:53:14 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 16:53:14 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v2] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 102 new commits since the last revision: - add back extra comma - remove from Source.java - refactor to change getInstance parameter type and deriveX methods parameter type - code review comment - minor code-review comments - javadoc formatting - javadoc formatting - remove unused declared exception in impls - throw a ProviderException instead of "eating" an NSAE for Mac - fix edge-case in consolidateKeyMaterial - ... and 92 more: https://git.openjdk.org/jdk/compare/12f71f86...ca63c111 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/12f71f86..ca63c111 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From kdriver at openjdk.org Tue Jul 23 17:09:10 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 17:09:10 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v3] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - refactor to change getInstance parameter type and deriveX methods parameter type - Provide a KDF API and accompanying implementation of RFC 5869. Squashing previous commits that were approved/reviewed in the JDK 23 timeframe. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/ca63c111..26cffbf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From jlu at openjdk.org Tue Jul 23 17:32:59 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 23 Jul 2024 17:32:59 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes Message-ID: As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. As this is simply cleanup, there is no regression test added. ------------- Commit messages: - add null case to restore IAE behavior - init Changes: https://git.openjdk.org/jdk/pull/20302/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336847 Stats: 142 lines in 3 files changed: 0 ins; 29 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/20302.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20302/head:pull/20302 PR: https://git.openjdk.org/jdk/pull/20302 From jlu at openjdk.org Tue Jul 23 17:33:00 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 23 Jul 2024 17:33:00 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes In-Reply-To: References: Message-ID: <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com> On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu wrote: > As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. > > As this is simply cleanup, there is no regression test added. src/java.base/share/classes/java/text/DecimalFormat.java line 1797: > 1795: case Long l -> digitList.set(isNegative, l, maxDigits); > 1796: case BigInteger bi -> digitList.set(isNegative, bi, maxDigits); > 1797: default -> {} // do nothing default case could also be thrown `AssertionError` if preferred. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688449249 From liach at openjdk.org Tue Jul 23 17:53:33 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 17:53:33 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes In-Reply-To: References: Message-ID: <18zx-9IHjZjtxns_Jsevp_L2uaM0Q9Fnr_vVEp1CuAE=.f26493f2-7bf8-42a9-a451-134c7b469e54@github.com> On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu wrote: > As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. > > As this is simply cleanup, there is no regression test added. Appears to be an equivalent migration by naked eye. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2194666920 From jlu at openjdk.org Tue Jul 23 18:00:41 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 23 Jul 2024 18:00:41 GMT Subject: RFR: 8336787: Examine java.text.Format API for implSpec usage Message-ID: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com> As discussed in https://bugs.openjdk.org/browse/JDK-8335834, there are occurrences in the java.text.Format API that would benefit from the implSpec (and apiNote) tag. This is a doc-only change, and a CSR has also been filed. I did not think "_Subclasses that support fields should override this and create an ..._" sounded right under the `implSpec` tag, and moved it to an `apiNote` tag. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/20303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336787 Stats: 11 lines in 1 file changed: 5 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20303/head:pull/20303 PR: https://git.openjdk.org/jdk/pull/20303 From liach at openjdk.org Tue Jul 23 18:00:41 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 18:00:41 GMT Subject: RFR: 8336787: Examine java.text.Format API for implSpec usage In-Reply-To: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com> References: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com> Message-ID: On Tue, 23 Jul 2024 17:51:04 GMT, Justin Lu wrote: > As discussed in https://bugs.openjdk.org/browse/JDK-8335834, there are occurrences in the java.text.Format API that would benefit from the implSpec (and apiNote) tag. > > This is a doc-only change, and a CSR has also been filed. > > I did not think "_Subclasses that support fields should override this and create an ..._" sounded right under the `implSpec` tag, and moved it to an `apiNote` tag. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20303#pullrequestreview-2194680165 From naoto at openjdk.org Tue Jul 23 18:07:31 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 23 Jul 2024 18:07:31 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes In-Reply-To: <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com> References: <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com> Message-ID: On Tue, 23 Jul 2024 17:29:10 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. >> >> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). > > src/java.base/share/classes/java/text/DecimalFormat.java line 1797: > >> 1795: case Long l -> digitList.set(isNegative, l, maxDigits); >> 1796: case BigInteger bi -> digitList.set(isNegative, bi, maxDigits); >> 1797: default -> {} // do nothing > > default case could also be thrown `AssertionError` if preferred. Or a simple `assert` statement, as throwing an Error could change the behavior ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688492608 From jlu at openjdk.org Tue Jul 23 18:32:31 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 23 Jul 2024 18:32:31 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 22:10:07 GMT, Naoto Sato wrote: > This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20285#pullrequestreview-2194745589 From jlu at openjdk.org Tue Jul 23 18:36:31 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 23 Jul 2024 18:36:31 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes In-Reply-To: References: <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com> Message-ID: On Tue, 23 Jul 2024 18:04:54 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/DecimalFormat.java line 1797: >> >>> 1795: case Long l -> digitList.set(isNegative, l, maxDigits); >>> 1796: case BigInteger bi -> digitList.set(isNegative, bi, maxDigits); >>> 1797: default -> {} // do nothing >> >> default case could also be thrown `AssertionError` if preferred. > > Or a simple `assert` statement, as throwing an Error could change the behavior Either of the 3 is fine with me. In this case, I think `AssertionError` is harmless, because AFAICT it is internally used by CompactNumberFormat only, and so throwing may prevent potential incorrect uses in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688523933 From naoto at openjdk.org Tue Jul 23 18:51:31 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 23 Jul 2024 18:51:31 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes In-Reply-To: References: <_gTi8uxpBKSkA4VFGtGSl_XaNosTeDV7MquWa0enObE=.0684393a-b0c0-49db-9592-74ee39bc0711@github.com> Message-ID: <1n6UejgupVDVyENpehwB71gcpr_hYKxqiMkukZckF2g=.b7dd82ac-d420-43d4-8fa8-a610d9f938d3@github.com> On Tue, 23 Jul 2024 18:33:47 GMT, Justin Lu wrote: >> Or a simple `assert` statement, as throwing an Error could change the behavior > > Either of the 3 is fine with me. In this case, I think `AssertionError` is harmless, because AFAICT it is internally used by CompactNumberFormat only, and so throwing may prevent potential incorrect uses in the future. OK, then I think I am inclined to use `AssertionError`, assuming `DigitList` is defined to only accept those types. Might want to modify the method description too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1688543808 From naoto at openjdk.org Tue Jul 23 18:59:44 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 23 Jul 2024 18:59:44 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v2] In-Reply-To: References: Message-ID: <5y2jLnXx8D3jLn_qD9weZtgLVKlbRih4RX_a8Gt91Bc=.d56fee9d-7f43-49ed-8ef3-f8e969589fb8@github.com> > This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing a CSR comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20285/files - new: https://git.openjdk.org/jdk/pull/20285/files/bd91aba2..49b894b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20285&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20285&range=00-01 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20285/head:pull/20285 PR: https://git.openjdk.org/jdk/pull/20285 From vlivanov at openjdk.org Tue Jul 23 19:03:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Jul 2024 19:03:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Mon, 22 Jul 2024 14:56:31 GMT, Andrew Haley wrote: >> src/hotspot/share/oops/klass.inline.hpp line 117: >> >>> 115: } >>> 116: >>> 117: inline bool Klass::search_secondary_supers(Klass *k) const { >> >> I see you moved `Klass::search_secondary_supers` in `klass.inline.hpp`, but I'm not sure how it interacts with `Klass::is_subtype_of` (the sole caller) being declared in `klass.hpp`. >> >> Will the inlining still happen if `Klass::is_subtype_of()` callers include `klass.hpp`? > > Presumably this question applies to every function in `klass.inline.hpp`? > Practically everything does `#include "oops/klass.inline.hpp"`. It's inlined in about 120 files, as far as I can see everywhere such queries are made. My confusion arises from the following: * `Klass::is_subtype_of()` is declared in `klass.hpp` * `Klass::is_subtype_of()` calls `Klass::search_secondary_supers()` * `Klass::search_secondary_supers()` is declared in `klass.inline.hpp` * `klass.inline.hpp` includes `klass.hpp` What happens when users include `klass.hpp`, but not `klass.inline.hpp`? How does it affect generated code? I suspect that `Klass::search_secondary_supers()` won't be inlinined in such case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1688559463 From kdriver at openjdk.org Tue Jul 23 19:04:34 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 19:04:34 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v4] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: getter for KDFParameters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/26cffbf8..4fb26325 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=02-03 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From vlivanov at openjdk.org Tue Jul 23 19:09:40 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Jul 2024 19:09:40 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> <7JeIjy2PKvI4EZpDain1vd0dBRlWjgjp42xPeY0bHMs=.fee63987-dd85-486d-b7d3-67e52fdbee6f@github.com> Message-ID: On Mon, 22 Jul 2024 14:00:35 GMT, Andrew Haley wrote: >> Also, `num_extra_slots == 0` check is redundant. > >> Since `secondary_supers` are hashed unconditionally now, is `interfaces->length() <= 1` check still needed? > > I don't think so, no. Our incoming `transitive_interfaces` is formed by concatenating the interface lists of our superclasses and superinterfaces. Right, I forgot the details. It requires us to hash transitive interfaces list first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1688568321 From vlivanov at openjdk.org Tue Jul 23 19:09:41 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Jul 2024 19:09:41 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Mon, 22 Jul 2024 14:16:05 GMT, Andrew Haley wrote: >> src/hotspot/share/oops/klass.cpp line 175: >> >>> 173: if (secondary_supers()->at(i) == k) { >>> 174: if (UseSecondarySupersCache) { >>> 175: ((Klass*)this)->set_secondary_super_cache(k); >> >> Does it make sense to assert `UseSecondarySupersCache` in `Klass::set_secondary_super_cache()`? > > I kinda hate this because we're casting away `const`, which is UB. I think I'd just take it out, but once I do that, I don't think anything sets `_secondary_super_cache`. IMO it's OK if C++ runtime omits `_secondary_super_cache` accesses irrespective of whether `UseSecondarySupersCache` is set or not. I'm fine with addressing it separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1688565818 From coleenp at openjdk.org Tue Jul 23 19:09:43 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:43 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <1ivG4ii0OclIXn9-0Ihh4udD4WUu5Oe64ovWDY1xSJ4=.731721e8-806e-4e34-9ec0-3188b81f9f41@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include I have some suggestions that hopefully you can click on if you agree. Also, some comments. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 67: > 65: } > 66: static void* allocate_node(void* context, size_t size, Value const& value) { > 67: reinterpret_cast(context)->inc_table_count(); Suggestion: reinterpret_cast(context)->inc_items_count(); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 71: > 69: }; > 70: static void free_node(void* context, void* memory, Value const& value) { > 71: reinterpret_cast(context)->dec_table_count(); Suggestion: reinterpret_cast(context)->dec_items_count(); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 125: > 123: }; > 124: > 125: void inc_table_count() { Suggestion: void inc_items_count() { src/hotspot/share/runtime/lightweightSynchronizer.cpp line 126: > 124: > 125: void inc_table_count() { > 126: Atomic::inc(&_table_count); Suggestion: Atomic::inc(&_items_count); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 129: > 127: } > 128: > 129: void dec_table_count() { Suggestion: void dec_items_count() { src/hotspot/share/runtime/lightweightSynchronizer.cpp line 130: > 128: > 129: void dec_table_count() { > 130: Atomic::inc(&_table_count); Suggestion: Atomic::inc(&_items_count); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 134: > 132: > 133: double get_load_factor() { > 134: return (double)_table_count/(double)_table_size; Suggestion: return (double)_items_count/(double)_table_size; ------------- PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2193868194 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688563846 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688563501 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688565196 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688565561 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688565947 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688566411 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688566752 From coleenp at openjdk.org Tue Jul 23 19:09:43 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:43 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: <7MDa4Z7FtvI5TG3rARV50PQckm3MSqOzBefku_lFwyc=.ead08ce2-1850-4803-a2eb-bd22cdcdd221@github.com> References: <7MDa4Z7FtvI5TG3rARV50PQckm3MSqOzBefku_lFwyc=.ead08ce2-1850-4803-a2eb-bd22cdcdd221@github.com> Message-ID: On Tue, 23 Jul 2024 12:34:45 GMT, Coleen Phillimore wrote: >> I was thinking it was referring to `ObjectSynchronizer::waitUninterruptibly` added the same commit as the comment b3bf31a0a08da679ec2fd21613243fb17b1135a9 > > git backout restored the old wrong comment. We should fix this separately. Suggestion: // If we were to use wait() instead of waitInterruptibly() then >> I think I was thinking of the names as a prefix to refer to the `Count of the table` and `Size of the table`. And not the `Number of tables`. But I can see the confusion. >> >> `ConcurrentHashTable` tracks no statistics except for JFR which added some counters directly into the implementation. All statistics are for the users to manage, even if there are helpers for gather these statistics. >> >> The current implementation is based on what we do for the StringTable and SymbolTable > > In the other tables, it's called _items_count and it determines the load_factor for triggering concurrent work. We should rename this field items_count to match, and also since it's consistent. Suggestion: volatile size_t _items_count; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1687990861 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688564267 From coleenp at openjdk.org Tue Jul 23 19:09:45 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:45 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:44:31 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/basicLock.cpp line 37: >> >>> 35: if (mon != nullptr) { >>> 36: mon->print_on(st); >>> 37: } >> >> I am not sure if we wanted to do this, but we know the owner, therefore we could also look-up the OM from the table, and print it. It wouldn't have all that much to do with the BasicLock, though. > > Yeah maybe it is unwanted. Not sure how we should treat these prints of the frames. My thinking was that there is something in the cache, print it. But maybe just treating it as some internal data, maybe print "monitor { }" or similar is better. It seems generally useful to print the monitor in the cache if it's there. I don't think we should do a table search here. I think this looks fine as it is, and might be helpful for debugging if it turns out to be the wrong monitor. >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 80: >> >>> 78: >>> 79: ConcurrentTable* _table; >>> 80: volatile size_t _table_count; >> >> Looks like a misnomer to me. We only have one table, but we do have N entries/nodes. This is counted when new nodes are allocated or old nodes are freed. Consider renaming this to '_entry_count' or '_node_count'? I'm actually a bit surprised if ConcurrentHashTable doesn't already track this... > > I think I was thinking of the names as a prefix to refer to the `Count of the table` and `Size of the table`. And not the `Number of tables`. But I can see the confusion. > > `ConcurrentHashTable` tracks no statistics except for JFR which added some counters directly into the implementation. All statistics are for the users to manage, even if there are helpers for gather these statistics. > > The current implementation is based on what we do for the StringTable and SymbolTable In the other tables, it's called _items_count and it determines the load_factor for triggering concurrent work. We should rename this field items_count to match, and also since it's consistent. >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 159: >> >>> 157: static size_t min_log_size() { >>> 158: // ~= log(AvgMonitorsPerThreadEstimate default) >>> 159: return 10; >> >> Uh wait - are we assuming that threads hold 1024 monitors *on average* ? Isn't this a bit excessive? I would have thought maybe 8 monitors/thread. Yes there are workloads that are bonkers. Or maybe the comment/flag name does not say what I think it says. >> >> Or why not use AvgMonitorsPerThreadEstimate directly? > > Maybe that is resonable. I believe I had that at some point but it had to deal with how to handle extreme values of `AvgMonitorsPerThreadEstimate` as well as what to do when `AvgMonitorsPerThreadEstimate` was disabled `=0`. One 4 / 8 KB allocation seems harmless. > > But this was very arbitrary. This will probably be changed when/if the resizing of the table becomes more synchronised with deflation, allowing for shrinking the table. Shrinking the table is NYI. Maybe we should revisit this initial value then. >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 563: >> >>> 561: assert(locking_thread == current || locking_thread->is_obj_deopt_suspend(), "locking_thread may not run concurrently"); >>> 562: if (_no_safepoint) { >>> 563: ::new (&_nsv) NoSafepointVerifier(); >> >> I'm thinking that it might be easier and cleaner to just re-do what the NoSafepointVerifier does? It just calls thread->inc/dec >> _no_safepoint_count(). > > I wanted to avoid having to add `NoSafepointVerifier` implementation details in the synchroniser code. I guess `ContinuationWrapper` already does this. > > Simply creating a `NoSafepointVerifier` when you expect no safepoint is more obvious to me, shows the intent better. This looks strange to me also, but it's be better than changing the no_safepoint_count directly, since NSV handles when the current thread isn't a JavaThread, so you'd have to duplicate that in this VerifyThreadState code too. NoSafepointVerifier::NoSafepointVerifier() : _thread(Thread::current()) { if (_thread->is_Java_thread()) { JavaThread::cast(_thread)->inc_no_safepoint_count(); } } >> src/hotspot/share/runtime/lightweightSynchronizer.hpp line 68: >> >>> 66: static void exit(oop object, JavaThread* current); >>> 67: >>> 68: static ObjectMonitor* inflate_into_object_header(Thread* current, JavaThread* inflating_thread, oop object, const ObjectSynchronizer::InflateCause cause); >> >> My IDE flags this with a warning 'Parameter 'cause' is const-qualified in the function declaration; const-qualification of parameters only has an effect in function definitions' *shrugs* > > Yeah. The only effect is has is that you cannot reassign the variable. It was the style taken from [synchronizer.hpp](https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.hpp) where all `InflateCause` parameters are const. Do you get this for inflate_fast_locked_object also? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688011833 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688162915 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688378429 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688385921 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688397480 From coleenp at openjdk.org Tue Jul 23 19:09:47 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:47 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 06:35:34 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/share/runtime/basicLock.hpp line 44: > >> 42: // a sentinel zero value indicating a recursive stack-lock. >> 43: // * For LM_LIGHTWEIGHT >> 44: // Used as a cache the ObjectMonitor* used when locking. Must either > > The first sentence doesn't read correctly. Suggestion: // Used as a cache of the ObjectMonitor* used when locking. Must either > src/hotspot/share/runtime/deoptimization.cpp line 1641: > >> 1639: assert(fr.is_deoptimized_frame(), "frame must be scheduled for deoptimization"); >> 1640: if (LockingMode == LM_LEGACY) { >> 1641: mon_info->lock()->set_displaced_header(markWord::unused_mark()); > > In the existing code how is this restricted to the LM_LEGACY case?? It appears to be unconditional which suggests you are changing the non-UOMT LM_LIGHTWEIGHT logic. ?? Only legacy locking uses the displaced header, I believe, which isn't clear in this code at all. This seems like a fix. We should probably assert that only legacy locking uses this field as a displaced header. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62: > >> 60: class ObjectMonitorWorld : public CHeapObj { >> 61: struct Config { >> 62: using Value = ObjectMonitor*; > > Does this alias really help? We don't state the type that many times and it looks odd to end up with a mix of `Value` and `ObjectMonitor*` in the same code. This alias is present in the other CHT implementations, alas as a typedef in StringTable and SymbolTable so this follows the pattern and allows cut/paste of the allocate_node, get_hash, and other functions. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102: > >> 100: assert(*value != nullptr, "must be"); >> 101: return (*value)->object_is_cleared(); >> 102: } > > The `is_dead` functions seem oddly placed given they do not relate to the object stored in the wrapper. Why are they here? And what is the difference between `object_is_cleared` and `object_is_dead` (as used by `LookupMonitor`) ? This is a good question. When we look up the Monitor, we don't want to find any that the GC has marked dead, so that's why we call object_is_dead. When we look up with the object to find the Monitor, the object won't be dead (since we're using it to look up). But we don't want to find one that we've cleared because the Monitor was deflated? I don't see where we would clear it though. We clear the WeakHandle in the destructor after the Monitor has been removed from the table. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105: > >> 103: }; >> 104: >> 105: class LookupMonitor : public StackObj { > > I'm not understanding why we need this little wrapper class. It's a two way lookup. The plain Lookup class is used to lookup the Monitor given the object. This LookupMonitor class is used to lookup the object given the Monitor. The CHT takes these wrapper classes. Maybe we should rename LookupObject to be more clear? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688013308 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688041218 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688051557 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688375335 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688168626 From coleenp at openjdk.org Tue Jul 23 19:09:48 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:48 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> Message-ID: On Wed, 17 Jul 2024 06:40:31 GMT, David Holmes wrote: >> src/hotspot/share/runtime/basicLock.hpp line 46: >> >>> 44: // Used as a cache the ObjectMonitor* used when locking. Must either >>> 45: // be nullptr or the ObjectMonitor* used when locking. >>> 46: volatile uintptr_t _metadata; >> >> The displaced header/markword terminology was very well known to people, whereas "metadata" is really abstract - people will always need to go and find out what it actually refers to. Could we not define a union here to support the legacy and lightweight modes more explicitly and keep the existing terminology for the setters/getters for the code that uses it? > > I should have read ahead. I see you do keep the setters/getters. When we remove legacy locking in a couple of releases, we could rename this field cached_monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688015247 From liach at openjdk.org Tue Jul 23 19:10:12 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 19:10:12 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v4] In-Reply-To: References: Message-ID: > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Refine the spec of TypeAnnotation per Alex feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/6e31c489..416890a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From coleenp at openjdk.org Tue Jul 23 19:09:49 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:49 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <3m5N_Fh65MVy7vRvO0wq3qFlzxjbCLHhbTBJe8OJorw=.eb61b3bd-5aca-45cd-8e88-389ae86a599b@github.com> On Thu, 18 Jul 2024 11:30:27 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 77: > >> 75: using ConcurrentTable = ConcurrentHashTable; >> 76: >> 77: ConcurrentTable* _table; > > So you have a class ObjectMonitorWorld, which references the ConcurrentTable, which, internally also has its actual table. This is 3 dereferences to get to the actual table, if I counted correctly. I'd try to eliminate the outermost ObjectMonitorWorld class, or at least make it a global flat structure instead of a reference to a heap-allocated object. I think, because this is a structure that is global and would exist throughout the lifetime of the Java program anyway, it might be worth figuring out how to do the actual ConcurrentHashTable flat in the global structure, too. This is a really good suggestion and might help a lot with the performance problems that we see with the table with heavily contended locking. I think we should change this in a follow-on patch (which I'll work on). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688053792 From vlivanov at openjdk.org Tue Jul 23 19:14:35 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Jul 2024 19:14:35 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Mon, 22 Jul 2024 16:45:06 GMT, Andrew Haley wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4810: >> >>> 4808: Label* L_success, >>> 4809: Label* L_failure) { >>> 4810: // NB! Callers may assume that, when temp2_reg is a valid register, >> >> Oh, that's a subtle point... Can we make it more evident at call sites? > > Done. I think the only code that still depends on it is the C2 pattern that uses check_klass_subtype_slow_path_linear in x86_32.ad and x86_64.ad. Thanks. I revisited the code and now it seems like `temp2_reg_was_valid` duplicates `set_cond_codes` parameter in the original implementation. Am I missing something important here? Otherwise, why can't we rely on `set_cond_codes` flag instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1688579798 From liach at openjdk.org Tue Jul 23 19:14:46 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jul 2024 19:14:46 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v5] In-Reply-To: References: Message-ID: <6A5fADogvrAFf0SOxFNlD0OEOWwjJObCBqh0X2NXIYM=.41ca7fa2-c6a6-487a-8b1f-e2a996526e05@github.com> > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Further refine wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/416890a7..beb92159 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From vlivanov at openjdk.org Tue Jul 23 19:18:34 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Jul 2024 19:18:34 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: <6P17gX_V6nL3hsgbuPrGN4Y8nzyoQMs3fTLaiRaOzwA=.e3eb0ea0-d41c-4222-a1f3-65f9075dbb4d@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <6P17gX_V6nL3hsgbuPrGN4Y8nzyoQMs3fTLaiRaOzwA=.e3eb0ea0-d41c-4222-a1f3-65f9075dbb4d@github.com> Message-ID: On Mon, 22 Jul 2024 17:19:46 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Review comments FYI I did a merge with mainline and submitted the patch for testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2246099889 From vlivanov at openjdk.org Tue Jul 23 19:18:34 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Jul 2024 19:18:34 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Mon, 22 Jul 2024 16:36:25 GMT, Andrew Haley wrote: >>> Alternatively, `Klass::is_subtype_of()` can unconditionally perform linear search over secondary_supers array. >>> >>> Even though I very much like to see table lookup written in C++ (accompanying heavily optimized platform-specific MacroAssembler variants), it would make C++ runtime even simpler. >> >> It would, but there is something to be said for being able to provide a fast "no" answer for interface membership. I'll agree it's probably not a huge difference. I guess `is_cloneable_fast()` exists only because searching the interfaces is slow. >> Also, if table lookup is written in C++ but not used, it will rot. >> Also also, `Klass::is_subtype_of()` is used for C1 runtime. > > Thinking about it some more, I don't really mind. There may be some virtue to moving lookup_secondary_supers_table() to a comment in the back end(s), and the expansion of population_count() is rather bloaty. > Also also, Klass::is_subtype_of() is used for C1 runtime. Can you elaborate, please? What I'm seeing in `Runtime1::generate_code_for()` for `slow_subtype_check` is a call into `MacroAssembler::check_klass_subtype_slow_path()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1688586602 From vlivanov at openjdk.org Tue Jul 23 19:21:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Jul 2024 19:21:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: <6P17gX_V6nL3hsgbuPrGN4Y8nzyoQMs3fTLaiRaOzwA=.e3eb0ea0-d41c-4222-a1f3-65f9075dbb4d@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <6P17gX_V6nL3hsgbuPrGN4Y8nzyoQMs3fTLaiRaOzwA=.e3eb0ea0-d41c-4222-a1f3-65f9075dbb4d@github.com> Message-ID: On Mon, 22 Jul 2024 17:19:46 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Review comments My take on the questions you raised. > Should Klass::linear_search_secondary_supers() const call set_secondary_super_cache()? (Strong no from me. It's UB.) Agree. I'm fine with addressing that separately (as I mentioned earlier). > Should we use a straight linear search for secondary C++ supers in the runtime, i.e.not changing it for now? Slightly in favor of keeping `Klass::is_subtype_of()` simple, but I'm fine with it either way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2246108523 From rriggs at openjdk.org Tue Jul 23 19:30:34 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 23 Jul 2024 19:30:34 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> References: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> Message-ID: On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > reduce change Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20253#pullrequestreview-2194894116 From duke at openjdk.org Tue Jul 23 19:54:30 2024 From: duke at openjdk.org (Abdelhak Zaaim) Date: Tue, 23 Jul 2024 19:54:30 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu wrote: > As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. > > As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2194939999 From duke at openjdk.org Tue Jul 23 20:12:34 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Jul 2024 20:12:34 GMT Subject: RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v7] In-Reply-To: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> References: <7jJhv5Eb-VWcsm64nN3e07zHp92QaVE5MHv6W1KqScc=.53abce8f-2301-4dfd-b52d-bec0eea264dd@github.com> Message-ID: On Tue, 23 Jul 2024 12:56:07 GMT, Shaojin Wen wrote: >> Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > reduce change @wenshao Your change (at version a2be39af3cd39ff04519c8264a58e538310b38e1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2246224288 From duke at openjdk.org Tue Jul 23 20:23:39 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 20:23:39 GMT Subject: Integrated: 8336831: Optimize StringConcatHelper.simpleConcat In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 13:10:43 GMT, Shaojin Wen wrote: > Currently simpleConcat is implemented using mix and prepend, but in this simple scenario, it can be implemented in a simpler way and can improve performance. This pull request has now been integrated. Changeset: 476d2ae6 Author: Shaojin Wen Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/476d2ae69d6f67fdf9e2a9353f224141318690f2 Stats: 33 lines in 2 files changed: 17 ins; 0 del; 16 mod 8336831: Optimize StringConcatHelper.simpleConcat Reviewed-by: liach, redestad, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/20253 From coleenp at openjdk.org Tue Jul 23 20:24:37 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 20:24:37 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 13:12:23 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 1641: >> >>> 1639: assert(fr.is_deoptimized_frame(), "frame must be scheduled for deoptimization"); >>> 1640: if (LockingMode == LM_LEGACY) { >>> 1641: mon_info->lock()->set_displaced_header(markWord::unused_mark()); >> >> In the existing code how is this restricted to the LM_LEGACY case?? It appears to be unconditional which suggests you are changing the non-UOMT LM_LIGHTWEIGHT logic. ?? > > Only legacy locking uses the displaced header, I believe, which isn't clear in this code at all. This seems like a fix. We should probably assert that only legacy locking uses this field as a displaced header. Update: yes, this code change does assert if you use BasicLock's displaced header for locking modes other than LM_LEGACY. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688668887 From kdriver at openjdk.org Tue Jul 23 20:52:22 2024 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Jul 2024 20:52:22 GMT Subject: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v5] In-Reply-To: References: Message-ID: > Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. See [JEP 478](https://openjdk.org/jeps/478). > > Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: refactor out common code for provider selection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20301/files - new: https://git.openjdk.org/jdk/pull/20301/files/4fb26325..7bedda25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20301&range=03-04 Stats: 110 lines in 2 files changed: 19 ins; 82 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20301/head:pull/20301 PR: https://git.openjdk.org/jdk/pull/20301 From jlu at openjdk.org Tue Jul 23 20:54:08 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 23 Jul 2024 20:54:08 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v2] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. > > As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20302/files - new: https://git.openjdk.org/jdk/pull/20302/files/2efa5d3f..7799b0a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20302.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20302/head:pull/20302 PR: https://git.openjdk.org/jdk/pull/20302 From naoto at openjdk.org Tue Jul 23 20:58:01 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 23 Jul 2024 20:58:01 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v3] In-Reply-To: References: Message-ID: > This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: apiNote -> implNote ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20285/files - new: https://git.openjdk.org/jdk/pull/20285/files/49b894b6..17c61d99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20285&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20285&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20285/head:pull/20285 PR: https://git.openjdk.org/jdk/pull/20285 From duke at openjdk.org Tue Jul 23 22:22:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 22:22:34 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v15] In-Reply-To: <1U6SxE7Px2sJkm8bMXuMPXNvpSSMYWxhlc9pLZGlYXY=.ac3af497-ccf2-46ce-8908-d924da8754a1@github.com> References: <5QHigWHpug0lKFJajoXsKh_y8TN1AkHxFvnaUIOa51Q=.7f78826a-e6de-429e-a333-baf6dd4ff5dc@github.com> <1U6SxE7Px2sJkm8bMXuMPXNvpSSMYWxhlc9pLZGlYXY=.ac3af497-ccf2-46ce-8908-d924da8754a1@github.com> Message-ID: <5Tz8xaacl8muBMguuCJIUoW8SqMRjHTFPQzjuhGeuYQ=.d86408ba-3e72-422c-a62e-8f1aae318c7c@github.com> On Tue, 23 Jul 2024 13:48:57 GMT, Chen Liang wrote: >> explicit array stores has the overhead of boundary checking. If putCharsAt of StringLatin1 is not implemented based on Unsafe, the performance will be worse than StringUTF16. >> >> Of course, this is a common problem. StringUTF16.putChar is equivalent to Unsafe.putChar, without boundary checking. I found in many test scenarios that the UTF16 version performs better than the StringLatin1 version. >> >> We may need to change some StringLatin1 related implementations to use Unsafe, otherwise users will turn off COMPACT_STRINGS to improve performance. > > Thank you for telling what the blocking issue is here. Does C2 not merge the bound checks when it does the merge stores? Interesting, and I think a fix from their side should be the way to go. MergeStore does not work when using StringUTF16.putChar, waiting for improvements from @eme64 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19626#discussion_r1688786926 From duke at openjdk.org Tue Jul 23 22:26:01 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 23 Jul 2024 22:26:01 GMT Subject: RFR: 8336856: Optimize String Concat [v8] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - add comments and format code - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202407 # Conflicts: # src/java.base/share/classes/java/lang/String.java # src/java.base/share/classes/java/lang/StringConcatHelper.java - fix WithSecurityManager error - 1. reduce change 2. add flag GENERATE_INLINE_COPY - Merge remote-tracking branch 'origin/optim_simple_concat_202407' into optim_concat_factory_202407 # Conflicts: # src/java.base/share/classes/java/lang/StringConcatHelper.java # src/java.base/share/classes/java/lang/System.java # src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java - merge from master - Merge remote-tracking branch 'upstream/master' into optim_simple_concat_202407 # Conflicts: # src/java.base/share/classes/java/lang/StringConcatHelper.java - reduce change & refactor - fix TRUSTED not work - non-MH-based implementation - ... and 9 more: https://git.openjdk.org/jdk/compare/476d2ae6...d9d493a0 ------------- Changes: https://git.openjdk.org/jdk/pull/20273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=07 Stats: 410 lines in 5 files changed: 397 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From 1dropaflame at gmail.com Tue Jul 23 23:10:40 2024 From: 1dropaflame at gmail.com (Anil) Date: Tue, 23 Jul 2024 18:10:40 -0500 Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: Chen, Thank you for your reply. I am unable to find ant in cygwin64 anilr at ANIL-LAPTOP /cygdrive/c/users/anil/OpenJDK/jdk $ bin/idea.sh FATAL: cannot find ant. Try setting ANT_HOME. When I run setup, I don't see it at all. [image: image.png] On Sun, Jul 21, 2024 at 6:46?PM Chen Liang wrote: > Please refer to the "Intellij Idea" section on the ide doc: > https://github.com/openjdk/jdk/blob/master/doc/ide.md#intellij-idea > In short, in `jdk`, you need to run the `bin/idea.sh` with cygwin after > you've done `make images` once. Then the root `jdk` directory will be > recognized by idea as an idea project. > > Note that the guide asks to set the SDK to your images/jdk in the project. > Due to problems within Intellij, you should unset the JDK, so the files > won't show up a "package xxx already exists in java.base" error. > You should set the language level to `X-Experimental features` to mute the > warnings about some API usages. > And then, you can navigate JDK code as in any other project, such as > double-shift and search `Stream` to find the `java.util.stream.Stream` > class. > And once you are there, you may encounter the bug I've described, that > actually used methods will appear as "unused": you will have to type > something in one of the method names, like change `filter` to `filter1` so > Intellij idea does a reindex and you can find usages of other > methods/overrides of the interface. > > Regards, liach > > On Sun, Jul 21, 2024 at 2:23?PM Anil <1dropaflame at gmail.com> wrote: > >> Chen, >> Thanks for your reply. >> Yes, I am using IntelliJ Community Edition (on Windows 11, Cygwin64). >> I did not set up the project - I just opened the package in IJ >> C:\Users\Anil\OpenJDK\jdk\src\java.base\share\classes\java\util\stream >> Is there something different I should be doing? >> thanks, >> Anil >> >> >> On Sat, Jul 20, 2024 at 10:39?PM Chen Liang >> wrote: >> >>> Hi Anil, are you using intellij and setting up the project with idea.sh? >>> Idea has a bug where its indexing breaks completely; you need to type >>> something in the code, like a typo in method name, to force it to refresh. >>> >>> On Sat, Jul 20, 2024, 9:45?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Hi, >>>> I had a small idea on debugging of streams and was trying to implement >>>> it to see if it works. >>>> I am able to build the OpenJDK (on Windows 11, Cygwin64). >>>> However, I am unable to find the implementing class of java.util.Stream. >>>> Can you please help? >>>> thanks, >>>> Anil Philip >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 49860 bytes Desc: not available URL: From liangchenblue at gmail.com Tue Jul 23 23:41:45 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Tue, 23 Jul 2024 18:41:45 -0500 Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: Hi Anil, Ant is not a command-line tool of linux; it's an ancient Java build tool popular 10 years ago, before the appearance of Gradle. Its homepage is at https://ant.apache.org/ Once you download, extract it, and add its bin directory to PATH, the script will find ant automatically. Chen On Tue, Jul 23, 2024 at 6:10?PM Anil <1dropaflame at gmail.com> wrote: > Chen, > Thank you for your reply. > I am unable to find ant in cygwin64 > > anilr at ANIL-LAPTOP /cygdrive/c/users/anil/OpenJDK/jdk > $ bin/idea.sh > FATAL: cannot find ant. Try setting ANT_HOME. > > When I run setup, I don't see it at all. > > > [image: image.png] > > > > On Sun, Jul 21, 2024 at 6:46?PM Chen Liang > wrote: > >> Please refer to the "Intellij Idea" section on the ide doc: >> https://github.com/openjdk/jdk/blob/master/doc/ide.md#intellij-idea >> In short, in `jdk`, you need to run the `bin/idea.sh` with cygwin after >> you've done `make images` once. Then the root `jdk` directory will be >> recognized by idea as an idea project. >> >> Note that the guide asks to set the SDK to your images/jdk in the >> project. Due to problems within Intellij, you should unset the JDK, so the >> files won't show up a "package xxx already exists in java.base" error. >> You should set the language level to `X-Experimental features` to mute >> the warnings about some API usages. >> And then, you can navigate JDK code as in any other project, such as >> double-shift and search `Stream` to find the `java.util.stream.Stream` >> class. >> And once you are there, you may encounter the bug I've described, that >> actually used methods will appear as "unused": you will have to type >> something in one of the method names, like change `filter` to `filter1` so >> Intellij idea does a reindex and you can find usages of other >> methods/overrides of the interface. >> >> Regards, liach >> >> On Sun, Jul 21, 2024 at 2:23?PM Anil <1dropaflame at gmail.com> wrote: >> >>> Chen, >>> Thanks for your reply. >>> Yes, I am using IntelliJ Community Edition (on Windows 11, Cygwin64). >>> I did not set up the project - I just opened the package in IJ >>> C:\Users\Anil\OpenJDK\jdk\src\java.base\share\classes\java\util\stream >>> Is there something different I should be doing? >>> thanks, >>> Anil >>> >>> >>> On Sat, Jul 20, 2024 at 10:39?PM Chen Liang >>> wrote: >>> >>>> Hi Anil, are you using intellij and setting up the project with idea.sh? >>>> Idea has a bug where its indexing breaks completely; you need to type >>>> something in the code, like a typo in method name, to force it to refresh. >>>> >>>> On Sat, Jul 20, 2024, 9:45?PM Anil <1dropaflame at gmail.com> wrote: >>>> >>>>> Hi, >>>>> I had a small idea on debugging of streams and was trying to implement >>>>> it to see if it works. >>>>> I am able to build the OpenJDK (on Windows 11, Cygwin64). >>>>> However, I am unable to find the implementing class of >>>>> java.util.Stream. >>>>> Can you please help? >>>>> thanks, >>>>> Anil Philip >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 49860 bytes Desc: not available URL: From duke at openjdk.org Wed Jul 24 03:51:14 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 03:51:14 GMT Subject: RFR: 8336856: Optimize String Concat [v9] In-Reply-To: References: Message-ID: <0g2FMCrfCPBOzepRbdSd2ghXTJwDcgUMvwuQood2G_A=.cf1d0fbd-8131-4833-aff1-9cbfbec4a9c7@github.com> > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: refactor based on 8335182 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/d9d493a0..b274839c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=07-08 Stats: 294 lines in 2 files changed: 178 ins; 57 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From darcy at openjdk.org Wed Jul 24 04:47:08 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 24 Jul 2024 04:47:08 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} [v2] In-Reply-To: References: Message-ID: > First pass at adding some quality of implementation discussions around the overridable methods of Object. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8336043 - Appease jcheck. - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20128/files - new: https://git.openjdk.org/jdk/pull/20128/files/150713fe..81245907 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20128&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20128&range=00-01 Stats: 11244 lines in 484 files changed: 7156 ins; 2247 del; 1841 mod Patch: https://git.openjdk.org/jdk/pull/20128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20128/head:pull/20128 PR: https://git.openjdk.org/jdk/pull/20128 From darcy at openjdk.org Wed Jul 24 05:37:03 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 24 Jul 2024 05:37:03 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} [v3] In-Reply-To: References: Message-ID: <47Yi-KYKMWBRTQjyyyMscneUrqAFDhdsvvtPaKjh4R4=.3a0b80c1-c70f-4644-bad4-2c65f26c1b8a@github.com> > First pass at adding some quality of implementation discussions around the overridable methods of Object. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20128/files - new: https://git.openjdk.org/jdk/pull/20128/files/81245907..95f890bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20128&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20128&range=01-02 Stats: 14 lines in 1 file changed: 5 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20128/head:pull/20128 PR: https://git.openjdk.org/jdk/pull/20128 From darcy at openjdk.org Wed Jul 24 05:37:03 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 24 Jul 2024 05:37:03 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} [v3] In-Reply-To: References: <13yMIgfcXgfmSbDRsUfOPAdnay2-81vsMKG4xpwMkbs=.a12c7d6a-9147-49c4-bc60-f950805b6391@github.com> Message-ID: On Mon, 15 Jul 2024 18:46:09 GMT, Kevin Bourrillion wrote: > I would hope to spend as little space on this as possible, perhaps "This method should avoid throwing or propagating any exceptions unless it legitimately _cannot_ adhere to this contract." (or shorter) Pushed a version using that worked, but I expect discussion will continue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1689161936 From darcy at openjdk.org Wed Jul 24 05:37:03 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 24 Jul 2024 05:37:03 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} [v3] In-Reply-To: <13yMIgfcXgfmSbDRsUfOPAdnay2-81vsMKG4xpwMkbs=.a12c7d6a-9147-49c4-bc60-f950805b6391@github.com> References: <13yMIgfcXgfmSbDRsUfOPAdnay2-81vsMKG4xpwMkbs=.a12c7d6a-9147-49c4-bc60-f950805b6391@github.com> Message-ID: On Thu, 11 Jul 2024 00:11:07 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/java/lang/Object.java line 191: > >> 189: * should not be thrown if the argument has an incomparable type >> 190: * to this object and {@link NullPointerException} should not be >> 191: * thrown if the argument is {@code null}. The implementation > > For these cases the recommendation should be to return false instead of throwing such exceptions. Good point; updated accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1689162089 From asotona at openjdk.org Wed Jul 24 06:52:31 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 24 Jul 2024 06:52:31 GMT Subject: RFR: 8336927: Missing equals and hashCode in java.lang.classfile.Annotation [v2] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 15:43:42 GMT, Chen Liang wrote: >> Convert `AnnotationImpl` to a record so it comes with proper `equals` and `hashCode` implementations. This also fixes the comparison for annotation-valued annotation element values. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/anno-hash-equals > - 8336927: Missing equals and hashCode in java.lang.classfile.Annotation Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20291#pullrequestreview-2195787862 From duke at openjdk.org Wed Jul 24 07:54:38 2024 From: duke at openjdk.org (ExE Boss) Date: Wed, 24 Jul 2024 07:54:38 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v3] In-Reply-To: References: Message-ID: <4Fp8aYdnlRQdjETsE9jcaezn1isJMkfd0X4g1_SsWeA=.9818df57-c27a-4a65-93a8-5ecc3113f2d5@github.com> On Tue, 23 Jul 2024 20:58:01 GMT, Naoto Sato wrote: >> This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > apiNote -> implNote Maybe?add an?empty?line between?`@implSpec` and?`@implNote`: src/java.base/share/classes/java/lang/Process.java line 450: > 448: * @implNote > 449: * Concrete implementations of this class are strongly encouraged to > 450: * override this method with a more efficient implementation. Suggestion: * @implSpec * The default implementation of this method polls the {@code exitValue} * to check if the process has terminated. * * @implNote * Concrete implementations of this class are strongly encouraged to * override this method with a more efficient implementation. src/java.base/share/classes/java/lang/Process.java line 496: > 494: * @implNote > 495: * Concrete implementations of this class are strongly encouraged to > 496: * override this method with a more efficient implementation. Suggestion: * @implSpec * The default implementation of this method polls the {@code exitValue} * to check if the process has terminated. * * @implNote * Concrete implementations of this class are strongly encouraged to * override this method with a more efficient implementation. ------------- PR Review: https://git.openjdk.org/jdk/pull/20285#pullrequestreview-2195902793 PR Review Comment: https://git.openjdk.org/jdk/pull/20285#discussion_r1689310654 PR Review Comment: https://git.openjdk.org/jdk/pull/20285#discussion_r1689310914 From duke at openjdk.org Wed Jul 24 08:01:41 2024 From: duke at openjdk.org (ExE Boss) Date: Wed, 24 Jul 2024 08:01:41 GMT Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16] In-Reply-To: References: <_wFrh1u4zLnKZG8lvbcANwo1KaLWCx_Ssem51ohzPwI=.c3e4d975-97c8-4e32-9865-d26328f11221@github.com> Message-ID: On Tue, 25 Jun 2024 13:54:07 GMT, Oussama Louati wrote: >> And what is the purpose of parsing a model from bytes and transforming it back to bytes without a change? > > This transformation is called only after the `classModel` is transformed: > - at line 472 and 380 when the `transformToBytes()` method is called is after effectively transforming the `classModel` inside the `Logic` class. There isn?t currently any?API for?converting a?`ClassModel` directly to?a?`byte[]` without?calling a?`ClassFile?::transformClass(?)`?method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689321521 From duke at openjdk.org Wed Jul 24 08:10:45 2024 From: duke at openjdk.org (ExE Boss) Date: Wed, 24 Jul 2024 08:10:45 GMT Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16] In-Reply-To: References: Message-ID: On Sat, 22 Jun 2024 15:55:28 GMT, Oussama Louati wrote: >> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants. >> ### Purpose of Indify >> >> - **Transformation Tool**: `Indify` transforms existing class files to leverage `invokedynamic` and other JSR 292 features. This transformation allows for dynamic method calls. >> >> ### Key Functions >> >> - **Method Handle and Method Type Constants**: >> - **MH_x and MT_x Methods**: These methods are used to generate `MethodHandle` and `MethodType` constants. The tool transforms calls to these methods into `CONSTANT_MethodHandle` and `CONSTANT_MethodType` "ldc" (load constant) instructions. >> - **Invokedynamic Call Sites**: >> - **INDY_x Methods**: These methods generate `invokedynamic` call sites. Each `INDY_x` method starts with a call to an `MH_x` method, which acts as the bootstrap method. This is followed by an `invokeExact` call. >> - **Transformation**: The tool transforms pairs of calls (to `INDY_x` followed by `invokeExact`) into `invokedynamic` instructions. This mimics the JVM's handling of `invokedynamic` instructions, creating dynamic call sites that are linked at runtime. >> >> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead. > > Oussama Louati has updated the pull request incrementally with one additional commit since the last revision: > > remove: removed unnecessary logging Even?more formatting?nits: test/jdk/java/lang/invoke/indify/Indify.java line 483: > 481: final char[] poolMarks; > 482: final Map constants = new HashMap<>(); > 483: Logic(ClassModel classModel){ Suggestion: Logic(ClassModel classModel) { test/jdk/java/lang/invoke/indify/Indify.java line 566: > 564: )) b.with(e); > 565: else{ > 566: if(!quietly) System.err.println("Removing pattern method: " + ((MethodModel) e).methodName()); Suggestion: else { if (!quietly) System.err.println("Removing pattern method: " + ((MethodModel) e).methodName()); test/jdk/java/lang/invoke/indify/Indify.java line 640: > 638: } > 639: > 640: char nameAndTypeMark(Utf8Entry name, Utf8Entry type){ Suggestion: char nameAndTypeMark(Utf8Entry name, Utf8Entry type) { test/jdk/java/lang/invoke/indify/Indify.java line 716: > 714: > 715: private PoolEntry scanPattern(MethodModel method, char patternMark) { > 716: if(verbose) System.err.println("Scanning the method: " + method.methodName().stringValue() + "for the pattern mark: " + patternMark); Suggestion: if (verbose) System.err.println("Scanning the method: " + method.methodName().stringValue() + "for the pattern mark: " + patternMark); test/jdk/java/lang/invoke/indify/Indify.java line 731: > 729: List bsmArgs = null; // args to invokeGeneric > 730: decode: > 731: for(Instruction instruction : instructions){ Suggestion: for (Instruction instruction : instructions) { test/jdk/java/lang/invoke/indify/Indify.java line 735: > 733: int bc = instruction.opcode().bytecode(); > 734: String UNKNOWN_CON = ""; > 735: switch (bc){ Suggestion: switch (bc) { test/jdk/java/lang/invoke/indify/Indify.java line 743: > 741: case ANEWARRAY : > 742: arg = jvm.pop(); > 743: if( !(arg instanceof Integer)) break decode; Suggestion: if (!(arg instanceof Integer)) break decode; test/jdk/java/lang/invoke/indify/Indify.java line 859: > 857: buf.append(argClass.descriptorString()); > 858: }else if (typeArg instanceof PoolEntry argCon) { > 859: if(argCon.tag() == TAG_CLASS) { Suggestion: for (Object typeArg : args) { if (typeArg instanceof Class argClass) { buf.append(argClass.descriptorString()); } else if (typeArg instanceof PoolEntry argCon) { if (argCon.tag() == TAG_CLASS) { test/jdk/java/lang/invoke/indify/Indify.java line 888: > 886: continue; > 887: case "lookupClass": > 888: if(args.equals(List.of("lookup"))) { Suggestion: if (args.equals(List.of("lookup"))) { test/jdk/java/lang/invoke/indify/Indify.java line 907: > 905: case "Double.valueOf": > 906: removeEmptyJVMSlots(args); > 907: if(args.size() == 1 ) { Suggestion: if (args.size() == 1) { test/jdk/java/lang/invoke/indify/Indify.java line 923: > 921: continue; > 922: } > 923: if(!hasReceiver && ownMethod != null) { Suggestion: if (!hasReceiver && ownMethod != null) { test/jdk/java/lang/invoke/indify/Indify.java line 937: > 935: { > 936: ++branchCount; > 937: if(bsmArgs != null){ Suggestion: if (bsmArgs != null) { test/jdk/java/lang/invoke/indify/Indify.java line 952: > 950: break; > 951: if((arg instanceof PoolEntry) && ((PoolEntry) arg).tag() == wantedTag) > 952: return (PoolEntry) arg; Suggestion: if (branchCount == 2 && UNKNOWN_CON.equals(arg)) break; if ((arg instanceof PoolEntry) && ((PoolEntry) arg).tag() == wantedTag) return (PoolEntry) arg; test/jdk/java/lang/invoke/indify/Indify.java line 956: > 954: } > 955: default: > 956: if(jvm.stackMotion(instruction.opcode().bytecode())) break; Suggestion: if (jvm.stackMotion(instruction.opcode().bytecode())) break; test/jdk/java/lang/invoke/indify/Indify.java line 1008: > 1006: > 1007: } > 1008: } Suggestion: private PoolEntry makeMethodTypeCon(Object x) { if (x instanceof StringEntry stringEntry) { return poolBuilder.methodTypeEntry(stringEntry.utf8()); } else { return poolBuilder.methodTypeEntry(poolBuilder.utf8Entry((String) x)); } } test/jdk/java/lang/invoke/indify/Indify.java line 1044: > 1042: } > 1043: return poolBuilder.methodHandleEntry(refKind, ref); > 1044: } Suggestion: private PoolEntry parseMemberLookup(byte refKind, List args) { //E.g.: lookup().findStatic(Foo.class, "name", MethodType) if (args.size() != 4) return null; NameAndTypeEntry nameAndTypeEntry; Utf8Entry name, type; ClassEntry ownerClass; if (!"lookup".equals(args.getFirst())) return null; if (args.get(1) instanceof ClassEntry classEntry) ownerClass = classEntry; else return null; if (args.get(2) instanceof StringEntry stringEntry) name = stringEntry.utf8(); else return null; if (args.get(3) instanceof MethodTypeEntry methodTypeEntry) type = methodTypeEntry.descriptor(); else return null; nameAndTypeEntry = poolBuilder.nameAndTypeEntry(name,type); MemberRefEntry ref; if (refKind <= (byte) STATIC_SETTER.refKind) { ref = poolBuilder.fieldRefEntry(ownerClass, nameAndTypeEntry); return poolBuilder.methodHandleEntry(refKind, ref); } else if (refKind == (byte) INTERFACE_VIRTUAL.refKind) { ref = poolBuilder.interfaceMethodRefEntry(ownerClass, nameAndTypeEntry); return poolBuilder.methodHandleEntry(refKind, ref); } else { ref = poolBuilder.methodRefEntry(ownerClass, nameAndTypeEntry); } return poolBuilder.methodHandleEntry(refKind, ref); } test/jdk/java/lang/invoke/indify/Indify.java line 1049: > 1047: // E.g.: MH_bsm.invokeGeneric(lookup(), "name", MethodType, "extraArg") > 1048: removeEmptyJVMSlots(args); > 1049: if(args.size() < 4) return null; Suggestion: if (args.size() < 4) return null; ------------- PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2195922618 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689323572 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689328799 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689323765 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689330738 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689323955 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689324110 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689330906 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689330144 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689331095 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689331287 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689331509 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689324306 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689331836 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689332014 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689325088 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689326268 PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689326428 From galder at openjdk.org Wed Jul 24 08:18:32 2024 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Wed, 24 Jul 2024 08:18:32 GMT Subject: RFR: 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 ... I've been working on some JMH benchmarks and I'm seeing some strange results that I need to investigate further. I will update the PR when I have found the reason(s). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2247189103 From asotona at openjdk.org Wed Jul 24 08:19:40 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 24 Jul 2024 08:19:40 GMT Subject: RFR: 8307818: Convert Indify tool to Classfile API [v16] In-Reply-To: References: <_wFrh1u4zLnKZG8lvbcANwo1KaLWCx_Ssem51ohzPwI=.c3e4d975-97c8-4e32-9865-d26328f11221@github.com> Message-ID: On Wed, 24 Jul 2024 07:58:31 GMT, ExE Boss wrote: >> This transformation is called only after the `classModel` is transformed: >> - at line 472 and 380 when the `transformToBytes()` method is called is after effectively transforming the `classModel` inside the `Logic` class. > > There isn?t currently any?API for?converting a?`ClassModel` directly to?a?`byte[]` without?calling a?`ClassFile?::transformClass(?)`?method. Repeated parsing (bytes -> model) and transforming back (model -> bytes) is an anti-pattern. Indify tool should operate as a single-pass transformation. Looping on a class model methods / instructions while replacing the class model itself (with something partially transformed) is not the right approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1689346557 From aph at openjdk.org Wed Jul 24 09:05:38 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Jul 2024 09:05:38 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v5] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Tue, 23 Jul 2024 19:14:57 GMT, Vladimir Ivanov wrote: > > Also also, Klass::is_subtype_of() is used for C1 runtime. > > Can you elaborate, please? Sorry, that was rather vague. In C1-compiled code, the Java method `Class::isInstance(Object)`calls `Klass::is_subtype_of()`. In general, I find it difficult to decide how much work, if any, should be done to improve C1 performance. Clearly, if C1 exists only to help with startup time in a tiered compilation system, the answer is "not much". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1689414385 From duke at openjdk.org Wed Jul 24 09:11:44 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 24 Jul 2024 09:11:44 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: <53ftvg3_BujXQwi45uB2vWi5cvUU4fPptDhQSu-hzyU=.459cc7cb-9aa7-4662-8519-09e70ff50966@github.com> References: <53ftvg3_BujXQwi45uB2vWi5cvUU4fPptDhQSu-hzyU=.459cc7cb-9aa7-4662-8519-09e70ff50966@github.com> Message-ID: On Tue, 23 Jul 2024 15:19:30 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Conditions' order reversed in MBI.ulongSqrt() > > To clarify, the PR's code seems correct, but I wonder if it can be made simpler. @rgiulietti The C code in ?5.1 is correct, but it follows a logic that is slightly different from that of the pseudocode, it is less clear. Actually, the PR's code could be made simpler. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2247310012 From rgiulietti at openjdk.org Wed Jul 24 10:10:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 24 Jul 2024 10:10:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 17:22:50 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Conditions' order reversed in MBI.ulongSqrt() As I see it, there are some advantages in making the PR code as similar as possible to the code in the paper: * It might result in simpler code (and maybe even faster code). * It would make the Java code easier to compare to the C code in the paper. This would cause less head scratches to reviewers and contributors that might want to evolve the code. * Since we know that (a variant) of that C code is in production since many years in GMP, and since that code has been formally verified, there's more confidence about its correctness. Now, the C code has some obscure logic for the division by 2 S'. There's no stringent need to emulate that part, I think. Also, the logic for the 1 bit return value of the C function might be too cumbersome to emulate in the Java code. Anyway, I think it would be beneficial to avoid the denormalization step in the recursive `sqrtRemZimmermann()` method. If possible, normalization and denormalization should only happen once in `sqrtRem()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2247473366 From duke at openjdk.org Wed Jul 24 10:18:03 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 10:18:03 GMT Subject: RFR: 8336856: Optimize String Concat [v10] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with ten additional commits since the last revision: - minor refactor - minor refactor - reduce change - copyright - reduce change - refactor based on 8335182 - use Float.toString & Double.toString - remove ForceInline - fix build error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/b274839c..c53ce54d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=08-09 Stats: 385 lines in 4 files changed: 30 ins; 291 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From duke at openjdk.org Wed Jul 24 10:23:35 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 10:23:35 GMT Subject: RFR: 8336856: Optimize String Concat [v10] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 10:18:03 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with ten additional commits since the last revision: > > - minor refactor > - minor refactor > - reduce change > - copyright > - reduce change > - refactor based on 8335182 > - use Float.toString & Double.toString > - remove ForceInline > - fix build error Now, the implementation algorithm is the same as the MH-based implementation. The difference is that the original implementation was based on MethodHandle, but now it is based on bytecode-spinning, so no additional changes are required to StringConatHelper, and the performance is the same. - MH-based -@ 8 java.lang.invoke.LambdaForm$MH/0x00000800000d5000::linkToTargetMethod (10 bytes) force inline by annotation - @ 6 java.lang.invoke.LambdaForm$MH/0x00000800000d4800::invoke (80 bytes) force inline by annotation - @ 16 java.lang.invoke.LambdaForm$MH/0x00000800000d4000::invoke (46 bytes) force inline by annotation - @ 23 java.lang.invoke.LambdaForm$BMH/0x00000800000d2c00::reinvoke (20 bytes) force inline by annotation - @ 16 java.lang.invoke.LambdaForm$DMH/0x00000800000d2400::invokeStatic (17 bytes) force inline by annotation - @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation + bytecode-spinning +@ 8 java.lang.invoke.LambdaForm$MH/0x00000ff8000cd800::linkToTargetMethod (10 bytes) force inline by annotation + @ 6 java.lang.invoke.LambdaForm$DMH/0x00000ff8000cd000::invokeStatic (15 bytes) force inline by annotation + @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation Based on bytecode-spinning, some intermediate classes will be generated less, which should improve the startup time, but how to analyze the startup time? Can anyone help? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2247517412 From duke at openjdk.org Wed Jul 24 10:25:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 10:25:34 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v4] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:43:05 GMT, Shaojin Wen wrote: >> class LocalTime { >> public String toString() { >> // ... >> if (nanoValue % 1000_000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); >> } else if (nanoValue % 1000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); >> } else { >> buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); >> } >> // ... >> } >> } >> >> Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright Need a second reviewer to approve it. Can anyone take a look at this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2247520922 From duke at openjdk.org Wed Jul 24 10:32:08 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 24 Jul 2024 10:32:08 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v35] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Made normalization consistent with that of the C code in the paper ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/2598ec97..6561f5a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=33-34 Stats: 66 lines in 1 file changed: 6 ins; 41 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Wed Jul 24 10:40:42 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 24 Jul 2024 10:40:42 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v34] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 10:07:48 GMT, Raffaello Giulietti wrote: > As I see it, there are some advantages in making the PR code as similar as possible to the code in the paper: > > * It might result in simpler code (and maybe even faster code). > > * It would make the Java code easier to compare to the C code in the paper. This would cause less head scratches to reviewers and contributors that might want to evolve the code. > > * Since we know that (a variant) of that C code is in production since many years in GMP, and since that code has been formally verified, there's more confidence about its correctness. > > > Now, the C code has some obscure logic for the division by 2 S'. There's no stringent need to emulate that part, I think. Also, the logic for the 1 bit return value of the C function might be too cumbersome to emulate in the Java code. > > Anyway, I think it would be beneficial to avoid the denormalization step in the recursive `sqrtRemZimmermann()` method. If possible, normalization and denormalization should only happen once in `sqrtRem()`. Initially, when I implemented the algorithm, I almost completely ignored the C code in the paper, because it seemed very obscure to me, and I relied solely on the logic of the pseudocode, even at the cost of writing a less efficient program. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2247559325 From sspitsyn at openjdk.org Wed Jul 24 10:45:35 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 10:45:35 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates [v2] In-Reply-To: References: Message-ID: <9389g2jCKnajfqlGWHttg0RI1HgwODRFKHeuQX3F_ls=.d77bfcc2-b137-4bf5-a325-026229e662e1@github.com> On Fri, 19 Jul 2024 16:59:54 GMT, Alan Bateman wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > Alan Bateman 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 > - Fix typo in comment, missing copyright update, test nits > - Merge > - Drop JLA updates for this update > - Merge > - Merge > - Update copyright headers > - Initial commit Looks good. Thank you for porting this to Main line. test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java line 63: > 61: }; > 62: > 63: ThreadFactory factory = VThreadScheduler.virtualThreadFactory(scheduler); Nit: So, there is no name for this thread anymore. Just wanted to note thread names are useful in debugging. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20143#pullrequestreview-2187747262 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1684084924 From redestad at openjdk.org Wed Jul 24 11:31:38 2024 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 24 Jul 2024 11:31:38 GMT Subject: RFR: 8336856: Optimize String Concat [v10] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 10:18:03 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with ten additional commits since the last revision: > > - minor refactor > - minor refactor > - reduce change > - copyright > - reduce change > - refactor based on 8335182 > - use Float.toString & Double.toString > - remove ForceInline > - fix build error This is looking much better! An idea: evolve this PR to first and foremost be a replacement for the current `SimpleStringBuilderStrategy`. If you can prove the new strategy is always superior to the baseline `SimpleStringBuilderStrategy` (performance close to `generateMHInlineCopy` but without the problematic scaling JIT overheads for high-arity expressions) then we have a good, incremental improvement with relatively low risk. We can then follow-up with making this better for low-arity expressions by implementing a sharing strategy (need to build classes where we inject rather than embed constants and cache them, e.g. in a `ReferencedKeyMap`) as a follow-up. One issue for both this and that future PR is that the hidden classes are generated into `java.lang` with `Lookup.ClassOption.STRONG`. This means such classes effectively can never be unloaded. That's a blocker. We need to get rid of that `STRONG` coupling, add tests to ensure generated classes can be unloaded and validate that this doesn't add too much overhead. For startup verification I added a `StringConcatStartup` JMH in #19927. You could extend that with a few tests that exercise high-arity expressions. src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 153: > 151: @SuppressWarnings("removal") > 152: private static boolean isGenerateInlineCopy() { > 153: return GENERATE_INLINE_COPY && System.getSecurityManager() == null; This security manager hack is unfortunate. Likely some bootstrapping issue due use of the classfile API, which might be pulling in lambdas in the paths travelled by this patch. src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1253: > 1251: } > 1252: > 1253: int lengthCoderSloat = paramSlotsTotalSize; Suggestion: int lengthCoderSlot = paramSlotsTotalSize; ------------- PR Review: https://git.openjdk.org/jdk/pull/20273#pullrequestreview-2196340289 PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1689583138 PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1689578966 From duke at openjdk.org Wed Jul 24 11:43:45 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 11:43:45 GMT Subject: RFR: 8336856: Optimize String Concat [v11] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202407 - typo - change comments - minor refactor - minor refactor - reduce change - copyright - reduce change - refactor based on 8335182 - use Float.toString & Double.toString - ... and 22 more: https://git.openjdk.org/jdk/compare/05d88de0...6faecfd7 ------------- Changes: https://git.openjdk.org/jdk/pull/20273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=10 Stats: 278 lines in 2 files changed: 265 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From rgiulietti at openjdk.org Wed Jul 24 11:48:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 24 Jul 2024 11:48:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v35] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 10:32:08 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Made normalization consistent with that of the C code in the paper The aim is not about having even more efficient code (yours is already faster than the existing algorithm), but to have simpler code. The two denormalization code snippets, while based on the same underlying math, are quite different in shape. Having just one denormalization code should be easier to read, understand, check, compare to the paper, and (possibly) evolve. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2247702550 From rgiulietti at openjdk.org Wed Jul 24 11:54:50 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 24 Jul 2024 11:54:50 GMT Subject: RFR: 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float) [v4] In-Reply-To: References: Message-ID: <7yRyUiHtUVBJ-CGHtveb78Ryq_AbmApWTnr-RWSBcsM=.593e3c3e-5b66-4bbe-add0-40b42430edbb@github.com> On Tue, 30 Apr 2024 08:44:32 GMT, Raffaello Giulietti wrote: >> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings. > > 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 four additional commits since the last revision: > > - Merge branch 'master' into 8316662 > - Merge branch 'master' into 8316662 > - Uppercase JLA. > - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float) Adding a comment just for... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-2247715108 From duke at openjdk.org Wed Jul 24 12:02:12 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 24 Jul 2024 12:02:12 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v36] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: An optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/6561f5a7..05f4fff3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=35 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=34-35 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From liach at openjdk.org Wed Jul 24 12:16:37 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 12:16:37 GMT Subject: Integrated: 8336927: Missing equals and hashCode in java.lang.classfile.Annotation In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 04:44:57 GMT, Chen Liang wrote: > Convert `AnnotationImpl` to a record so it comes with proper `equals` and `hashCode` implementations. This also fixes the comparison for annotation-valued annotation element values. This pull request has now been integrated. Changeset: 332df83e Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/332df83e7cb1f272c08f8e4955d6abaf3f091ace Stats: 42 lines in 2 files changed: 23 ins; 14 del; 5 mod 8336927: Missing equals and hashCode in java.lang.classfile.Annotation Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20291 From duke at openjdk.org Wed Jul 24 12:24:40 2024 From: duke at openjdk.org (Vanitha B P) Date: Wed, 24 Jul 2024 12:24:40 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive Message-ID: tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. ------------- Commit messages: - 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive Changes: https://git.openjdk.org/jdk/pull/20312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336315 Stats: 20 lines in 2 files changed: 6 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20312/head:pull/20312 PR: https://git.openjdk.org/jdk/pull/20312 From liach at openjdk.org Wed Jul 24 13:00:47 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 13:00:47 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: References: Message-ID: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> > `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. > > Depends on #20205. Chen Liang has updated the pull request incrementally with three additional commits since the last revision: - More refinements from alex - Artifact -> construct - More about Annotation, add equals note ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20247/files - new: https://git.openjdk.org/jdk/pull/20247/files/beb92159..cf16e7ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=04-05 Stats: 73 lines in 4 files changed: 52 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/20247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247 PR: https://git.openjdk.org/jdk/pull/20247 From duke at openjdk.org Wed Jul 24 13:20:53 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 24 Jul 2024 13:20:53 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v37] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Revert "An optimization" This reverts commit 05f4fff3ee47124da9fb4a637212ba525d4f80ef. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/05f4fff3..daef55c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=35-36 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Wed Jul 24 13:23:37 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 24 Jul 2024 13:23:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v35] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 11:46:03 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Made normalization consistent with that of the C code in the paper > > The aim is not about having even more efficient code (yours is already faster than the existing algorithm), but to have simpler code. > > The two denormalization code snippets, while based on the same underlying math, are quite different in shape. Having just one denormalization code should be easier to read, understand, check, compare to the paper, and (possibly) evolve. @rgiulietti I simplified the code to fit the normalization/unnormalization with that of the paper's C code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2247920751 From liach at openjdk.org Wed Jul 24 13:36:37 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 13:36:37 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v6] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 00:52:17 GMT, Shaojin Wen wrote: >> [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. > > Shaojin Wen 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 14 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - bug fix for `putChars4C` > - bug fix for `putChars4C` and `putChars4S` > - use VarHandler CHAR_L & CHAR_B > - copyright > - bug fix for putIntBU > - add cases for `getChar` & `putChar` > - code format > - add `setIntRL` & `setIntRLU` > - ... and 4 more: https://git.openjdk.org/jdk/compare/1bd72368...74f8837c Should we leave this benchmark in `vm/compiler` instead of `java/lang`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2247951444 From asotona at openjdk.org Wed Jul 24 13:39:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 24 Jul 2024 13:39:32 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> References: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> Message-ID: On Wed, 24 Jul 2024 13:00:47 GMT, Chen Liang wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > Chen Liang has updated the pull request incrementally with three additional commits since the last revision: > > - More refinements from alex > - Artifact -> construct > - More about Annotation, add equals note Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2196775087 From epeter at openjdk.org Wed Jul 24 13:41:41 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 24 Jul 2024 13:41:41 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v5] In-Reply-To: References: Message-ID: On Tue, 18 Jun 2024 01:09:49 GMT, Shaojin Wen wrote: >> Shaojin Wen 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 13 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into merge_store_bench >> - bug fix for `putChars4C` >> - bug fix for `putChars4C` and `putChars4S` >> - use VarHandler CHAR_L & CHAR_B >> - copyright >> - bug fix for putIntBU >> - add cases for `getChar` & `putChar` >> - code format >> - add `setIntRL` & `setIntRLU` >> - add comments >> - ... and 3 more: https://git.openjdk.org/jdk/compare/322c6e37...4c9b9418 > > I re-ran the performance test based on WebRevs 04: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=04) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=03-04) ([4c9b9418](https://git.openjdk.org/jdk/pull/19734/files/4c9b9418fc4a95504867b6019b3e94605917f747)) . > > # 1. Cases MergeStore does not work > @eme64 > I found `putChars4BV` and `putChars4LV` two cases MergeStore didn't work, if support can be enhanced, it would be useful for people using VarHandle. > > > putChars4BV > putChars4LV > > > I also found that the performance of the case using VarHandle is particularly good. Why? For example: > > setIntBV > setIntLV > setLongBV > setLongLV > > > # 2. Performance numbers > The names of these cases have the following B/L/V/U suffixes, which are: > > B BigEndian > L LittleEndian > V VarHandle > U Unsafe > R reverseBytes > C Unsafe.getChar & putChar > S Unsafe.getShort & putShort > > > ## 2.1 MacBook M1 Pro (aarch64) > > Benchmark Mode Cnt Score Error Units > MergeStoreBench.getCharB avgt 15 5340.200 ? 7.038 ns/op > MergeStoreBench.getCharBU avgt 15 5482.163 ? 7.922 ns/op > MergeStoreBench.getCharBV avgt 15 5074.165 ? 6.759 ns/op > MergeStoreBench.getCharC avgt 15 5051.763 ? 6.552 ns/op > MergeStoreBench.getCharL avgt 15 5374.464 ? 9.783 ns/op > MergeStoreBench.getCharLU avgt 15 5487.532 ? 6.368 ns/op > MergeStoreBench.getCharLV avgt 15 5071.263 ? 9.717 ns/op > MergeStoreBench.getIntB avgt 15 6277.984 ? 6.284 ns/op > MergeStoreBench.getIntBU avgt 15 5232.984 ? 10.384 ns/op > MergeStoreBench.getIntBV avgt 15 1206.264 ? 1.193 ns/op > MergeStoreBench.getIntL avgt 15 6172.779 ? 1.962 ns/op > MergeStoreBench.getIntLU avgt 15 5157.317 ? 16.077 ns/op > MergeStoreBench.getIntLV avgt 15 2558.110 ? 3.402 ns/op > MergeStoreBench.getIntRB avgt 15 6889.916 ? 36.955 ns/op > MergeStoreBench.getIntRBU avgt 15 5769.950 ? 11.499 ns/op > MergeStoreBench.getIntRL avgt 15 6625.605 ? 10.662 ns/op > MergeStoreBench.getIntRLU avgt 15 5746.742 ? 11.945 ns/op > MergeStoreBench.getIntRU avgt 15 2544.586 ? 2.769 ns/op > MergeStoreBench.getIntU avgt 15 2541.119 ? 3.252 ns/op > MergeStoreBench.getLongB avgt 15 12098.129 ? 31.451 ns/op > MergeStoreBench.getLongBU avgt 15 9760.621 ? 16.427 ns/op > MergeStoreBench.getLongBV avgt 15 2593.635 ? 4.698 ns/op > MergeStoreBench.getLongL avgt 15 12031.065 ? 19.820 ns/op > Merge... @wenshao what is the state of this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2247964317 From epeter at openjdk.org Wed Jul 24 13:41:38 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 24 Jul 2024 13:41:38 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v6] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 13:33:43 GMT, Chen Liang wrote: >> Shaojin Wen 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 14 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into merge_store_bench >> - Merge remote-tracking branch 'upstream/master' into merge_store_bench >> - bug fix for `putChars4C` >> - bug fix for `putChars4C` and `putChars4S` >> - use VarHandler CHAR_L & CHAR_B >> - copyright >> - bug fix for putIntBU >> - add cases for `getChar` & `putChar` >> - code format >> - add `setIntRL` & `setIntRLU` >> - ... and 4 more: https://git.openjdk.org/jdk/compare/1677d430...74f8837c > > Should we leave this benchmark in `vm/compiler` instead of `java/lang`? @liach we should move it to `vm/compiler`, yes! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2247961571 From liach at openjdk.org Wed Jul 24 14:18:32 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 14:18:32 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v2] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 20:54:08 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. >> >> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review The new AssertionError looks neat. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2196887046 From liach at openjdk.org Wed Jul 24 14:27:34 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 14:27:34 GMT Subject: RFR: 8333265: De-duplicate method references in java.util.stream.FindOps [v3] In-Reply-To: References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com> Message-ID: On Tue, 18 Jun 2024 10:00:46 GMT, Claes Redestad wrote: >> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Fixes test/micro/org/openjdk/bench/java/util/stream/ops/ref/FindAny.java line 63: > 61: } > 62: > 63: public static void main(String... args) { Is this driver necessary? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1689920309 From duke at openjdk.org Wed Jul 24 14:31:37 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 14:31:37 GMT Subject: RFR: 8336856: Optimize String Concat [v11] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 11:43:45 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202407 > - typo > - change comments > - minor refactor > - minor refactor > - reduce change > - copyright > - reduce change > - refactor based on 8335182 > - use Float.toString & Double.toString > - ... and 22 more: https://git.openjdk.org/jdk/compare/05d88de0...6faecfd7 Below are the performance values ??running on a MacBook M1 Pro, with a significant improvement in startup performance. `StringConcatStartup.StringSingle.run` has a performance regression due to an additional static FLAG. Remove the following code and the performance of this scenario is the same. String generateInlineCopy = VM.getSavedProperty("java.lang.invoke.StringConcat.generateInlineCopy"); GENERATE_INLINE_COPY = generateInlineCopy != null ? "true".equalsIgnoreCase(generateInlineCopy) : true; String generateInlineCopy = VM.getSavedProperty("java.lang.invoke.StringConcat.generateInlineCopy"); GENERATE_INLINE_COPY = generateInlineCopy != null ? "true".equalsIgnoreCase(generateInlineCopy) : true; -# baseline (05d88de05e9b7814ecd5517aacd17f0feafdff3c) -Benchmark (intValue) Mode Cnt Score Error Units -StringConcatStartup.MixedLarge.run N/A ss 10 314.191 ? 8.621 ms/op -StringConcatStartup.MixedSmall.run N/A ss 20 24.906 ? 0.669 ms/op -StringConcatStartup.StringLarge.run N/A ss 10 87.491 ? 3.760 ms/op -StringConcatStartup.StringSingle.run N/A ss 40 0.096 ? 0.002 ms/op +# current e497c954bd2d27334cbfabb7efa6841d0a5d9427 +Benchmark (intValue) Mode Cnt Score Error Units +StringConcatStartup.MixedLarge.run N/A ss 10 102.306 ? 3.709 ms/op +StringConcatStartup.MixedSmall.run N/A ss 20 4.366 ? 0.109 ms/op +StringConcatStartup.StringLarge.run N/A ss 10 44.109 ? 1.600 ms/op +StringConcatStartup.StringSingle.run N/A ss 40 0.126 ? 0.008 ms/op | | baseline | current | delta | | --- | --- | --- | --- | | StringConcatStartup.MixedLarge.run | 314.191 | 102.306 | 207.11% | | StringConcatStartup.MixedSmall.run | 24.906 | 4.366 | 470.45% | | StringConcatStartup.StringLarge.run | 87.491 | 44.109 | 98.35% | | StringConcatStartup.StringSingle.run | 0.096 | 0.126 | -23.81% | ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2248148892 From aph at openjdk.org Wed Jul 24 14:34:09 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Jul 2024 14:34:09 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v6] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19989/files - new: https://git.openjdk.org/jdk/pull/19989/files/02cfd130..48e80a13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From aph at openjdk.org Wed Jul 24 14:34:09 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Jul 2024 14:34:09 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v6] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Tue, 23 Jul 2024 19:00:02 GMT, Vladimir Ivanov wrote: > What happens when users include `klass.hpp`, but not `klass.inline.hpp`? How does it affect generated code? > > I suspect that `Klass::search_secondary_supers()` won't be inlinined in such case. That is true. I can't tell from this exchange whether you think it should. The same "wont be inlined" fact is also true of everything else in `klass.inline.hpp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1689927770 From liach at openjdk.org Wed Jul 24 14:41:35 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 14:41:35 GMT Subject: RFR: 8336856: Optimize String Concat [v11] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 11:43:45 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202407 > - typo > - change comments > - minor refactor > - minor refactor > - reduce change > - copyright > - reduce change > - refactor based on 8335182 > - use Float.toString & Double.toString > - ... and 22 more: https://git.openjdk.org/jdk/compare/05d88de0...6faecfd7 I will have a more in-depth review later, and help resolve the access issues with Lookup and SecurityManager. src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 387: > 385: try { > 386: if (concatType.parameterCount() <= HIGH_ARITY_THRESHOLD) { > 387: mh = generateMHInlineCopy(concatType, constantStrings); You can consider using `concatType.erase()` src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1119: > 1117: > 1118: private static MethodHandle generate(Lookup lookup, MethodType args, String[] constants) throws Exception { > 1119: lookup = MethodHandles.Lookup.IMPL_LOOKUP; I think you can try moving the inline copy generation to java.lang's StringConcatHelper; this way, we don't need to expose stringSize, coder etc. through JavaLangAccess (we may update String impl detail in the future) and just access the generated MethodHandle. ------------- PR Review: https://git.openjdk.org/jdk/pull/20273#pullrequestreview-2196930455 PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1689931670 PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1689935833 From liach at openjdk.org Wed Jul 24 14:44:34 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 14:44:34 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v3] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 20:58:01 GMT, Naoto Sato wrote: >> This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > apiNote -> implNote Thank you for addressing my CSR comment about subclass recommendations. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20285#pullrequestreview-2196957390 From duke at openjdk.org Wed Jul 24 14:44:50 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 14:44:50 GMT Subject: RFR: 8336856: Optimize String Concat [v12] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: replace generateMethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/6faecfd7..0fa1658e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=10-11 Stats: 98 lines in 1 file changed: 0 ins; 96 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From duke at openjdk.org Wed Jul 24 14:49:05 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 14:49:05 GMT Subject: RFR: 8336856: Optimize String Concat [v13] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: reduce change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/0fa1658e..a0cdef4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=11-12 Stats: 11 lines in 1 file changed: 2 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From acobbs at openjdk.org Wed Jul 24 14:57:05 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 24 Jul 2024 14:57:05 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7] In-Reply-To: References: Message-ID: > `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. > > There are several issues with this: > > 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. > 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). > 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. > > On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). > > So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into JDK-8322256 - Wording tweak. - Change concatenation policy config from booleans to new ConcatPolicy enum. - Merge branch 'master' into JDK-8322256 - Bump @since from 23 to 24. - Merge branch 'master' into JDK-8322256 - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. - Simplify code by eliminating an impossible case. - Field name change and Javadoc wording tweaks. - Merge branch 'master' into JDK-8322256 - ... and 6 more: https://git.openjdk.org/jdk/compare/332df83e...72b60092 ------------- Changes: https://git.openjdk.org/jdk/pull/18385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=06 Stats: 383 lines in 2 files changed: 357 ins; 13 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/18385.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385 PR: https://git.openjdk.org/jdk/pull/18385 From duke at openjdk.org Wed Jul 24 14:59:33 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 14:59:33 GMT Subject: RFR: 8336856: Optimize String Concat [v11] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 14:34:01 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: >> >> - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202407 >> - typo >> - change comments >> - minor refactor >> - minor refactor >> - reduce change >> - copyright >> - reduce change >> - refactor based on 8335182 >> - use Float.toString & Double.toString >> - ... and 22 more: https://git.openjdk.org/jdk/compare/05d88de0...6faecfd7 > > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1119: > >> 1117: >> 1118: private static MethodHandle generate(Lookup lookup, MethodType args, String[] constants) throws Exception { >> 1119: lookup = MethodHandles.Lookup.IMPL_LOOKUP; > > I think you can try moving the inline copy generation to java.lang's StringConcatHelper; this way, we don't need to expose stringSize, coder etc. through JavaLangAccess (we may update String impl detail in the future) and just access the generated MethodHandle. If you do not use TRUSTED Lookup, errors will occur when processing records. You can see this build error https://github.com/wenshao/jdk/actions/runs/10049344961/job/27775952878 TEST: java/lang/reflect/records/RecordReflectionTest.java Caused by: java.lang.IllegalAccessException: no such method: java.lang.StringConcatHelper$$StringConcat/0xad1b77c0.concat(R1,R2,R3)String/invokeStatic at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:906) at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:989) at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3750) at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2648) at java.base/java.lang.invoke.StringConcatFactory$SimpleStringBuilderStrategy.generate(StringConcatFactory.java:727) ... 41 more Caused by: java.lang.LinkageError: bad method type alias: (R1,R2,R3)String not visible from class java.lang.StringConcatHelper$$StringConcat/0xad1b77c0 at java.base/java.lang.invoke.MemberName.ensureTypeVisible(MemberName.java:812) at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:961) at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:986) ... 44 more record R1() {} record R2(int i, int j) {} record R3(List ls) {} // error record R4(R1 r1, R2 r2, R3 r3) {} This PR also fixes the issue with TRUSTED not working in MemberName.java after using TRUSTED Lookup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1689972638 From liach at openjdk.org Wed Jul 24 15:11:34 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 15:11:34 GMT Subject: RFR: 8336856: Optimize String Concat [v11] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 14:56:48 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1119: >> >>> 1117: >>> 1118: private static MethodHandle generate(Lookup lookup, MethodType args, String[] constants) throws Exception { >>> 1119: lookup = MethodHandles.Lookup.IMPL_LOOKUP; >> >> I think you can try moving the inline copy generation to java.lang's StringConcatHelper; this way, we don't need to expose stringSize, coder etc. through JavaLangAccess (we may update String impl detail in the future) and just access the generated MethodHandle. > > If you do not use TRUSTED Lookup, errors will occur when processing records. > > You can see this build error https://github.com/wenshao/jdk/actions/runs/10049344961/job/27775952878 > > TEST: java/lang/reflect/records/RecordReflectionTest.java > > > Caused by: java.lang.IllegalAccessException: no such method: java.lang.StringConcatHelper$$StringConcat/0xad1b77c0.concat(R1,R2,R3)String/invokeStatic > at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:906) > at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:989) > at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3750) > at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2648) > at java.base/java.lang.invoke.StringConcatFactory$SimpleStringBuilderStrategy.generate(StringConcatFactory.java:727) > ... 41 more > Caused by: java.lang.LinkageError: bad method type alias: (R1,R2,R3)String not visible from class java.lang.StringConcatHelper$$StringConcat/0xad1b77c0 > at java.base/java.lang.invoke.MemberName.ensureTypeVisible(MemberName.java:812) > at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:961) > at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:986) > ... 44 more > > > > record R1() {} > > record R2(int i, int j) {} > > record R3(List ls) {} > > // error > record R4(R1 r1, R2 r2, R3 r3) {} > > > This PR also fixes the issue with TRUSTED not working in MemberName.java after using TRUSTED Lookup. The solution is to call `.erase()` on the input method handle, and call `viewAsType` on the result method handle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1689992258 From bpb at openjdk.org Wed Jul 24 15:36:37 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Jul 2024 15:36:37 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v3] In-Reply-To: References: Message-ID: <8TyR1pTcK9Kx3uuvx7kPzcHmx7uTSPLIdnIcsEZHbyw=.6f38b012-77ba-4420-9b0c-f7907a67135d@github.com> On Tue, 23 Jul 2024 20:58:01 GMT, Naoto Sato wrote: >> This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > apiNote -> implNote Re-reviewed. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20285#pullrequestreview-2197094696 From aph at openjdk.org Wed Jul 24 15:54:35 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Jul 2024 15:54:35 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v6] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Wed, 24 Jul 2024 14:29:09 GMT, Andrew Haley wrote: > I suspect that Klass::search_secondary_supers() won't be inlinined in such case. That's true, but it's true of every other function in that file. Is it not deliberate? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1690061017 From duke at openjdk.org Wed Jul 24 16:00:10 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 16:00:10 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v7] In-Reply-To: References: Message-ID: > [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. Shaojin Wen 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 16 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into merge_store_bench - move to vm.compiler - Merge remote-tracking branch 'upstream/master' into merge_store_bench - Merge remote-tracking branch 'upstream/master' into merge_store_bench - bug fix for `putChars4C` - bug fix for `putChars4C` and `putChars4S` - use VarHandler CHAR_L & CHAR_B - copyright - bug fix for putIntBU - add cases for `getChar` & `putChar` - ... and 6 more: https://git.openjdk.org/jdk/compare/116db649...d00654ff ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19734/files - new: https://git.openjdk.org/jdk/pull/19734/files/74f8837c..d00654ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19734&range=05-06 Stats: 5554 lines in 236 files changed: 3846 ins; 825 del; 883 mod Patch: https://git.openjdk.org/jdk/pull/19734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19734/head:pull/19734 PR: https://git.openjdk.org/jdk/pull/19734 From duke at openjdk.org Wed Jul 24 16:06:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 16:06:34 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v7] In-Reply-To: References: Message-ID: <1Y0ILEKr_XPKokPMaOH8FDP3hU_-_QCVJWezt3KLsF0=.c7f8d7b9-5361-4195-bd82-fc2a46d9649e@github.com> On Wed, 24 Jul 2024 16:00:10 GMT, Shaojin Wen wrote: >> [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. > > Shaojin Wen 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 16 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - move to vm.compiler > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - bug fix for `putChars4C` > - bug fix for `putChars4C` and `putChars4S` > - use VarHandler CHAR_L & CHAR_B > - copyright > - bug fix for putIntBU > - add cases for `getChar` & `putChar` > - ... and 6 more: https://git.openjdk.org/jdk/compare/b54ac578...d00654ff It has been moved to vm/compiler. Can it be approved? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2248386813 From aph at openjdk.org Wed Jul 24 16:17:34 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Jul 2024 16:17:34 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v6] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Wed, 24 Jul 2024 15:51:26 GMT, Andrew Haley wrote: >>> What happens when users include `klass.hpp`, but not `klass.inline.hpp`? How does it affect generated code? >>> >>> I suspect that `Klass::search_secondary_supers()` won't be inlinined in such case. >> >> That is true. I can't tell from this exchange whether you think it should. The same "wont be inlined" fact is also true of everything else in `klass.inline.hpp`. > >> I suspect that Klass::search_secondary_supers() won't be inlinined in such case. > > That's true, but it's true of every other function in that file. Is it not deliberate? FYI, somewhat related: AArch64 GCC inlines `lookup_secondary_supers_table()` 237 times (it's only a few instructions.) x86-64 GCC, because it doesn't use a popcount intrinsic, decides that `lookup_secondary_supers_table()` is too big to be worth inlining in all but 3 cases. So the right thing happens, I think: where we can profit from fast lookups without bloating the runtime, we do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1690096760 From naoto at openjdk.org Wed Jul 24 16:41:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 24 Jul 2024 16:41:32 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v2] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 20:54:08 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. >> >> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2197263736 From naoto at openjdk.org Wed Jul 24 16:41:46 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 24 Jul 2024 16:41:46 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v4] In-Reply-To: References: Message-ID: > This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/java/lang/Process.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/lang/Process.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20285/files - new: https://git.openjdk.org/jdk/pull/20285/files/17c61d99..d3b3c800 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20285&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20285&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20285/head:pull/20285 PR: https://git.openjdk.org/jdk/pull/20285 From naoto at openjdk.org Wed Jul 24 16:41:46 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 24 Jul 2024 16:41:46 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v3] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 20:58:01 GMT, Naoto Sato wrote: >> This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > apiNote -> implNote Thanks for the reviews & suggestions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20285#issuecomment-2248460913 From bpb at openjdk.org Wed Jul 24 16:45:33 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Jul 2024 16:45:33 GMT Subject: RFR: 8336679: Add @implSpec for the default implementations in Process.waitFor() [v4] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 16:41:46 GMT, Naoto Sato wrote: >> This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/Process.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/lang/Process.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20285#pullrequestreview-2197270404 From asemenyuk at openjdk.org Wed Jul 24 16:45:34 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 24 Jul 2024 16:45:34 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 12:20:05 GMT, Vanitha B P wrote: > tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. Changes requested by asemenyuk (Reviewer). @sashamatveev please review test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java line 33: > 31: var lock = new Object(); > 32: synchronized (lock) { > 33: System.out.println("Process id=" + ProcessHandle.current().pid() + " is about to block"); This log message goes nowhere and doesn't make sense. The app launcher is not built with `--win-console` option, so it doesn't have a console, and stdout is not attached to anything that can be captured in the test output. When sketching a workaround in JBS comments section I didn't realize this log message would not be captured in the test output. I'd remove it for simplicity. test/jdk/tools/jpackage/windows/WinChildProcessTest.java line 81: > 79: boolean isAlive = processHandle.isPresent() > 80: && processHandle.get().isAlive(); > 81: System.out.println("Is Alive " + isAlive); This log statement is redundant. The following `TKit.assertTrue()` call produces enough information in the log: [03:45:39.326] TRACE: assertEquals(0): Check command [test\output\WinChildProcessTest\WinChildProcessTest.exe](1) exited with 0 code Is Alive true [03:45:39.326] TRACE: assertTrue(): Check is child process is alive It is irrelevant to this PR and is an oversight from the previous review. However, I believe it is OK to make this small change in this PR. ------------- PR Review: https://git.openjdk.org/jdk/pull/20312#pullrequestreview-2197244491 PR Comment: https://git.openjdk.org/jdk/pull/20312#issuecomment-2248468758 PR Review Comment: https://git.openjdk.org/jdk/pull/20312#discussion_r1690129976 PR Review Comment: https://git.openjdk.org/jdk/pull/20312#discussion_r1690115428 From naoto at openjdk.org Wed Jul 24 16:51:39 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 24 Jul 2024 16:51:39 GMT Subject: Integrated: 8336679: Add @implSpec for the default implementations in Process.waitFor() In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 22:10:07 GMT, Naoto Sato wrote: > This is a simple doc-only change that follows up [JDK-8336479](https://bugs.openjdk.org/browse/JDK-8336479). A corresponding CSR has also been drafted. This pull request has now been integrated. Changeset: 4ea4d7c6 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/4ea4d7c68444200ab38cbd76762c2f27848e264e Stats: 14 lines in 1 file changed: 6 ins; 0 del; 8 mod 8336679: Add @implSpec for the default implementations in Process.waitFor() Reviewed-by: bpb, jlu, liach ------------- PR: https://git.openjdk.org/jdk/pull/20285 From 1dropaflame at gmail.com Wed Jul 24 17:29:54 2024 From: 1dropaflame at gmail.com (Anil) Date: Wed, 24 Jul 2024 12:29:54 -0500 Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: Thank you! I set up ant and IDEA. If I understood you correctly, SDK should not be set at all (screenshot below). [image: image.png] On Tue, Jul 23, 2024 at 6:41?PM Chen Liang wrote: > Hi Anil, > Ant is not a command-line tool of linux; it's an ancient Java build tool > popular 10 years ago, before the appearance of Gradle. Its homepage is at > https://ant.apache.org/ > Once you download, extract it, and add its bin directory to PATH, the > script will find ant automatically. > Chen > > On Tue, Jul 23, 2024 at 6:10?PM Anil <1dropaflame at gmail.com> wrote: > >> Chen, >> Thank you for your reply. >> I am unable to find ant in cygwin64 >> >> anilr at ANIL-LAPTOP /cygdrive/c/users/anil/OpenJDK/jdk >> $ bin/idea.sh >> FATAL: cannot find ant. Try setting ANT_HOME. >> >> When I run setup, I don't see it at all. >> >> >> [image: image.png] >> >> >> >> On Sun, Jul 21, 2024 at 6:46?PM Chen Liang >> wrote: >> >>> Please refer to the "Intellij Idea" section on the ide doc: >>> https://github.com/openjdk/jdk/blob/master/doc/ide.md#intellij-idea >>> In short, in `jdk`, you need to run the `bin/idea.sh` with cygwin after >>> you've done `make images` once. Then the root `jdk` directory will be >>> recognized by idea as an idea project. >>> >>> Note that the guide asks to set the SDK to your images/jdk in the >>> project. Due to problems within Intellij, you should unset the JDK, so the >>> files won't show up a "package xxx already exists in java.base" error. >>> You should set the language level to `X-Experimental features` to mute >>> the warnings about some API usages. >>> And then, you can navigate JDK code as in any other project, such as >>> double-shift and search `Stream` to find the `java.util.stream.Stream` >>> class. >>> And once you are there, you may encounter the bug I've described, that >>> actually used methods will appear as "unused": you will have to type >>> something in one of the method names, like change `filter` to `filter1` so >>> Intellij idea does a reindex and you can find usages of other >>> methods/overrides of the interface. >>> >>> Regards, liach >>> >>> On Sun, Jul 21, 2024 at 2:23?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Chen, >>>> Thanks for your reply. >>>> Yes, I am using IntelliJ Community Edition (on Windows 11, Cygwin64). >>>> I did not set up the project - I just opened the package in IJ >>>> C:\Users\Anil\OpenJDK\jdk\src\java.base\share\classes\java\util\stream >>>> Is there something different I should be doing? >>>> thanks, >>>> Anil >>>> >>>> >>>> On Sat, Jul 20, 2024 at 10:39?PM Chen Liang >>>> wrote: >>>> >>>>> Hi Anil, are you using intellij and setting up the project with >>>>> idea.sh? >>>>> Idea has a bug where its indexing breaks completely; you need to type >>>>> something in the code, like a typo in method name, to force it to refresh. >>>>> >>>>> On Sat, Jul 20, 2024, 9:45?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> I had a small idea on debugging of streams and was trying to >>>>>> implement it to see if it works. >>>>>> I am able to build the OpenJDK (on Windows 11, Cygwin64). >>>>>> However, I am unable to find the implementing class of >>>>>> java.util.Stream. >>>>>> Can you please help? >>>>>> thanks, >>>>>> Anil Philip >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 49860 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23783 bytes Desc: not available URL: From chen.l.liang at oracle.com Wed Jul 24 17:49:29 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Wed, 24 Jul 2024 17:49:29 +0000 Subject: want to try out small idea; where is the implementing class for Stream interface? In-Reply-To: References: Message-ID: Anil, you are correct. The guide says to set the SDK to your built image, but it will make IDEA use your built image (much like how some user processes hold Microsoft Visual Studio when you try to set the short name) and you will have trouble building. Setting the SDK will also introduce extra unrelated compile errors due to project setup. However, there is one scenario where you will need to set the SDK: that is when you have JTReg plugin installed (which you most likely do not, you need to build it yourself) and you wish to run the tests directly, IDE will asks for an SDK, but you can just set any SDK for that purpose as JTReg plugin already uses our images JDK for its configurations. Regards, Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jul 24 18:56:20 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 24 Jul 2024 18:56:20 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v38] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Use primitive right shift for speed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/daef55c3..78c332ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=37 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=36-37 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From rriggs at openjdk.org Wed Jul 24 19:10:33 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 24 Jul 2024 19:10:33 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v4] In-Reply-To: References: Message-ID: <5wSO05QYgsbSjjMkRCGyJTKSXQ_5ZGOBfp5UkXwzIc0=.fa76aa3e-e82d-4174-8001-0d190e645d72@github.com> On Thu, 18 Jul 2024 15:43:05 GMT, Shaojin Wen wrote: >> class LocalTime { >> public String toString() { >> // ... >> if (nanoValue % 1000_000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); >> } else if (nanoValue % 1000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); >> } else { >> buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); >> } >> // ... >> } >> } >> >> Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20232#pullrequestreview-2197566267 From aturbanov at openjdk.org Wed Jul 24 19:12:32 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 24 Jul 2024 19:12:32 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v2] In-Reply-To: References: Message-ID: <-POXdqDTBpENhdR9sDS36AhVHq0ibmliQGzJIYSYoc4=.63c3ec3e-31e7-42cc-8f33-157e8c603d63@github.com> On Tue, 23 Jul 2024 20:54:08 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. >> >> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review src/java.base/share/classes/java/text/NumberFormat.java line 331: > 329: case BigInteger bi when bi.bitLength() < 64 -> format(bi.longValue(), toAppendTo, pos); > 330: case Number n -> format(n.doubleValue(), toAppendTo, pos); > 331: case null, default -> throw new IllegalArgumentException("Cannot format given Object as a Number"); Suggestion: case null, default -> throw new IllegalArgumentException("Cannot format given Object as a Number"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20302#discussion_r1690303087 From vlivanov at openjdk.org Wed Jul 24 19:12:37 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Jul 2024 19:12:37 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v6] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Wed, 24 Jul 2024 09:03:12 GMT, Andrew Haley wrote: >>> Also also, Klass::is_subtype_of() is used for C1 runtime. >> >> Can you elaborate, please? What I'm seeing in `Runtime1::generate_code_for()` for `slow_subtype_check` is a call into `MacroAssembler::check_klass_subtype_slow_path()`. > >> > Also also, Klass::is_subtype_of() is used for C1 runtime. >> >> Can you elaborate, please? > > Sorry, that was rather vague. In C1-compiled code, the Java method `Class::isInstance(Object)`calls `Klass::is_subtype_of()`. > > In general, I find it difficult to decide how much work, if any, should be done to improve C1 performance. Clearly, if C1 exists only to help with startup time in a tiered compilation system, the answer is "not much". Thanks, now I see that `Class::isInstance(Object)` is backed by `Runtime1::is_instance_of()` which uses `oopDesc::is_a()` to do the job. If it turns out to be performance critical, the intrinsic implementation should be rewritten to exercise existing subtype checking support in C1. As it is implemented now, it's already quite inefficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1690303731 From aturbanov at openjdk.org Wed Jul 24 19:13:36 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 24 Jul 2024 19:13:36 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> References: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> Message-ID: On Wed, 24 Jul 2024 13:00:47 GMT, Chen Liang wrote: >> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation. >> >> Depends on #20205. > > Chen Liang has updated the pull request incrementally with three additional commits since the last revision: > > - More refinements from alex > - Artifact -> construct > - More about Annotation, add equals note test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java line 1200: > 1198: case RuntimeVisibleTypeAnnotationsAttribute rvattr -> { > 1199: if (expected.matchVisibility(true)) { > 1200: for(var anno : rvattr.annotations()) { Suggestion: for (var anno : rvattr.annotations()) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1690305951 From bpb at openjdk.org Wed Jul 24 19:19:01 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Jul 2024 19:19:01 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava Message-ID: 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. ------------- Commit messages: - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337143 Stats: 1265 lines in 75 files changed: 631 ins; 523 del; 111 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Wed Jul 24 19:19:01 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Jul 2024 19:19:01 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: <3SJ0NGEh2LCiNc6XEAUta-0MR7aPIJvjw9NIW-xySNo=.9fba6440-4c7a-4e84-806d-12a6a522146f@github.com> On Wed, 24 Jul 2024 19:11:42 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. This change passes CI tiers 1-5 jobs on all platforms. With the change in place, one can remove `libnio` from the JDK and still be able to copy a file using FileChannel. Without the change, doing this will result in throwing a `java.lang.UnsatisfiedLinkError`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2248732983 From liach at openjdk.org Wed Jul 24 19:28:33 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 19:28:33 GMT Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v6] In-Reply-To: References: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com> Message-ID: On Wed, 24 Jul 2024 19:11:18 GMT, Andrey Turbanov wrote: >> Chen Liang has updated the pull request incrementally with three additional commits since the last revision: >> >> - More refinements from alex >> - Artifact -> construct >> - More about Annotation, add equals note > > test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java line 1200: > >> 1198: case RuntimeVisibleTypeAnnotationsAttribute rvattr -> { >> 1199: if (expected.matchVisibility(true)) { >> 1200: for(var anno : rvattr.annotations()) { > > Suggestion: > > for (var anno : rvattr.annotations()) { There are 43 `for(` and 2 `for (` in this file, so fixing a single occurrence isn't too helpful; for consistency I think you can create a dedicated RFE for running IDE formatters over all jdk/classfile tests. I will review it if you submit such a patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20247#discussion_r1690320937 From almatvee at openjdk.org Wed Jul 24 19:28:38 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 24 Jul 2024 19:28:38 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive In-Reply-To: References: Message-ID: <2yyLGb18wArjn5IQAY0qQZ6T0e4GeoGVd0tjQmoSBmQ=.98443da0-b316-48bb-94a1-81865ceb2f2b@github.com> On Wed, 24 Jul 2024 12:20:05 GMT, Vanitha B P wrote: > tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. Looks good. I will approve once comments from Alexey are resolved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20312#issuecomment-2248746951 From jlu at openjdk.org Wed Jul 24 19:45:45 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 24 Jul 2024 19:45:45 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v3] In-Reply-To: References: Message-ID: > As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. > > As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20302/files - new: https://git.openjdk.org/jdk/pull/20302/files/7799b0a6..e9f24bc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20302&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20302.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20302/head:pull/20302 PR: https://git.openjdk.org/jdk/pull/20302 From naoto at openjdk.org Wed Jul 24 19:55:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 24 Jul 2024 19:55:32 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v3] In-Reply-To: References: Message-ID: <78HewAa5utrky-gZR1fZPoy9hZiUKlRbAnTq6qRDK9k=.55d30f4a-b829-4f41-bcb7-8307b1a9914d@github.com> On Wed, 24 Jul 2024 19:45:45 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. >> >> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comment Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2197643624 From liach at openjdk.org Wed Jul 24 20:10:33 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Jul 2024 20:10:33 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v3] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:45:45 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. >> >> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comment Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20302#pullrequestreview-2197671975 From jlu at openjdk.org Wed Jul 24 20:10:35 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 24 Jul 2024 20:10:35 GMT Subject: Integrated: 8336787: Examine java.text.Format API for implSpec usage In-Reply-To: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com> References: <-hhNAfchsyqjKpXmqPa6twkyEZsTHI8K_yFHYS75WU0=.1fdcebc9-4cd6-41f9-bc2c-7a42d94fa202@github.com> Message-ID: On Tue, 23 Jul 2024 17:51:04 GMT, Justin Lu wrote: > As discussed in https://bugs.openjdk.org/browse/JDK-8335834, there are occurrences in the java.text.Format API that would benefit from the implSpec (and apiNote) tag. > > This is a doc-only change, and a CSR has also been filed. > > I did not think "_Subclasses that support fields should override this and create an ..._" sounded right under the `implSpec` tag, and moved it to an `apiNote` tag. This pull request has now been integrated. Changeset: 9e8e3595 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/9e8e359513cf15faf549b12ced947d3a78e544aa Stats: 11 lines in 1 file changed: 5 ins; 5 del; 1 mod 8336787: Examine java.text.Format API for implSpec usage Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/20303 From jlu at openjdk.org Wed Jul 24 20:16:37 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 24 Jul 2024 20:16:37 GMT Subject: RFR: 8336847: Use pattern match switch in NumberFormat classes [v3] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:45:45 GMT, Justin Lu wrote: >> As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. >> >> As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comment Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20302#issuecomment-2248817446 From jlu at openjdk.org Wed Jul 24 20:16:37 2024 From: jlu at openjdk.org (Justin Lu) Date: Wed, 24 Jul 2024 20:16:37 GMT Subject: Integrated: 8336847: Use pattern match switch in NumberFormat classes In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 17:28:02 GMT, Justin Lu wrote: > As discussed in https://github.com/openjdk/jdk/pull/19513#discussion_r1684957942, there is code within java.text.NumberFormat (and subclasses) that can use the pattern match switch to improve readability. > > As this is simply cleanup, there is no regression test added. (Tiers 1-3 and java_text JCK ran to ensure clean migration). This pull request has now been integrated. Changeset: 5a8861a3 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/5a8861a3a1b436ce7414176c095c58c9a1e038d6 Stats: 146 lines in 3 files changed: 3 ins; 28 del; 115 mod 8336847: Use pattern match switch in NumberFormat classes Reviewed-by: liach, naoto ------------- PR: https://git.openjdk.org/jdk/pull/20302 From naoto at openjdk.org Wed Jul 24 20:37:32 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 24 Jul 2024 20:37:32 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v4] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:43:05 GMT, Shaojin Wen wrote: >> class LocalTime { >> public String toString() { >> // ... >> if (nanoValue % 1000_000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); >> } else if (nanoValue % 1000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); >> } else { >> buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); >> } >> // ... >> } >> } >> >> Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20232#pullrequestreview-2197717405 From vlivanov at openjdk.org Wed Jul 24 21:26:39 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Jul 2024 21:26:39 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v6] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Wed, 24 Jul 2024 16:14:47 GMT, Andrew Haley wrote: >>> I suspect that Klass::search_secondary_supers() won't be inlinined in such case. >> >> That's true, but it's true of every other function in that file. Is it not deliberate? > > FYI, somewhat related: AArch64 GCC inlines `lookup_secondary_supers_table()` 237 times (it's only a few instructions.) > x86-64 GCC, because it doesn't use a popcount intrinsic, decides that `lookup_secondary_supers_table()` is too big to be worth inlining in all but 3 cases. So the right thing happens, I think: where we can profit from fast lookups without bloating the runtime, we do. > That's true, but it's true of every other function in that file. Is it not deliberate? IMO the fact that `Klass::search_secondary_supers()` is used in `klass.hpp` makes a difference here. After thinking more about it, I did a small experiment [1] and observed a build failure on AArch64 [2]. I think we don't see any more failures simply because `klass.inline.hpp` is included pervasively. What do you think about moving `Klass::is_subtype_of()` to `klass.inline.hpp`? [1] diff --git a/test/hotspot/gtest/oops/test_klass.cpp b/test/hotspot/gtest/oops/test_klass.cpp new file mode 100644 index 00000000000..326a70f1f54 --- /dev/null +++ b/test/hotspot/gtest/oops/test_klass.cpp @@ -0,0 +1,9 @@ +#include "precompiled.hpp" +#include "oops/klass.hpp" +#include "unittest.hpp" + +TEST_VM(Klass, is_subtype_of) { + Klass* k = vmClasses::Object_klass(); + ASSERT_TRUE(k->is_subtype_of(k)); +} [2] Undefined symbols for architecture arm64: "Klass::search_secondary_supers(Klass*) const", referenced from: Klass_is_subtype_of_vm_Test::TestBody() in test_klass.o ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1690472489 From duke at openjdk.org Wed Jul 24 22:02:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 22:02:34 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v7] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 16:00:10 GMT, Shaojin Wen wrote: >> [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. > > Shaojin Wen 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 16 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - move to vm.compiler > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - bug fix for `putChars4C` > - bug fix for `putChars4C` and `putChars4S` > - use VarHandler CHAR_L & CHAR_B > - copyright > - bug fix for putIntBU > - add cases for `getChar` & `putChar` > - ... and 6 more: https://git.openjdk.org/jdk/compare/e56ab33e...d00654ff Here are the performance numbers running on the new MacBook M1 Pro, * Test scenarios with significant performance improvements Benchmark Mode Cnt Score-Old Score-New Units MergeStoreBench.putChars4BU avgt 15 10266.123 3830.198 * ns/op MergeStoreBench.putChars4LU avgt 15 10266.238 3827.784 * ns/op MergeStoreBench.setIntLU avgt 15 5103.562 2573.624 * ns/op MergeStoreBench.setLongLU avgt 15 10304.012 2921.575 * ns/op MergeStoreBench.setLongRLU avgt 15 10263.975 3241.057 * ns/op * Benchmark Mode Cnt Score-Old Score-New Units MergeStoreBench.getCharB avgt 15 5341.787 5340.200 ns/op MergeStoreBench.getCharBU avgt 15 5477.363 5482.163 ns/op MergeStoreBench.getCharBV avgt 15 5163.099 5074.165 ns/op MergeStoreBench.getCharC avgt 15 5068.708 5051.763 ns/op MergeStoreBench.getCharL avgt 15 5379.821 5374.464 ns/op MergeStoreBench.getCharLU avgt 15 5477.268 5487.532 ns/op MergeStoreBench.getCharLV avgt 15 5079.045 5071.263 ns/op MergeStoreBench.getIntB avgt 15 6276.548 6277.984 ns/op MergeStoreBench.getIntBU avgt 15 5229.813 5232.984 ns/op MergeStoreBench.getIntBV avgt 15 1207.868 1206.264 ns/op MergeStoreBench.getIntL avgt 15 6182.150 6172.779 ns/op MergeStoreBench.getIntLU avgt 15 5164.260 5157.317 ns/op MergeStoreBench.getIntLV avgt 15 2555.443 2558.110 ns/op MergeStoreBench.getIntRB avgt 15 6879.188 6889.916 ns/op MergeStoreBench.getIntRBU avgt 15 5771.857 5769.950 ns/op MergeStoreBench.getIntRL avgt 15 6625.754 6625.605 ns/op MergeStoreBench.getIntRLU avgt 15 5746.554 5746.742 ns/op MergeStoreBench.getIntRU avgt 15 2547.449 2544.586 ns/op MergeStoreBench.getIntU avgt 15 2543.552 2541.119 ns/op MergeStoreBench.getLongB avgt 15 12099.002 12098.129 ns/op MergeStoreBench.getLongBU avgt 15 9771.893 9760.621 ns/op MergeStoreBench.getLongBV avgt 15 2593.835 2593.635 ns/op MergeStoreBench.getLongL avgt 15 12045.235 12031.065 ns/op MergeStoreBench.getLongLU avgt 15 9659.585 9653.938 ns/op MergeStoreBench.getLongLV avgt 15 2561.089 2557.521 ns/op MergeStoreBench.getLongRB avgt 15 12095.060 12092.061 ns/op MergeStoreBench.getLongRBU avgt 15 9767.943 9763.489 ns/op MergeStoreBench.getLongRL avgt 15 12037.935 12027.686 ns/op MergeStoreBench.getLongRLU avgt 15 9655.918 9649.433 ns/op MergeStoreBench.getLongRU avgt 15 2551.109 2546.239 ns/op MergeStoreBench.getLongU avgt 15 2543.732 2539.762 ns/op MergeStoreBench.putChars4B avgt 15 8499.750 8487.381 ns/op MergeStoreBench.putChars4BU avgt 15 10266.123 3830.198 * ns/op MergeStoreBench.putChars4BV avgt 15 5153.418 5154.819 ns/op MergeStoreBench.putChars4C avgt 15 5141.336 5162.766 ns/op MergeStoreBench.putChars4L avgt 15 8382.747 8381.231 ns/op MergeStoreBench.putChars4LU avgt 15 10266.238 3827.784 * ns/op MergeStoreBench.putChars4LV avgt 15 5150.613 5151.508 ns/op MergeStoreBench.putChars4S avgt 15 5144.843 5152.123 ns/op MergeStoreBench.setCharBS avgt 15 5318.051 5317.319 ns/op MergeStoreBench.setCharBV avgt 15 5187.295 5175.400 ns/op MergeStoreBench.setCharC avgt 15 5093.774 5085.752 ns/op MergeStoreBench.setCharLS avgt 15 5301.267 5294.766 ns/op MergeStoreBench.setCharLV avgt 15 5116.066 5108.269 ns/op MergeStoreBench.setIntB avgt 15 5104.537 5095.236 ns/op MergeStoreBench.setIntBU avgt 15 5104.838 5097.007 ns/op MergeStoreBench.setIntBV avgt 15 1228.375 1224.506 ns/op MergeStoreBench.setIntL avgt 15 2772.278 2764.388 ns/op MergeStoreBench.setIntLU avgt 15 5103.562 2573.624 * ns/op MergeStoreBench.setIntLV avgt 15 5112.770 5105.804 ns/op MergeStoreBench.setIntRB avgt 15 5356.946 5348.785 ns/op MergeStoreBench.setIntRBU avgt 15 5420.478 5422.049 ns/op MergeStoreBench.setIntRL avgt 15 5297.975 5293.414 ns/op MergeStoreBench.setIntRLU avgt 15 5418.844 5126.889 ns/op MergeStoreBench.setIntRU avgt 15 5108.486 5097.927 ns/op MergeStoreBench.setIntU avgt 15 5091.868 5087.192 ns/op MergeStoreBench.setLongB avgt 15 10273.648 10249.037 ns/op MergeStoreBench.setLongBU avgt 15 10271.248 10238.910 ns/op MergeStoreBench.setLongBV avgt 15 2667.768 2663.647 ns/op MergeStoreBench.setLongL avgt 15 6316.791 6304.458 ns/op MergeStoreBench.setLongLU avgt 15 10304.012 2921.575 * ns/op MergeStoreBench.setLongLV avgt 15 2667.648 2663.323 ns/op MergeStoreBench.setLongRB avgt 15 10269.238 10255.875 ns/op MergeStoreBench.setLongRBU avgt 15 10272.547 10227.856 ns/op MergeStoreBench.setLongRL avgt 15 6651.182 6641.173 ns/op MergeStoreBench.setLongRLU avgt 15 10263.975 3241.057 * ns/op MergeStoreBench.setLongRU avgt 15 2621.004 2608.399 ns/op MergeStoreBench.setLongU avgt 15 2606.578 2594.970 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2248969570 From duke at openjdk.org Wed Jul 24 22:19:53 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 22:19:53 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v16] In-Reply-To: References: Message-ID: > After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores. > > This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2. Shaojin Wen 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 17 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406 - replace unsafe with putChar - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406 - private static final field `UNSAFE` - Utf16 case remove `append first utf16 char` - `delete` -> `setLength` - copyright 2024 - optimization for x64 - rename benchmark - code format & use long address - ... and 7 more: https://git.openjdk.org/jdk/compare/8d29efdf...d2dcc24d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19626/files - new: https://git.openjdk.org/jdk/pull/19626/files/9d9c8eb8..d2dcc24d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=14-15 Stats: 5553 lines in 235 files changed: 3846 ins; 825 del; 882 mod Patch: https://git.openjdk.org/jdk/pull/19626.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626 PR: https://git.openjdk.org/jdk/pull/19626 From duke at openjdk.org Wed Jul 24 22:38:32 2024 From: duke at openjdk.org (duke) Date: Wed, 24 Jul 2024 22:38:32 GMT Subject: RFR: 8336741: Optimize LocalTime.toString with StringBuilder.repeat [v4] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:43:05 GMT, Shaojin Wen wrote: >> class LocalTime { >> public String toString() { >> // ... >> if (nanoValue % 1000_000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); >> } else if (nanoValue % 1000 == 0) { >> buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); >> } else { >> buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); >> } >> // ... >> } >> } >> >> Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright @wenshao Your change (at version d930eb376c3077d449400e438059f372efa26f7f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20232#issuecomment-2249009049 From duke at openjdk.org Wed Jul 24 22:42:38 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 22:42:38 GMT Subject: Integrated: 8336741: Optimize LocalTime.toString with StringBuilder.repeat In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:32:47 GMT, Shaojin Wen wrote: > class LocalTime { > public String toString() { > // ... > if (nanoValue % 1000_000 == 0) { > buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1)); > } else if (nanoValue % 1000 == 0) { > buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1)); > } else { > buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1)); > } > // ... > } > } > > Currently, LocalTime.toString handles nanos by adding a value and then subString(1) to fill it with zeros. Using StringBuilder.repeat is more concise and has better performance. This pull request has now been integrated. Changeset: 0898ab7f Author: Shaojin Wen Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/0898ab7f7496689e5de52a5dc4530ca21def1fca Stats: 164 lines in 3 files changed: 158 ins; 0 del; 6 mod 8336741: Optimize LocalTime.toString with StringBuilder.repeat Reviewed-by: liach, rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/20232 From duke at openjdk.org Wed Jul 24 23:39:36 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 24 Jul 2024 23:39:36 GMT Subject: RFR: 8336856: Optimize String Concat [v5] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 13:35:41 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge remote-tracking branch 'origin/optim_simple_concat_202407' into optim_concat_factory_202407 >> >> # Conflicts: >> # src/java.base/share/classes/java/lang/StringConcatHelper.java >> # src/java.base/share/classes/java/lang/System.java >> # src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java >> - reduce change & refactor >> - fix TRUSTED not work >> - non-MH-based implementation >> - non-MH-based implementation >> - optimize string concat > > While a reasonable start I'd suggest: > > - adding a flag to switch over to the new implementation and leaving the existing strategy in place initially, then when we have something that is superior in every way we can clean out the old strategy > - AFAICT this mimics the `SimpleStringBuilderStrategy` and generates and installs a new class for each expression. This is likely fine for high-arity concatenations which are likely to be one-of-a-kind (the sort of expressions the `SimpleStringBuilderStrategy` was brought back to life for), but could generate a proliferation of classes for low-arity expressions. Instead we probably need to aim for sharing > - such shareable classes could be made simpler if we put them in java.lang so that they can link directly with package private methods in `StringConcatHelper` and `String` rather than using trusted `MethodHandles` to cross such boundaries > > Again: I am working on and have a prototype for this which I aim to present and discuss in two weeks as JVMLS. I appreciate the effort here, but I'll need to focus on my talk and prototype for now. Now, according to @cl4es's suggestion, this is just an improvement to the original SimpleStringBuilderStrategy's bytecode-spinning implementation, which will be used when HIGH_ARITY_THRESHOLD is reached. Such an improvement will be very low risk. Now the question is, the default HIGH_ARITY_THRESHOLD is 20, which is too large. Should it be reduced, such as 8? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2249066313 From bpb at openjdk.org Thu Jul 25 00:29:56 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 25 Jul 2024 00:29:56 GMT Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer Message-ID: Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively. ------------- Commit messages: - 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer Changes: https://git.openjdk.org/jdk/pull/20320/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336895 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20320/head:pull/20320 PR: https://git.openjdk.org/jdk/pull/20320 From duke at openjdk.org Thu Jul 25 00:40:00 2024 From: duke at openjdk.org (fabioromano1) Date: Thu, 25 Jul 2024 00:40:00 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v39] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimized division by 2*sqrt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/78c332ac..96582ee5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=37-38 Stats: 12 lines in 1 file changed: 6 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Thu Jul 25 00:45:39 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 00:45:39 GMT Subject: RFR: 8336856: Optimize String Concat [v11] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 15:08:50 GMT, Chen Liang wrote: >> If you do not use TRUSTED Lookup, errors will occur when processing records. >> >> You can see this build error https://github.com/wenshao/jdk/actions/runs/10049344961/job/27775952878 >> >> TEST: java/lang/reflect/records/RecordReflectionTest.java >> >> >> Caused by: java.lang.IllegalAccessException: no such method: java.lang.StringConcatHelper$$StringConcat/0xad1b77c0.concat(R1,R2,R3)String/invokeStatic >> at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:906) >> at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:989) >> at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3750) >> at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2648) >> at java.base/java.lang.invoke.StringConcatFactory$SimpleStringBuilderStrategy.generate(StringConcatFactory.java:727) >> ... 41 more >> Caused by: java.lang.LinkageError: bad method type alias: (R1,R2,R3)String not visible from class java.lang.StringConcatHelper$$StringConcat/0xad1b77c0 >> at java.base/java.lang.invoke.MemberName.ensureTypeVisible(MemberName.java:812) >> at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:961) >> at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:986) >> ... 44 more >> >> >> >> record R1() {} >> >> record R2(int i, int j) {} >> >> record R3(List ls) {} >> >> // error >> record R4(R1 r1, R2 r2, R3 r3) {} >> >> >> This PR also fixes the issue with TRUSTED not working in MemberName.java after using TRUSTED Lookup. > > The solution is to call `.erase()` on the input method handle, and call `viewAsType` on the result method handle. Sorry, I don't understand what you mean. The following code can't solve the above build error public static CallSite makeConcatWithConstants() { // line 383 return new ConstantCallSite( SimpleStringBuilderStrategy.generate(lookup, concatType, constantStrings) .viewAsType(concatType, true)); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1690626588 From duke at openjdk.org Thu Jul 25 01:17:38 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 01:17:38 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v4] In-Reply-To: References: <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com> <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com> Message-ID: On Wed, 26 Jun 2024 14:39:57 GMT, Emanuel Peter wrote: >>> I filed: >>> >>> [JDK-8335113](https://bugs.openjdk.org/browse/JDK-8335113): C2 MergeStores: allow merging of putChar and other larger stores on smaller array elements >> >> Great! Should we hold off on this optimization and see if we can avoid the need for `Unsafe` here - or go ahead integrating this PR and leave it to JDK-8335113 to revert any no-longer-needed changes made here? > > @cl4es I would wait, to be honest. I'm currently quite busy, but I hope I can do something here in the next 2-3 weeks. @eme64 Unsafe.putByte MergeStore of master branch doesn't work import sun.misc.Unsafe; public class PutBytesTest { static final Unsafe UNSAFE = JDKUtils.UNSAFE; // MergeStore not work static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) { putByte(val, index , (byte)(c1)); putByte(val, index + 1, (byte)(c2)); putByte(val, index + 2, (byte)(c3)); putByte(val, index + 3, (byte)(c4)); } // MergeStore work static void putCharsAtArrayStore(byte[] val, int index, int c1, int c2, int c3, int c4) { val[index] = (byte) c1; val[index + 1] = (byte) c2; val[index + 2] = (byte) c3; val[index + 3] = (byte) c4; } static void putByte(byte[] bytes, int index, byte c) { UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + index, c); } static void putNull(byte[] bytes, int index) { putCharsAt(bytes, index, 'n', 'u', 'l', 'l'); } public static void main(String[] args) { for (int i = 0; i < 5; i++) { testNull(); } System.out.println("done"); } private static void testNull() { byte[] bytes = new byte[4096]; for (int i = 0; i < 1000; i++) { int index = 0; for (int j = 0; j < 1024; j++) { putNull(bytes, index); index += 4; } } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2249171446 From syan at openjdk.org Thu Jul 25 01:49:32 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Jul 2024 01:49:32 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v2] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Wed, 26 Jun 2024 15:40:36 GMT, SendaoYan wrote: >> Hi all, >> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. >> >> Only change the testcase, the change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > add a word throw Hi, is there anyone take look this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2249202447 From jpai at openjdk.org Thu Jul 25 04:56:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 25 Jul 2024 04:56:31 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v2] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: <4F-ICMQFz9hNXdp4xAR6Jtb1IEipGiMeYvllgjKRy1Q=.8df3091e-4842-43eb-8e1a-d9f8a88de40d@github.com> On Wed, 26 Jun 2024 15:40:36 GMT, SendaoYan wrote: >> Hi all, >> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. >> >> Only change the testcase, the change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > add a word throw test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java line 216: > 214: } catch (IOException e) { > 215: if (e.getMessage().contains("Mount point not found")) { > 216: // We would like to skip the test with a cause with Hello @sendaoYan, it feels very specific and odd to be checking only for this exception message. This test method's goal appears to be to create a read-only directory into which it wants to write out the proxy classes and verify that it won't be able to do that. For that it first verifies that the underlying `FileStore` supports posix file attributes. If it's not able to ascertain that the underlying `FileStore` has posix support, then it skips the test. So I think we should just catch the `IOException` here when getting the FileStore and skip the test instead of checking for specific exception messages. While we are at it, we should throw a `org.testng.SkipException` (this is a testng test) from this method wherever we are currently skipping the test execution by writing out a System.out warning message and returning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19905#discussion_r1690807453 From alanb at openjdk.org Thu Jul 25 05:01:41 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 05:01:41 GMT Subject: Integrated: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 This pull request has now been integrated. Changeset: 6e228ce3 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/6e228ce382d1fad6cba0d0df8a507e6bd32a9a4a Stats: 4114 lines in 42 files changed: 2528 ins; 1150 del; 436 mod 8336254: Virtual thread implementation + test updates Reviewed-by: sspitsyn, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/20143 From duke at openjdk.org Thu Jul 25 05:40:00 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 05:40:00 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString Message-ID: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. ------------- Commit messages: - optimize LocalDateTime.toString, reduce StringBuilder allocate Changes: https://git.openjdk.org/jdk/pull/20321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337168 Stats: 26 lines in 3 files changed: 15 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20321/head:pull/20321 PR: https://git.openjdk.org/jdk/pull/20321 From duke at openjdk.org Thu Jul 25 05:40:06 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 05:40:06 GMT Subject: RFR: 8337167: StringSize deduplication Message-ID: Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. ------------- Commit messages: - stringSize deduplication Changes: https://git.openjdk.org/jdk/pull/20322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337167 Stats: 99 lines in 8 files changed: 32 ins; 57 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/20322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20322/head:pull/20322 PR: https://git.openjdk.org/jdk/pull/20322 From epeter at openjdk.org Thu Jul 25 06:19:37 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 25 Jul 2024 06:19:37 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v7] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 16:00:10 GMT, Shaojin Wen wrote: >> [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. > > Shaojin Wen 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 16 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - move to vm.compiler > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - bug fix for `putChars4C` > - bug fix for `putChars4C` and `putChars4S` > - use VarHandler CHAR_L & CHAR_B > - copyright > - bug fix for putIntBU > - add cases for `getChar` & `putChar` > - ... and 6 more: https://git.openjdk.org/jdk/compare/1669617e...d00654ff Looks good to me. Thanks for creating this benchmark! I'll definitely use it soon, when I try to extend MergeStores to more cases :) ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19734#pullrequestreview-2198398556 From duke at openjdk.org Thu Jul 25 06:22:30 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 06:22:30 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: On Thu, 25 Jul 2024 05:06:17 GMT, Shaojin Wen wrote: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. Below are the performance numbers running on a MacBook M1 Max, which increased speed by +179.88% -# master 05d88de05e9b7814ecd5517aacd17f0feafdff3c -Benchmark Mode Cnt Score Error Units -ToStringBench.localDateTimeToString thrpt 15 4.896 ? 1.414 ops/ms +# current c03ed26ffdf2cebcc9074c2aeae27fbb1f49c025 +Benchmark Mode Cnt Score Error Units +ToStringBench.localDateTimeToString thrpt 15 13.703 ? 1.960 ops/ms +179.88% ------------- PR Comment: https://git.openjdk.org/jdk/pull/20321#issuecomment-2249546065 From duke at openjdk.org Thu Jul 25 06:27:34 2024 From: duke at openjdk.org (duke) Date: Thu, 25 Jul 2024 06:27:34 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v7] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 16:00:10 GMT, Shaojin Wen wrote: >> [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. > > Shaojin Wen 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 16 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - move to vm.compiler > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - bug fix for `putChars4C` > - bug fix for `putChars4C` and `putChars4S` > - use VarHandler CHAR_L & CHAR_B > - copyright > - bug fix for putIntBU > - add cases for `getChar` & `putChar` > - ... and 6 more: https://git.openjdk.org/jdk/compare/364c3621...d00654ff @wenshao Your change (at version d00654ffddecd32aaad470e4268ddb9e16879855) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2249552223 From duke at openjdk.org Thu Jul 25 08:40:44 2024 From: duke at openjdk.org (Vanitha B P) Date: Thu, 25 Jul 2024 08:40:44 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive [v2] In-Reply-To: References: Message-ID: > tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Addressed the review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20312/files - new: https://git.openjdk.org/jdk/pull/20312/files/5a2dcd3d..d3cae3b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20312&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20312&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20312/head:pull/20312 PR: https://git.openjdk.org/jdk/pull/20312 From duke at openjdk.org Thu Jul 25 08:41:07 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 08:41:07 GMT Subject: RFR: 8336856: Optimize String Concat [v14] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Descending mixer, same order as prepend ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/a0cdef4d..e430a417 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=12-13 Stats: 21 lines in 1 file changed: 3 ins; 9 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From epeter at openjdk.org Thu Jul 25 08:45:35 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 25 Jul 2024 08:45:35 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v7] In-Reply-To: References: Message-ID: <_9EEUIF5MpPibEHmMK2AEwenfs83UkWBkpe3NoJVhZI=.9ee99a0b-862d-45e9-b142-b5acaa5a1e44@github.com> On Wed, 24 Jul 2024 21:59:52 GMT, Shaojin Wen wrote: >> Shaojin Wen 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 16 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into merge_store_bench >> - move to vm.compiler >> - Merge remote-tracking branch 'upstream/master' into merge_store_bench >> - Merge remote-tracking branch 'upstream/master' into merge_store_bench >> - bug fix for `putChars4C` >> - bug fix for `putChars4C` and `putChars4S` >> - use VarHandler CHAR_L & CHAR_B >> - copyright >> - bug fix for putIntBU >> - add cases for `getChar` & `putChar` >> - ... and 6 more: https://git.openjdk.org/jdk/compare/19a79110...d00654ff > > Here are the performance numbers running on the new MacBook M1 Pro, > > * Test scenarios with significant performance improvements > > Benchmark Mode Cnt Score-Old Score-New Units > MergeStoreBench.putChars4BU avgt 15 10266.123 3830.198 * ns/op > MergeStoreBench.putChars4LU avgt 15 10266.238 3827.784 * ns/op > MergeStoreBench.setIntLU avgt 15 5103.562 2573.624 * ns/op > MergeStoreBench.setLongLU avgt 15 10304.012 2921.575 * ns/op > MergeStoreBench.setLongRLU avgt 15 10263.975 3241.057 * ns/op > > > * > > Benchmark Mode Cnt Score-Old Score-New Units > MergeStoreBench.getCharB avgt 15 5341.787 5340.200 ns/op > MergeStoreBench.getCharBU avgt 15 5477.363 5482.163 ns/op > MergeStoreBench.getCharBV avgt 15 5163.099 5074.165 ns/op > MergeStoreBench.getCharC avgt 15 5068.708 5051.763 ns/op > MergeStoreBench.getCharL avgt 15 5379.821 5374.464 ns/op > MergeStoreBench.getCharLU avgt 15 5477.268 5487.532 ns/op > MergeStoreBench.getCharLV avgt 15 5079.045 5071.263 ns/op > MergeStoreBench.getIntB avgt 15 6276.548 6277.984 ns/op > MergeStoreBench.getIntBU avgt 15 5229.813 5232.984 ns/op > MergeStoreBench.getIntBV avgt 15 1207.868 1206.264 ns/op > MergeStoreBench.getIntL avgt 15 6182.150 6172.779 ns/op > MergeStoreBench.getIntLU avgt 15 5164.260 5157.317 ns/op > MergeStoreBench.getIntLV avgt 15 2555.443 2558.110 ns/op > MergeStoreBench.getIntRB avgt 15 6879.188 6889.916 ns/op > MergeStoreBench.getIntRBU avgt 15 5771.857 5769.950 ns/op > MergeStoreBench.getIntRL avgt 15 6625.754 6625.605 ns/op > MergeStoreBench.getIntRLU avgt 15 5746.554 5746.742 ns/op > MergeStoreBench.getIntRU avgt 15 2547.449 2544.586 ns/op > MergeStoreBench.getIntU avgt 15 2543.552 2541.119 ns/op > MergeStoreBench.getLongB avgt 15 12099.002 12098.129 ns/op > MergeStoreBench.getLongBU avgt 15 9771.893 9760.621 ns/op > MergeStoreBench.getLongBV avgt 15 2593.835 2593.635 ns/op > MergeStoreBench.getLongL avgt 15 12045.235 12031.065 ns/op > MergeStoreBench.getLongLU avgt 15 9659.585 9653.938 ns/op > MergeStoreBench.getLongLV avgt 15 2561.089 2557.521 ns/op > MergeStoreBench.getLongRB avgt 15 12095.060 12092.061... @wenshao generally we like to have at least 2 reviews before integration ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19734#issuecomment-2249791741 From duke at openjdk.org Thu Jul 25 08:58:14 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 08:58:14 GMT Subject: RFR: 8336856: Optimize String Concat [v15] In-Reply-To: References: Message-ID: <0EQa3rOXnTed-C0CAgTBAcNGn1hEpF9oRngYdp_yWAw=.d03d88dc-c4aa-4a2e-830d-84b51f1fc156@github.com> > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: add benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/e430a417..00fcd554 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=13-14 Stats: 141 lines in 2 files changed: 141 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From thartmann at openjdk.org Thu Jul 25 09:19:45 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 25 Jul 2024 09:19:45 GMT Subject: RFR: 8334342: Add MergeStore JMH benchmarks [v7] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 16:00:10 GMT, Shaojin Wen wrote: >> [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. > > Shaojin Wen 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 16 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - move to vm.compiler > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - Merge remote-tracking branch 'upstream/master' into merge_store_bench > - bug fix for `putChars4C` > - bug fix for `putChars4C` and `putChars4S` > - use VarHandler CHAR_L & CHAR_B > - copyright > - bug fix for putIntBU > - add cases for `getChar` & `putChar` > - ... and 6 more: https://git.openjdk.org/jdk/compare/3610715a...d00654ff Looks good to me too. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19734#pullrequestreview-2198766610 From duke at openjdk.org Thu Jul 25 09:19:46 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 09:19:46 GMT Subject: Integrated: 8334342: Add MergeStore JMH benchmarks In-Reply-To: References: Message-ID: <6FY6g75AM558_a7HMcMYcKSij_zj-2NYLttPP-VWsAM=.1e914eaa-d44a-4391-a8d4-c0fae994d46a@github.com> On Sun, 16 Jun 2024 07:17:16 GMT, Shaojin Wen wrote: > [8318446](https://github.com/openjdk/jdk/pull/16245) brings MergeStore. We need a JMH Benchmark to evaluate the performance of various batch operations and the effect of MergeStore. This pull request has now been integrated. Changeset: 8081f870 Author: Shaojin Wen Committer: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/8081f8702a89c4895302377be62da22fc34f2c74 Stats: 1132 lines in 1 file changed: 1132 ins; 0 del; 0 mod 8334342: Add MergeStore JMH benchmarks Reviewed-by: epeter, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/19734 From syan at openjdk.org Thu Jul 25 09:50:10 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Jul 2024 09:50:10 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: > Hi all, > Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. > > Only change the testcase, the change has been verified locally, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: 1. Just catch the IOException here when getting the FileStore and skip the test instead of checking for specific exception messages. 2. Throw a org.testng.SkipException instead print and return ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19905/files - new: https://git.openjdk.org/jdk/pull/19905/files/8931debe..9c7946f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19905&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19905&range=01-02 Stats: 17 lines in 1 file changed: 1 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/19905.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19905/head:pull/19905 PR: https://git.openjdk.org/jdk/pull/19905 From liach at openjdk.org Thu Jul 25 09:51:34 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 09:51:34 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: On Thu, 25 Jul 2024 05:06:17 GMT, Shaojin Wen wrote: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. Simple and straightforward improvement. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20321#pullrequestreview-2198838834 From syan at openjdk.org Thu Jul 25 09:54:37 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Jul 2024 09:54:37 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v2] In-Reply-To: <4F-ICMQFz9hNXdp4xAR6Jtb1IEipGiMeYvllgjKRy1Q=.8df3091e-4842-43eb-8e1a-d9f8a88de40d@github.com> References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> <4F-ICMQFz9hNXdp4xAR6Jtb1IEipGiMeYvllgjKRy1Q=.8df3091e-4842-43eb-8e1a-d9f8a88de40d@github.com> Message-ID: On Thu, 25 Jul 2024 04:53:33 GMT, Jaikiran Pai wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> add a word throw > > test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java line 216: > >> 214: } catch (IOException e) { >> 215: if (e.getMessage().contains("Mount point not found")) { >> 216: // We would like to skip the test with a cause with > > Hello @sendaoYan, it feels very specific and odd to be checking only for this exception message. This test method's goal appears to be to create a read-only directory into which it wants to write out the proxy classes and verify that it won't be able to do that. For that it first verifies that the underlying `FileStore` supports posix file attributes. If it's not able to ascertain that the underlying `FileStore` has posix support, then it skips the test. > > So I think we should just catch the `IOException` here when getting the FileStore and skip the test instead of checking for specific exception messages. While we are at it, we should throw a `org.testng.SkipException` (this is a testng test) from this method wherever we are currently skipping the test execution by writing out a System.out warning message and returning. Thanks for your advice, the checking for specific exception messages has been replaced to just catch the IOException when getting the FileStore, and all the `System.out warning message and returning` has been replaced to `org.testng.SkipException`. Additional, the `org.testng.SkipException` seems do not work normally in [jtreg](https://bugs.openjdk.org/browse/CODETOOLS-7903708) for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19905#discussion_r1691168794 From alanb at openjdk.org Thu Jul 25 10:07:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 10:07:32 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com> On Wed, 24 Jul 2024 19:11:42 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. I think this will require thinking about how to organize the native code in native/libjava as it hard to maintain if everything is in the same directory. We may have to create subdirectories, as we do in native/libnio. Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2249958450 From redestad at openjdk.org Thu Jul 25 10:17:33 2024 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 25 Jul 2024 10:17:33 GMT Subject: RFR: 8336856: Optimize String Concat [v15] In-Reply-To: <0EQa3rOXnTed-C0CAgTBAcNGn1hEpF9oRngYdp_yWAw=.d03d88dc-c4aa-4a2e-830d-84b51f1fc156@github.com> References: <0EQa3rOXnTed-C0CAgTBAcNGn1hEpF9oRngYdp_yWAw=.d03d88dc-c4aa-4a2e-830d-84b51f1fc156@github.com> Message-ID: On Thu, 25 Jul 2024 08:58:14 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > add benchmark test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47: > 45: @Measurement(iterations = 5, time = 1000, timeUnit = TimeUnit.MILLISECONDS) > 46: @Fork(value = 3, jvmArgsAppend = "-Djava.lang.invoke.StringConcat.highArityThreshold=0") > 47: public class StringConcatGenerate extends StringConcat { Adding a subclass with an overridden `@Fork` to pass a different `jvmArgsAppend` is a reasonable trick, but could be moved to a nested class within `StringConcat` to keep it in the same context. I'm not sure if this micro brings a persistent added value, though: for experimentation we can just run `StringConcat` with different `-Djava.lang.invoke.StringConcat.highArityThreshold` settings, while for continuous regression testing we're more interested in validating the default settings. Supplying the new `main` method doesn't add anything here, either, since a standalone execution wouldn't pick up the `jvmArgsAppend` value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1691205621 From alanb at openjdk.org Thu Jul 25 10:26:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 10:26:32 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 09:50:10 GMT, SendaoYan wrote: >> Hi all, >> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. >> >> Only change the testcase, the change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 1. Just catch the IOException here when getting the FileStore and skip the test instead of checking for specific exception messages. 2. Throw a org.testng.SkipException instead print and return Would it possible to provide a summary on how Mock works and how we end up with the current directory in a location that doesn't have a mount point? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2249991703 From liach at openjdk.org Thu Jul 25 10:49:33 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 10:49:33 GMT Subject: RFR: 8337167: StringSize deduplication In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 05:30:34 GMT, Shaojin Wen wrote: > Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. src/java.base/share/classes/java/lang/Integer.java line 472: > 470: * code after loop unrolling. > 471: */ > 472: static int stringSize(int x) { Same question, if we can just inline this src/java.base/share/classes/java/lang/Long.java line 502: > 500: * code after loop unrolling. > 501: */ > 502: static int stringSize(long x) { Can we just remove this method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20322#discussion_r1691241572 PR Review Comment: https://git.openjdk.org/jdk/pull/20322#discussion_r1691240301 From jvernee at openjdk.org Thu Jul 25 11:03:39 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 25 Jul 2024 11:03:39 GMT Subject: RFR: 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled Message-ID: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> We are seeing some failures of this test in our CI, particularly on Windows machines, which are known to starve out certain threads. To make sure the compiler threads get a chance to work, I've added `-Xbatch` to the flags with which the test runs (this was missed in the original PR). I've also removed the timeout from the `awaitCompilation` method. The intent is to instead rely on the overall test's timeout, which can also be adjusted with a timeout factor for slower machines, rather than putting an absolute time limit on the compilation. Finally, Alan asked me to increase the timeout for the executor shutdown, since there have also been some timeouts there. The current timeout is borrowed from `test/jdk/java/foreign/TestHandshake`, but that test uses a lot less threads, so it can probably get await with waiting just 20 seconds. Testing: I ran this 200s time in Oracle CI, half of the runs were with `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:-VerifyContinuations` (which is one of the failing configurations). ------------- Commit messages: - use -Xbatch + rely on test timeout Changes: https://git.openjdk.org/jdk/pull/20325/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20325&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337060 Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20325/head:pull/20325 PR: https://git.openjdk.org/jdk/pull/20325 From mcimadamore at openjdk.org Thu Jul 25 11:40:34 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 25 Jul 2024 11:40:34 GMT Subject: RFR: 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled In-Reply-To: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> References: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> Message-ID: On Thu, 25 Jul 2024 10:58:42 GMT, Jorn Vernee wrote: > We are seeing some failures of this test in our CI, particularly on Windows machines, which are known to starve out certain threads. > > To make sure the compiler threads get a chance to work, I've added `-Xbatch` to the flags with which the test runs (this was missed in the original PR). I've also removed the timeout from the `awaitCompilation` method. The intent is to instead rely on the overall test's timeout, which can also be adjusted with a timeout factor for slower machines, rather than putting an absolute time limit on the compilation. > > Finally, Alan asked me to increase the timeout for the executor shutdown, since there have also been some timeouts there. The current timeout is borrowed from `test/jdk/java/foreign/TestHandshake`, but that test uses a lot less threads, so it can probably get await with waiting just 20 seconds. > > Testing: I ran this 200s time in Oracle CI, half of the runs were with `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:-VerifyContinuations` (which is one of the failing configurations). Looks good. ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20325#pullrequestreview-2199057092 From chen.l.liang at oracle.com Thu Jul 25 11:57:17 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 25 Jul 2024 11:57:17 +0000 Subject: Should the documentation state peekFirst() as equivalent to Stack's peek()? In-Reply-To: References: Message-ID: Hi Turkhan, this mail belongs to core-libs-dev list. I have forwarded your mail to the right list. Indeed, we should claim that peek() is equivalent to peekFirst(); the information in stack section should be a typo, as peek() being the same as peekFirst() is claimed by the deque section and the peek() specification. I have created a ticket on the Java Bug System to track this issue: [JDK-8337205] Typo in Stack vs Deque Method table in Deque specification - Java Bug System (openjdk.org) Feel free to open a pull request to jdk to fix this bug. Best, Chen Liang ________________________________ From: jdk-dev on behalf of Turkhan Badalov Sent: Thursday, July 25, 2024 4:58 AM To: jdk-dev at openjdk.org Subject: Should the documentation state peekFirst() as equivalent to Stack's peek()? Here is the table "Comparison of Stack and Deque methods" that lists equivalent Deque methods compared to Stack methods: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html At the moment, getFirst() is said to be equivalent to peek(). Since peek() doesn't throw an exception when the queue/stack is empty, peekFirst() could be a better equivalent because getFirst() throws. In fact, the documentation of the peek() method itself says that this method is equivalent to peekFirst(): https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html#peek(). If this should be posted somewhere else, please let me know. I am still new to using mailing lists. Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Thu Jul 25 12:10:32 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 12:10:32 GMT Subject: RFR: 8337167: StringSize deduplication In-Reply-To: References: Message-ID: <0jfG7iylc5mEUNCqLypLo0C8vFa8gkC3M6xE9YIBXTI=.f4381069-ebad-4fc3-9564-46aba582ade5@github.com> On Thu, 25 Jul 2024 05:30:34 GMT, Shaojin Wen wrote: > Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 462: > 460: > 461: int stringSize(long i); > 462: ? Removing extra dependencies on `JavaLangAccess` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20322#discussion_r1691333555 From syan at openjdk.org Thu Jul 25 12:42:31 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Jul 2024 12:42:31 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 10:23:29 GMT, Alan Bateman wrote: > Would it possible to provide a summary on how Mock works and how we end up with the current directory in a location that doesn't have a mount point? The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails. ![image](https://github.com/user-attachments/assets/693928c6-9080-4cfe-b90b-cc0d3133478a) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2250225244 From syan at openjdk.org Thu Jul 25 12:47:32 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Jul 2024 12:47:32 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 09:50:10 GMT, SendaoYan wrote: >> Hi all, >> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. >> >> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails. >> >> Only change the testcase, the change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 1. Just catch the IOException here when getting the FileStore and skip the test instead of checking for specific exception messages. 2. Throw a org.testng.SkipException instead print and return GHA report a failure: linux x86 `compiler/interpreter/Test6833129.java` fails `SIGSEGV in oopDesc::size_given_klass`, this issue has been recorded by [JDK-8334760](https://bugs.openjdk.org/browse/JDK-8334760), it's unrelated to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2250234321 From alanb at openjdk.org Thu Jul 25 12:50:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 12:50:31 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 12:39:35 GMT, SendaoYan wrote: > The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails. Okay, but doesn't mean that lots of other tests will fail too, esp. tests in jdk_nio test group. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2250241338 From alanb at openjdk.org Thu Jul 25 12:54:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 12:54:31 GMT Subject: RFR: 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled In-Reply-To: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> References: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> Message-ID: On Thu, 25 Jul 2024 10:58:42 GMT, Jorn Vernee wrote: > We are seeing some failures of this test in our CI, particularly on Windows machines, which are known to starve out certain threads. > > To make sure the compiler threads get a chance to work, I've added `-Xbatch` to the flags with which the test runs (this was missed in the original PR). I've also removed the timeout from the `awaitCompilation` method. The intent is to instead rely on the overall test's timeout, which can also be adjusted with a timeout factor for slower machines, rather than putting an absolute time limit on the compilation. > > Finally, Alan asked me to increase the timeout for the executor shutdown, since there have also been some timeouts there. The current timeout is borrowed from `test/jdk/java/foreign/TestHandshake`, but that test uses a lot less threads, so it can probably get await with waiting just 20 seconds. > > Testing: I ran this 200s time in Oracle CI, half of the runs were with `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:-VerifyContinuations` (which is one of the failing configurations). Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20325#pullrequestreview-2199207970 From syan at openjdk.org Thu Jul 25 12:56:31 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Jul 2024 12:56:31 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 12:48:20 GMT, Alan Bateman wrote: > Okay, but doesn't mean that lots of other tests will fail too, esp. tests in jdk_nio test group. Currently we observer only this test fails of tier1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2250252865 From alanb at openjdk.org Thu Jul 25 13:26:34 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 13:26:34 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 12:54:16 GMT, SendaoYan wrote: > > Okay, but doesn't mean that lots of other tests will fail too, esp. tests in jdk_nio test group. > > Currently we observer only this test fails of tier1. Is this because you only run tier1 or do you mean this is the only test that fails? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2250315338 From syan at openjdk.org Thu Jul 25 13:50:31 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Jul 2024 13:50:31 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 13:23:37 GMT, Alan Bateman wrote: > Is this because you only run tier1 or do you mean this is the only test that fails? We only run tier1 on rpmbuild mock enviroment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2250369276 From aph at openjdk.org Thu Jul 25 13:59:35 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Jul 2024 13:59:35 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v6] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Wed, 24 Jul 2024 19:09:06 GMT, Vladimir Ivanov wrote: >>> > Also also, Klass::is_subtype_of() is used for C1 runtime. >>> >>> Can you elaborate, please? >> >> Sorry, that was rather vague. In C1-compiled code, the Java method `Class::isInstance(Object)`calls `Klass::is_subtype_of()`. >> >> In general, I find it difficult to decide how much work, if any, should be done to improve C1 performance. Clearly, if C1 exists only to help with startup time in a tiered compilation system, the answer is "not much". > > Thanks, now I see that `Class::isInstance(Object)` is backed by `Runtime1::is_instance_of()` which uses `oopDesc::is_a()` to do the job. > > If it turns out to be performance critical, the intrinsic implementation should be rewritten to exercise existing subtype checking support in C1. As it is implemented now, it's already quite inefficient. I did write an intrinsic for that, but it made this patch even larger. I have a small patch for C1, for some other time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1691491950 From duke at openjdk.org Thu Jul 25 14:29:05 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 14:29:05 GMT Subject: RFR: 8337167: StringSize deduplication [v2] In-Reply-To: References: Message-ID: > Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: remove unused Integer.stringSize & Long.stringSize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20322/files - new: https://git.openjdk.org/jdk/pull/20322/files/752279f0..a3045712 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20322&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20322&range=00-01 Stats: 30 lines in 2 files changed: 0 ins; 30 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20322/head:pull/20322 PR: https://git.openjdk.org/jdk/pull/20322 From liach at openjdk.org Thu Jul 25 14:46:35 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 14:46:35 GMT Subject: RFR: 8337167: StringSize deduplication [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 14:29:05 GMT, Shaojin Wen wrote: >> Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove unused Integer.stringSize & Long.stringSize Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20322#pullrequestreview-2199522887 From rriggs at openjdk.org Thu Jul 25 14:51:37 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 25 Jul 2024 14:51:37 GMT Subject: RFR: 8337167: StringSize deduplication [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 14:29:05 GMT, Shaojin Wen wrote: >> Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove unused Integer.stringSize & Long.stringSize What is the performance difference between the long and int versions? If it is negligible, keep only the long version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20322#issuecomment-2250535851 From duke at openjdk.org Thu Jul 25 14:52:11 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 14:52:11 GMT Subject: RFR: 8336856: Optimize String Concat [v16] In-Reply-To: References: Message-ID: <1ZwToSQZXTiMjFU2iH1yj5y6yUnii2bwtMPo7sARJSo=.752f9553-db8c-463c-8e21-b94804dc8a08@github.com> > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - remove benchmark - common simpleConcat ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/00fcd554..f1898af9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=14-15 Stats: 175 lines in 3 files changed: 20 ins; 149 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From liach at openjdk.org Thu Jul 25 14:58:33 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 14:58:33 GMT Subject: RFR: 8337167: StringSize deduplication [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 14:48:29 GMT, Roger Riggs wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused Integer.stringSize & Long.stringSize > > What is the performance difference between the long and int versions? > If it is negligible, keep only the long version. @RogerRiggs They will be used in MethodHandle chains or explicit bytecode; having `long` and `int` specific versions simplify the bytecode or MethodHandle we need to prepare for String concatenation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20322#issuecomment-2250575109 From duke at openjdk.org Thu Jul 25 15:10:33 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 15:10:33 GMT Subject: RFR: 8337167: StringSize deduplication [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 14:48:29 GMT, Roger Riggs wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused Integer.stringSize & Long.stringSize > > What is the performance difference between the long and int versions? > If it is negligible, keep only the long version. @RogerRiggs The risk of removing stringSize(int) is not low, and the performance may be different on different platforms. If we want to remove it, it should be a separate PR, with extensive testing and extensive discussion before doing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20322#issuecomment-2250622673 From duke at openjdk.org Thu Jul 25 15:17:32 2024 From: duke at openjdk.org (duke) Date: Thu, 25 Jul 2024 15:17:32 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: On Thu, 25 Jul 2024 05:06:17 GMT, Shaojin Wen wrote: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. @wenshao Your change (at version c03ed26ffdf2cebcc9074c2aeae27fbb1f49c025) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20321#issuecomment-2250640401 From jpai at openjdk.org Thu Jul 25 15:20:01 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 25 Jul 2024 15:20:01 GMT Subject: [jdk23] RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Message-ID: Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. ------------- Commit messages: - 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Changes: https://git.openjdk.org/jdk/pull/20333/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20333&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334167 Stats: 144 lines in 3 files changed: 82 ins; 40 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/20333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20333/head:pull/20333 PR: https://git.openjdk.org/jdk/pull/20333 From bpb at openjdk.org Thu Jul 25 15:21:31 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 25 Jul 2024 15:21:31 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:11:42 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. Yes, I was wondering about changing the organization of the native code files. It's not great to have them all in `/libjava`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2250654680 From liach at openjdk.org Thu Jul 25 15:35:30 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 15:35:30 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString In-Reply-To: References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: <9EsYCBG58atmdhdHwh3RnxFMwxVu51AuEzyvXF7Ok6w=.eb8d1c17-47f8-4bcc-9b2f-fe4cdd1268c3@github.com> On Thu, 25 Jul 2024 06:19:46 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Below are the performance numbers running on a MacBook M1 Max, which increased speed by +179.88% > > > -# master 05d88de05e9b7814ecd5517aacd17f0feafdff3c > -Benchmark Mode Cnt Score Error Units > -ToStringBench.localDateTimeToString thrpt 15 4.896 ? 1.414 ops/ms > > +# current c03ed26ffdf2cebcc9074c2aeae27fbb1f49c025 > +Benchmark Mode Cnt Score Error Units > +ToStringBench.localDateTimeToString thrpt 15 13.703 ? 1.960 ops/ms +179.88% @wenshao Please give other reviewers (especially those maintaining the locale area) some time to take a look: https://openjdk.org/guide/#life-of-a-pr recommends to wait for 24 hours for reviewers before integrating a pull request. Also, ran tier 1-3 tests for this patch and looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20321#issuecomment-2250698964 From aph at openjdk.org Thu Jul 25 15:42:04 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Jul 2024 15:42:04 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v7] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request incrementally with four additional commits since the last revision: - Cleanup - temp - Merge branch 'JDK-8331658-work' of https://github.com/theRealAph/jdk into JDK-8331658-work - Minor cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19989/files - new: https://git.openjdk.org/jdk/pull/19989/files/48e80a13..011a3880 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=05-06 Stats: 51 lines in 7 files changed: 21 ins; 18 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From asemenyuk at openjdk.org Thu Jul 25 15:42:38 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 25 Jul 2024 15:42:38 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 08:40:44 GMT, Vanitha B P wrote: >> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Addressed the review comments Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20312#pullrequestreview-2199685519 From duke at openjdk.org Thu Jul 25 16:00:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 16:00:34 GMT Subject: RFR: 8336856: Optimize String Concat [v16] In-Reply-To: <1ZwToSQZXTiMjFU2iH1yj5y6yUnii2bwtMPo7sARJSo=.752f9553-db8c-463c-8e21-b94804dc8a08@github.com> References: <1ZwToSQZXTiMjFU2iH1yj5y6yUnii2bwtMPo7sARJSo=.752f9553-db8c-463c-8e21-b94804dc8a08@github.com> Message-ID: On Thu, 25 Jul 2024 14:52:11 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - remove benchmark > - common simpleConcat Startup performance is better when simpleConcat works, so I use highArity and bytecode-spinning only when simpleConcat doesn't work. Should we add some simpleConcat implementations, such as: String simpleConcat(Object arg0, int arg1); String simpleConcat(Object arg0, long arg1) String simpleConcat(Object arg0, boolean arg1) String simpleConcat(int arg0, Object arg1) String simpleConcat(long arg0, Object arg1) String simpleConcat(boolean arg0, Object arg1) This will help with startup performance ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2250787254 From aph at openjdk.org Thu Jul 25 16:05:49 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Jul 2024 16:05:49 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v8] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'clean' into JDK-8331658-work - Cleanup - temp - Merge branch 'JDK-8331658-work' of https://github.com/theRealAph/jdk into JDK-8331658-work - Review comments - Review comments - Review comments - Review comments - Review feedback - Review feedback - ... and 30 more: https://git.openjdk.org/jdk/compare/34ee06f5...248f44dc ------------- Changes: https://git.openjdk.org/jdk/pull/19989/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=07 Stats: 991 lines in 19 files changed: 754 ins; 116 del; 121 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From aph at openjdk.org Thu Jul 25 16:25:38 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Jul 2024 16:25:38 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v8] In-Reply-To: <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> Message-ID: On Thu, 25 Jul 2024 16:05:49 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge branch 'clean' into JDK-8331658-work > - Cleanup > - temp > - Merge branch 'JDK-8331658-work' of https://github.com/theRealAph/jdk into JDK-8331658-work > - Review comments > - Review comments > - Review comments > - Review comments > - Review feedback > - Review feedback > - ... and 30 more: https://git.openjdk.org/jdk/compare/34ee06f5...248f44dc OK! I think that's everything. Are we ready for a second pair of eyes now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2250880303 From bpb at openjdk.org Thu Jul 25 16:26:34 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 25 Jul 2024 16:26:34 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:11:42 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. Perhaps `/native/libjava/nio/ch` and `/native/libjava/nio/fs`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2250883875 From jvernee at openjdk.org Thu Jul 25 16:40:35 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 25 Jul 2024 16:40:35 GMT Subject: RFR: 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled In-Reply-To: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> References: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> Message-ID: On Thu, 25 Jul 2024 10:58:42 GMT, Jorn Vernee wrote: > We are seeing some failures of this test in our CI, particularly on Windows machines, which are known to starve out certain threads. > > To make sure the compiler threads get a chance to work, I've added `-Xbatch` to the flags with which the test runs (this was missed in the original PR). I've also removed the timeout from the `awaitCompilation` method. The intent is to instead rely on the overall test's timeout, which can also be adjusted with a timeout factor for slower machines, rather than putting an absolute time limit on the compilation. > > Finally, Alan asked me to increase the timeout for the executor shutdown, since there have also been some timeouts there. The current timeout is borrowed from `test/jdk/java/foreign/TestHandshake`, but that test uses a lot less threads, so it can probably get await with waiting just 20 seconds. > > Testing: I ran this test 200 time in Oracle CI, half of the runs were with `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:-VerifyContinuations` (which is one of the failing configurations). Will integrate this now, since we're seeing sporadic failures in tier 1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20325#issuecomment-2250908883 From jvernee at openjdk.org Thu Jul 25 16:40:36 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 25 Jul 2024 16:40:36 GMT Subject: Integrated: 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled In-Reply-To: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> References: <_22vrQFU2s_miFW43KvlGqDPkbuoLXvoMiRuOKfCuPM=.3abfca64-3787-4685-899e-7c7fc32243f1@github.com> Message-ID: On Thu, 25 Jul 2024 10:58:42 GMT, Jorn Vernee wrote: > We are seeing some failures of this test in our CI, particularly on Windows machines, which are known to starve out certain threads. > > To make sure the compiler threads get a chance to work, I've added `-Xbatch` to the flags with which the test runs (this was missed in the original PR). I've also removed the timeout from the `awaitCompilation` method. The intent is to instead rely on the overall test's timeout, which can also be adjusted with a timeout factor for slower machines, rather than putting an absolute time limit on the compilation. > > Finally, Alan asked me to increase the timeout for the executor shutdown, since there have also been some timeouts there. The current timeout is borrowed from `test/jdk/java/foreign/TestHandshake`, but that test uses a lot less threads, so it can probably get await with waiting just 20 seconds. > > Testing: I ran this test 200 time in Oracle CI, half of the runs were with `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:-VerifyContinuations` (which is one of the failing configurations). This pull request has now been integrated. Changeset: 81ed0287 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/81ed0287175617e6f7ad79dd7036b2fbde27e80a Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled Reviewed-by: mcimadamore, alanb ------------- PR: https://git.openjdk.org/jdk/pull/20325 From almatvee at openjdk.org Thu Jul 25 20:18:32 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 25 Jul 2024 20:18:32 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 08:40:44 GMT, Vanitha B P wrote: >> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Addressed the review comments Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20312#pullrequestreview-2200371354 From naoto at openjdk.org Thu Jul 25 20:42:31 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 25 Jul 2024 20:42:31 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: On Thu, 25 Jul 2024 05:06:17 GMT, Shaojin Wen wrote: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. LGTM src/java.base/share/classes/java/time/LocalTime.java line 1645: > 1643: int nanoValue = nano; > 1644: buf.append(hourValue < 10 ? "0" : "").append(hourValue) > 1645: .append(minuteValue < 10 ? ":0" : ":").append(minuteValue); Nit: unnecessary modification ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20321#pullrequestreview-2200429700 PR Review Comment: https://git.openjdk.org/jdk/pull/20321#discussion_r1692090342 From rriggs at openjdk.org Thu Jul 25 20:59:32 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 25 Jul 2024 20:59:32 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: <3QNQV0MMihxLy0llTm5tICgnpJOMKz74cJQHEXqWlH0=.4313765a-9bca-4906-acd2-953c3d049b92@github.com> On Thu, 25 Jul 2024 05:06:17 GMT, Shaojin Wen wrote: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. src/java.base/share/classes/java/time/LocalDate.java line 2155: > 2153: } > 2154: > 2155: void formatTo(StringBuilder buf) { For methods used outside of a class (i.e. not private) a minimal method description is recommended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20321#discussion_r1692113590 From rriggs at openjdk.org Thu Jul 25 21:36:32 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 25 Jul 2024 21:36:32 GMT Subject: RFR: 8337167: StringSize deduplication [v2] In-Reply-To: References: Message-ID: <9hHHd2bd3kBDmdcYwkxWWcE2czGvrJxB38E1nG01t0k=.33f04187-1374-4ca0-9363-801d2171a14f@github.com> On Thu, 25 Jul 2024 14:29:05 GMT, Shaojin Wen wrote: >> Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove unused Integer.stringSize & Long.stringSize lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20322#pullrequestreview-2200503680 From rriggs at openjdk.org Thu Jul 25 21:47:33 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 25 Jul 2024 21:47:33 GMT Subject: RFR: 8336934: Clean up JavaLangReflectAccess In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 04:10:38 GMT, Chen Liang wrote: > Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`. The description should include a summary of the changes and the rationale. The Jira description is a bit better and could also be more complete. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20290#issuecomment-2251449428 From duke at openjdk.org Thu Jul 25 21:52:03 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 21:52:03 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v2] In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - add comments - reduce change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20321/files - new: https://git.openjdk.org/jdk/pull/20321/files/c03ed26f..7b68b32b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20321&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20321&range=00-01 Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20321/head:pull/20321 PR: https://git.openjdk.org/jdk/pull/20321 From rriggs at openjdk.org Thu Jul 25 21:59:31 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 25 Jul 2024 21:59:31 GMT Subject: RFR: 8336934: Clean up JavaLangReflectAccess In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 04:10:38 GMT, Chen Liang wrote: > Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`. src/java.base/share/classes/java/lang/reflect/Constructor.java line 168: > 166: } > 167: > 168: /** Creates a new root constructor with a custom accessor for serialization hooks. */ Preserve "/**" comments for generated javadoc, a "//" comment would be more appropriate for a 1-liner. src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java line 53: > 51: // > 52: > 53: // Personal editor comments should not be included. src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java line 68: > 66: > 67: // > 68: Remove ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20290#discussion_r1692174982 PR Review Comment: https://git.openjdk.org/jdk/pull/20290#discussion_r1692164266 PR Review Comment: https://git.openjdk.org/jdk/pull/20290#discussion_r1692165039 From liach at openjdk.org Thu Jul 25 22:06:31 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 22:06:31 GMT Subject: RFR: 8336934: Clean up JavaLangReflectAccess In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 21:38:04 GMT, Roger Riggs wrote: >> Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`. > > src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java line 53: > >> 51: // >> 52: >> 53: // > > Personal editor comments should not be included. Ah, thought editor folds were acceptable as they appear in a few places in javac code. Will remove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20290#discussion_r1692193282 From liach at openjdk.org Thu Jul 25 22:23:35 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 22:23:35 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v2] In-Reply-To: References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: On Thu, 25 Jul 2024 21:52:03 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - add comments > - reduce change src/java.base/share/classes/java/time/LocalDate.java line 2157: > 2155: > 2156: /** > 2157: * Outputs this date into {@code StringBuilder}, such as {@code 2007-12-03}. You shouldn't copy the docs for `toString` as that is not we should be careful about using this `formatTo`. You should write something helpful like: /** * Prints the toString result to the given buf, avoiding extra string allocations. * Requires extra capacity of 10 to avoid StringBuilder reallocation. */ src/java.base/share/classes/java/time/LocalTime.java line 1640: > 1638: > 1639: /** > 1640: * Outputs this time into {@code StringBuilder}, such as {@code 10:15}. Same here: /** * Prints the toString result to the given buf, avoiding extra string allocations. * Requires extra capacity of 18 to avoid StringBuilder reallocation. */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20321#discussion_r1692207893 PR Review Comment: https://git.openjdk.org/jdk/pull/20321#discussion_r1692209966 From jlu at openjdk.org Thu Jul 25 22:23:45 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 25 Jul 2024 22:23:45 GMT Subject: RFR: 8313205: Modernize java.text.Format with StringBuilder Message-ID: Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses. While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it. The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods. A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized). ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/20337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313205 Stats: 883 lines in 12 files changed: 881 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20337/head:pull/20337 PR: https://git.openjdk.org/jdk/pull/20337 From liach at openjdk.org Thu Jul 25 22:33:44 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 22:33:44 GMT Subject: RFR: 8336934: Clean up JavaLangReflectAccess [v2] In-Reply-To: References: Message-ID: > Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`. > > The cleanup in `JavaLangReflectAccess` is: > - Converted `newConstructor` taking parameters to taking another constructor and a new accessor. The old existing API essentially does a copy and sets an accessor. > - Removed lots of constructor getters, unused after `newConstructor` cleanup. > - Removed accessor getter/setters, unused after `newConstructor` cleanup. > - Removed `leafCopyMethod`. We can already use `getRoot` plus `copyMethod` to achieve the same effect. 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: - Remove editor folds, improve comments - Merge branch 'm5' into cleanup/reflect-access - 8336934: Clean up JavaLangReflectAccess ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20290/files - new: https://git.openjdk.org/jdk/pull/20290/files/5d6c60bc..7973c8ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20290&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20290&range=00-01 Stats: 8152 lines in 178 files changed: 5432 ins; 1729 del; 991 mod Patch: https://git.openjdk.org/jdk/pull/20290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20290/head:pull/20290 PR: https://git.openjdk.org/jdk/pull/20290 From liach at openjdk.org Thu Jul 25 22:39:30 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 22:39:30 GMT Subject: RFR: 8336934: Clean up JavaLangReflectAccess In-Reply-To: References: Message-ID: <0EZL86DvQaZq6MsvEDwlpWK8BY8GIKC0ashgXjaOLU8=.60d13b5d-f5a2-4861-acd7-1c18b0d79cad@github.com> On Thu, 25 Jul 2024 21:45:21 GMT, Roger Riggs wrote: >> Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`. >> >> The cleanup in `JavaLangReflectAccess` is: >> - Converted `newConstructor` taking parameters to taking another constructor and a new accessor. The old existing API essentially does a copy and sets an accessor. >> - Removed lots of constructor getters, unused after `newConstructor` cleanup. >> - Removed accessor getter/setters, unused after `newConstructor` cleanup. >> - Removed `leafCopyMethod`. We can already use `getRoot` plus `copyMethod` to achieve the same effect. > > The description should include a summary of the changes and the rationale. > The Jira description is a bit better and could also be more complete. @RogerRiggs Is the description now cleaner? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20290#issuecomment-2251513818 From liach at openjdk.org Thu Jul 25 22:46:58 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 22:46:58 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute Message-ID: As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. ------------- Commit messages: - 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute Changes: https://git.openjdk.org/jdk/pull/20338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337225 Stats: 106 lines in 11 files changed: 32 ins; 54 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/20338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20338/head:pull/20338 PR: https://git.openjdk.org/jdk/pull/20338 From duke at openjdk.org Thu Jul 25 22:51:09 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 22:51:09 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v3] In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: change description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20321/files - new: https://git.openjdk.org/jdk/pull/20321/files/7b68b32b..e7c5bc69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20321&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20321&range=01-02 Stats: 19 lines in 2 files changed: 0 ins; 15 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20321/head:pull/20321 PR: https://git.openjdk.org/jdk/pull/20321 From liach at openjdk.org Thu Jul 25 22:54:37 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 22:54:37 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v3] In-Reply-To: References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: On Thu, 25 Jul 2024 22:51:09 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > change description src/java.base/share/classes/java/time/LocalTime.java line 1641: > 1639: /** > 1640: * Prints the toString result to the given buf, avoiding extra string allocations. > 1641: * Requires extra capacity of 10 to avoid StringBuilder reallocation. Suggestion: * Requires extra capacity of 18 to avoid StringBuilder reallocation. Sorry I left a typo, you see toString is `new StringBuilder(18)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20321#discussion_r1692240103 From duke at openjdk.org Thu Jul 25 23:05:46 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 23:05:46 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v4] In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/time/LocalTime.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20321/files - new: https://git.openjdk.org/jdk/pull/20321/files/e7c5bc69..f17ea04a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20321&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20321&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20321/head:pull/20321 PR: https://git.openjdk.org/jdk/pull/20321 From liach at openjdk.org Thu Jul 25 23:16:32 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 23:16:32 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v4] In-Reply-To: <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> Message-ID: On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/time/LocalTime.java > > Co-authored-by: Chen Liang Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20321#pullrequestreview-2200599732 From liach at openjdk.org Thu Jul 25 23:16:42 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 23:16:42 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments Message-ID: Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. ------------- Commit messages: - 8337219: AccessFlags factories do not require necessary arguments Changes: https://git.openjdk.org/jdk/pull/20341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337219 Stats: 212 lines in 21 files changed: 71 ins; 80 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/20341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20341/head:pull/20341 PR: https://git.openjdk.org/jdk/pull/20341 From liach at openjdk.org Thu Jul 25 23:31:36 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Jul 2024 23:31:36 GMT Subject: RFR: 8313205: Modernize java.text.Format with StringBuilder In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 22:18:03 GMT, Justin Lu wrote: > Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses. > > While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it. > > The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods. > > A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized). You should add `@since` tags on all these new API additions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20337#issuecomment-2251565706 From vlivanov at openjdk.org Thu Jul 25 23:33:38 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Jul 2024 23:33:38 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v8] In-Reply-To: <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> Message-ID: <2tItgZaRCa5BQrmelOWEsn6FVlHlEvY4is2L1n3HxhE=.eb2519cc-d69e-45e6-8ca3-b5b02565bb76@github.com> On Thu, 25 Jul 2024 16:05:49 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge branch 'clean' into JDK-8331658-work > - Cleanup > - temp > - Merge branch 'JDK-8331658-work' of https://github.com/theRealAph/jdk into JDK-8331658-work > - Review comments > - Review comments > - Review comments > - Review comments > - Review feedback > - Review feedback > - ... and 30 more: https://git.openjdk.org/jdk/compare/34ee06f5...248f44dc Thanks! The patch looks good, except there was one failure observed during testing with the latest patch [1]. It does look related to the latest changes you did in [54050a5](https://github.com/openjdk/jdk/pull/19989/commits/54050a5c2c0aa1d6a9e36d0240c66345765845e3) about `bitmap == SECONDARY_SUPERS_BITMAP_FULL` check. [1] # Internal Error (.../src/hotspot/share/oops/array.hpp:126), pid=1225147, tid=1273512 # assert(i >= 0 && i< _length) failed: oob: 0 <= 63 < 63 V [libjvm.so+0x7f7eab] oopDesc::is_a(Klass*) const+0x21b (array.hpp:126) V [libjvm.so+0xe9805e] java_lang_Throwable::fill_in_stack_trace(Handle, methodHandle const&, JavaThread*)+0x158e (javaClasses.cpp:2677) V [libjvm.so+0xe982cb] java_lang_Throwable::fill_in_stack_trace(Handle, methodHandle const&)+0x6b (javaClasses.cpp:2719) V [libjvm.so+0xfe045c] JVM_FillInStackTrace+0x9c (jvm.cpp:515) .... RBX=0x00000000b446bcf0 is a pointer to class: javasoft.sqe.tests.lang.clss029.clss02902.e67 {0x00000000b446bcf0} ... - name: 'javasoft/sqe/tests/lang/clss029/clss02902/e67' - super: 'javasoft/sqe/tests/lang/clss029/clss02902/e66' - sub: 'javasoft/sqe/tests/lang/clss029/clss02902/e68' ... - secondary supers: Array(0x00007faff68b3058) - hash_slot: 39 - secondary bitmap: 0xffffffffffffffff R12=0x00000000b446ba80 is a pointer to class: javasoft.sqe.tests.lang.clss029.clss02902.e66 {0x00000000b446ba80} ... - name: 'javasoft/sqe/tests/lang/clss029/clss02902/e66' - super: 'javasoft/sqe/tests/lang/clss029/clss02902/e65' - sub: 'javasoft/sqe/tests/lang/clss029/clss02902/e67' ... - secondary supers: Array(0x00007faff68b2c90) - hash_slot: 63 - secondary bitmap: 0xfffffffffffefffd Do we miss ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2251567973 From duke at openjdk.org Thu Jul 25 23:38:36 2024 From: duke at openjdk.org (Shaojin Wen) Date: Thu, 25 Jul 2024 23:38:36 GMT Subject: RFR: 8336856: Optimize String Concat [v15] In-Reply-To: References: <0EQa3rOXnTed-C0CAgTBAcNGn1hEpF9oRngYdp_yWAw=.d03d88dc-c4aa-4a2e-830d-84b51f1fc156@github.com> Message-ID: On Thu, 25 Jul 2024 10:15:20 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> add benchmark > > test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47: > >> 45: @Measurement(iterations = 5, time = 1000, timeUnit = TimeUnit.MILLISECONDS) >> 46: @Fork(value = 3, jvmArgsAppend = "-Djava.lang.invoke.StringConcat.highArityThreshold=0") >> 47: public class StringConcatGenerate extends StringConcat { > > Adding a subclass with an overridden `@Fork` to pass a different `jvmArgsAppend` is a reasonable trick, but could be moved to a nested class within `StringConcat` to keep it in the same context. I'm not sure if this micro brings a persistent added value, though: for experimentation we can just run `StringConcat` with different `-Djava.lang.invoke.StringConcat.highArityThreshold` settings, while for continuous regression testing we're more interested in validating the default settings. Supplying the new `main` method doesn't add anything here, either, since a standalone execution wouldn't pick up the `jvmArgsAppend` value. I have removed the newly added micro benchmark. But I don't know how to add jvmArgs in make test. This will give an error make test TEST="micro:java.lang.StringConcat.concat6String" -Djava.lang.invoke.StringConcat.highArityThreshold=0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1692278005 From jlu at openjdk.org Thu Jul 25 23:45:08 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 25 Jul 2024 23:45:08 GMT Subject: RFR: 8313205: Modernize java.text.Format with StringBuilder [v2] In-Reply-To: References: Message-ID: <4K4AeUzxdLsAsgIcxZ02d4jLhQUMbCXrmKtjuN2yzIk=.5ea419d8-948b-4121-953d-805659c09e37@github.com> > Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses. > > While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it. > > The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods. > > A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: add since tags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20337/files - new: https://git.openjdk.org/jdk/pull/20337/files/3c78d9ac..314b8d7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=00-01 Stats: 18 lines in 9 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20337/head:pull/20337 PR: https://git.openjdk.org/jdk/pull/20337 From jlu at openjdk.org Thu Jul 25 23:45:08 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 25 Jul 2024 23:45:08 GMT Subject: RFR: 8313205: Modernize java.text.Format with StringBuilder In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 23:28:44 GMT, Chen Liang wrote: > You should add `@since` tags on all these new API additions. Thanks for the reminder. Updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20337#issuecomment-2251577718 From vlivanov at openjdk.org Thu Jul 25 23:51:38 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Jul 2024 23:51:38 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v8] In-Reply-To: <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> Message-ID: <8X8AZw0dKF8wuWXY1KtHXSY0OItqLX-SiAJG6zRYwfY=.8e4b95c2-95ca-4847-aa12-3d8fd7b10f17@github.com> On Thu, 25 Jul 2024 16:05:49 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge branch 'clean' into JDK-8331658-work > - Cleanup > - temp > - Merge branch 'JDK-8331658-work' of https://github.com/theRealAph/jdk into JDK-8331658-work > - Review comments > - Review comments > - Review comments > - Review comments > - Review feedback > - Review feedback > - ... and 30 more: https://git.openjdk.org/jdk/compare/34ee06f5...248f44dc src/hotspot/share/oops/klass.inline.hpp line 82: > 80: // subtype check: true if is_subclass_of, or if k is interface and receiver implements it > 81: inline bool Klass::is_subtype_of(Klass* k) const { > 82: guarantee(secondary_supers() != nullptr, "must be"); Minor point: considering libjvm contains hundreds of copies, does it make sense to turn it into an assert instead? For example, on AArch64 the check costs 36 bytes [1] in product build. [1] libjvm.dylib[0x1306d4] <+28>: ldr x9, [x8, #0x28] libjvm.dylib[0x1306d8] <+32>: cbz x9, 0x1307dc ; <+292> [inlined] Klass::is_subtype_of(Klass*) const at klass.inline.hpp:82:3 ... libjvm.dylib[0x1307dc] <+292>: adrp x0, 3200 libjvm.dylib[0x1307e0] <+296>: add x0, x0, #0x663 ; "open/src/hotspot/share/oops/klass.inline.hpp" libjvm.dylib[0x1307e4] <+300>: adrp x2, 3200 libjvm.dylib[0x1307e8] <+304>: add x2, x2, #0x690 ; "guarantee(secondary_supers() != nullptr) failed" libjvm.dylib[0x1307ec] <+308>: adrp x3, 3200 libjvm.dylib[0x1307f0] <+312>: add x3, x3, #0x6c0 ; "must be" libjvm.dylib[0x1307f4] <+316>: mov w1, #0x52 libjvm.dylib[0x1307f8] <+320>: bl 0x54f870 ; report_vm_error at debug.cpp:181 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1692288943 From duke at openjdk.org Fri Jul 26 00:19:41 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 00:19:41 GMT Subject: RFR: 8337245: Fix wrong comment of StringConcatHelper Message-ID: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> 8337245: Fix wrong comment of StringConcatHelper ------------- Commit messages: - fix typo Changes: https://git.openjdk.org/jdk/pull/20344/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337245 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20344/head:pull/20344 PR: https://git.openjdk.org/jdk/pull/20344 From jpai at openjdk.org Fri Jul 26 04:32:32 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 26 Jul 2024 04:32:32 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 09:50:10 GMT, SendaoYan wrote: >> Hi all, >> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. >> >> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails. >> >> Only change the testcase, the change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 1. Just catch the IOException here when getting the FileStore and skip the test instead of checking for specific exception messages. 2. Throw a org.testng.SkipException instead print and return test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java line 217: > 215: } catch (IOException e) { > 216: e.printStackTrace(); > 217: throw new SkipException("WARNING: IOException occur. Skipping testDumpDirNotWritable test."); Nit: "occurred" instead "occur". Additionally, I would suggest even the exception's toString() in that message just to provide additional context at the location wherever this will get reported outside of a .jtr (if at all). So something like: throw new SkipException("WARNING: IOException occurred: " + e + ", Skipping testDumpDirNotWritable test."); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19905#discussion_r1692498834 From jpai at openjdk.org Fri Jul 26 04:39:33 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 26 Jul 2024 04:39:33 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Thu, 25 Jul 2024 09:50:10 GMT, SendaoYan wrote: >> Hi all, >> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. >> >> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails. >> >> Only change the testcase, the change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 1. Just catch the IOException here when getting the FileStore and skip the test instead of checking for specific exception messages. 2. Throw a org.testng.SkipException instead print and return > Additional, the org.testng.SkipException seems do not work normally in [jtreg](https://bugs.openjdk.org/browse/CODETOOLS-7903708) for now. We have had several enhancement reports (in jtreg) for better reporting skipped tests. Some relate to what the make scripts in the JDK report and some from jtreg reports themselves. I'll have to go back and check if the one you note about is something that we are already aware about. For now though, your change to use `SkippedException` looks correct to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2251959084 From jpai at openjdk.org Fri Jul 26 04:44:37 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 26 Jul 2024 04:44:37 GMT Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 00:24:59 GMT, Brian Burkhalter wrote: > Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively. src/java.base/share/classes/java/io/BufferedInputStream.java line 56: > 54: * to read from the same {@code InputStream}. There is no way for a > 55: * {@code BufferedInputStream} to know what another {@code BufferedInputStream} > 56: * has read from the underlying {@code InputStream}, nor dues it have access Hello Brian, there's a typo here - should have been "does" instead of "dues". Same in the other class in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1692503702 From jpai at openjdk.org Fri Jul 26 05:16:30 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 26 Jul 2024 05:16:30 GMT Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 00:24:59 GMT, Brian Burkhalter wrote: > Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively. I went through the linked JBS issue to understand why we are adding this. The use case appears to be that the application uses a BufferedReader instance on top of the underlying Reader R1, then does some API calls on the BufferedReader, then uses a separate and new BufferedReader instance on top of the same underlying R1 Reader instance. I think the proposal to add this text is OK, although I wonder if this should also be added or is applicable to `BufferedOutputStream` too. Also, do you think we could reword the proposed text a bit? It wasn't immediately clear to me what issue we were trying to address with that text. Would something like the following be clearer: > More than one instance of a BufferedReader should not be used with the same instance of the underlying Reader. Doing so can cause the BufferedReader instances to return an incorrect result since each instance of the BufferedReader maintains its own state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2251988591 From vlivanov at openjdk.org Fri Jul 26 05:59:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 26 Jul 2024 05:59:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v8] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <5N5AdXvL7EpqKbo5LbxBvjeLsduh3_eEuM9LOPjD-Fc=.e70e1af6-430e-4213-8ce7-88a9cec15960@github.com> Message-ID: On Thu, 25 Jul 2024 13:56:34 GMT, Andrew Haley wrote: >> Thanks, now I see that `Class::isInstance(Object)` is backed by `Runtime1::is_instance_of()` which uses `oopDesc::is_a()` to do the job. >> >> If it turns out to be performance critical, the intrinsic implementation should be rewritten to exercise existing subtype checking support in C1. As it is implemented now, it's already quite inefficient. > > I did write an intrinsic for that, but it made this patch even larger. I have a small patch for C1, for some other time. FYI I filed a low-priority RFE against C1 to track it ([JDK-8337251](https://bugs.openjdk.org/browse/JDK-8337251)). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1692548251 From syan at openjdk.org Fri Jul 26 06:29:05 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Jul 2024 06:29:05 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v4] In-Reply-To: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: > Hi all, > Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. > > The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails. > > Only change the testcase, the change has been verified locally, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: add the exception's toString() into SkipException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19905/files - new: https://git.openjdk.org/jdk/pull/19905/files/9c7946f8..b3af3f87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19905&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19905&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19905.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19905/head:pull/19905 PR: https://git.openjdk.org/jdk/pull/19905 From syan at openjdk.org Fri Jul 26 06:29:05 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Jul 2024 06:29:05 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v3] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: <-LlXnBzbGlhR-Q9byj9lyboGSIBGTNqiybkJ5J5_IHk=.79041dca-3c24-485f-b64e-d39cd261c162@github.com> On Fri, 26 Jul 2024 04:30:16 GMT, Jaikiran Pai wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. Just catch the IOException here when getting the FileStore and skip the test instead of checking for specific exception messages. 2. Throw a org.testng.SkipException instead print and return > > test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java line 217: > >> 215: } catch (IOException e) { >> 216: e.printStackTrace(); >> 217: throw new SkipException("WARNING: IOException occur. Skipping testDumpDirNotWritable test."); > > Nit: "occurred" instead "occur". Additionally, I would suggest even the exception's toString() in that message just to provide additional context at the location wherever this will get reported outside of a .jtr (if at all). So something like: > > throw new SkipException("WARNING: IOException occurred: " + e + ", Skipping testDumpDirNotWritable test."); Thanks for your advice and review again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19905#discussion_r1692570083 From jpai at openjdk.org Fri Jul 26 06:31:36 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 26 Jul 2024 06:31:36 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v4] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Fri, 26 Jul 2024 06:29:05 GMT, SendaoYan wrote: >> Hi all, >> Test `test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java` fails on rpm build mock environment. The `df -h` command return fail `df: cannot read table of mounted file systems: No such file or directory` on the rpm build mock environment also. I think it's a environmental issue, and the environmental issue should not cause the test fails, it should skip the test. >> >> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails. >> >> Only change the testcase, the change has been verified locally, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > add the exception's toString() into SkipException The latest change looks OK to me. Please wait for Alan to decide if this is OK to integrate. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19905#pullrequestreview-2201036393 From duke at openjdk.org Fri Jul 26 07:03:32 2024 From: duke at openjdk.org (duke) Date: Fri, 26 Jul 2024 07:03:32 GMT Subject: RFR: 8337167: StringSize deduplication [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 14:29:05 GMT, Shaojin Wen wrote: >> Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove unused Integer.stringSize & Long.stringSize @wenshao Your change (at version a3045712850e5d5d7aca8dc63855e9e931fa8a2d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20322#issuecomment-2252103512 From duke at openjdk.org Fri Jul 26 07:11:39 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 07:11:39 GMT Subject: Integrated: 8337167: StringSize deduplication In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 05:30:34 GMT, Shaojin Wen wrote: > Integer.stringSize and Long.stringSize are used not only in java.lang, but also in other places. We put stringSize in DecimalDigits to reduce duplicate code and the use of JLA. This pull request has now been integrated. Changeset: 7f119354 Author: Shaojin Wen Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/7f11935461a6ff1ef0fac800fb4264a519e21061 Stats: 127 lines in 8 files changed: 32 ins; 87 del; 8 mod 8337167: StringSize deduplication Reviewed-by: liach, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/20322 From syan at openjdk.org Fri Jul 26 07:18:34 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Jul 2024 07:18:34 GMT Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment [v4] In-Reply-To: References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com> Message-ID: On Fri, 26 Jul 2024 06:29:18 GMT, Jaikiran Pai wrote: > The latest change looks OK to me. Please wait for Alan to decide if this is OK to integrate. Okey, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2252123786 From asotona at openjdk.org Fri Jul 26 08:05:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 26 Jul 2024 08:05:33 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 22:41:08 GMT, Chen Liang wrote: > As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. > > Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java line 67: > 65: this.maxLocals = Util.maxLocals(methodInfo.methodFlags(), methodInfo.methodTypeSymbol()); > 66: if (original != null) > 67: this.maxLocals = Math.max(this.maxLocals, original.maxLocals()); `original::maxLocals`set the counter for `CodeBuilder::allocateLocal` By restricting calculation of maxLocals to "origin instanceof CodeAttribute" may cause invalid locals allocations for chained code builders. The number might not be exposed in the API, however we need to know it internally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20338#discussion_r1692669453 From asotona at openjdk.org Fri Jul 26 08:22:31 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 26 Jul 2024 08:22:31 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote: > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. It is a reasonable cleanup of risky factory methods, given the fact we have more safe `withFlags` builders methods. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20341#pullrequestreview-2201219552 From duke at openjdk.org Fri Jul 26 10:48:11 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 26 Jul 2024 10:48:11 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v40] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Slightly slower but safer code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/96582ee5..27f0c8c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=39 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=38-39 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Fri Jul 26 11:29:32 2024 From: duke at openjdk.org (duke) Date: Fri, 26 Jul 2024 11:29:32 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v4] In-Reply-To: <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> Message-ID: <4wz62joo72UZC7n-Xr7wggFAy3zIjo0updYyJtZMqYI=.76eb2a32-b8f1-4847-95d5-70c27d74a312@github.com> On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/time/LocalTime.java > > Co-authored-by: Chen Liang @wenshao Your change (at version f17ea04a148d61184d9ffe04a3ca3beb90150cdc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20321#issuecomment-2252560045 From rgiulietti at openjdk.org Fri Jul 26 11:58:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 26 Jul 2024 11:58:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v35] In-Reply-To: References: Message-ID: <1g40tJFo9AlePrZSRsPBXS4devwQa4lkmQ6EFmt1S_w=.a95b1c99-eea9-462c-8240-2bd41b128bfb@github.com> On Wed, 24 Jul 2024 13:20:31 GMT, fabioromano1 wrote: >> The aim is not about having even more efficient code (yours is already faster than the existing algorithm), but to have simpler code. >> >> The two denormalization code snippets, while based on the same underlying math, are quite different in shape. Having just one denormalization code should be easier to read, understand, check, compare to the paper, and (possibly) evolve. > > @rgiulietti I simplified the code to fit the normalization/unnormalization with that of the paper's C code. @fabioromano1 I'll resume reviewing the PR sometimes next week, so you have some days left for some last-minute enhancements ;-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2252605117 From duke at openjdk.org Fri Jul 26 12:13:40 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 12:13:40 GMT Subject: Integrated: 8337168: Optimize LocalDateTime.toString In-Reply-To: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> Message-ID: On Thu, 25 Jul 2024 05:06:17 GMT, Shaojin Wen wrote: > The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. This pull request has now been integrated. Changeset: 5ff7c57f Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea Stats: 33 lines in 3 files changed: 23 ins; 3 del; 7 mod 8337168: Optimize LocalDateTime.toString Reviewed-by: liach, naoto ------------- PR: https://git.openjdk.org/jdk/pull/20321 From scolebourne at openjdk.org Fri Jul 26 12:27:38 2024 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Fri, 26 Jul 2024 12:27:38 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v4] In-Reply-To: <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> Message-ID: On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/time/LocalTime.java > > Co-authored-by: Chen Liang This change is fine, however the comments and performance testing assume that a date is always 10 characters long which isn't true, as the year could be greater than 9999. ------------- PR Review: https://git.openjdk.org/jdk/pull/20321#pullrequestreview-2201711797 From epeter at openjdk.org Fri Jul 26 12:39:35 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 26 Jul 2024 12:39:35 GMT Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null [v4] In-Reply-To: References: <8HwQQlslwxeOCDysbaQXSwrjWoHQW05RgrRJlxqcfyQ=.dafe2d7c-c48a-44c1-bbdf-7f6a85635dc6@github.com> <3Q_KYJ615tKdXXDRySx5DNLuOfzpLB9bjv19AiapjMI=.44e4d937-8736-4dba-970d-dcb6c38a1681@github.com> Message-ID: <7_TjBMxbbePoXnxXdp7QRmBlyxIrQS6sk3_RPsiOoIw=.39429044-b542-4bf6-9ba7-8fd10f5f9acc@github.com> On Thu, 25 Jul 2024 01:14:32 GMT, Shaojin Wen wrote: >> @cl4es I would wait, to be honest. I'm currently quite busy, but I hope I can do something here in the next 2-3 weeks. > > @eme64 Unsafe.putByte MergeStore of master branch doesn't work > > > import sun.misc.Unsafe; > > public class PutBytesTest { > static final Unsafe UNSAFE = JDKUtils.UNSAFE; > > // MergeStore not work > static void putCharsAt(byte[] val, int index, int c1, int c2, int c3, int c4) { > putByte(val, index , (byte)(c1)); > putByte(val, index + 1, (byte)(c2)); > putByte(val, index + 2, (byte)(c3)); > putByte(val, index + 3, (byte)(c4)); > } > > // MergeStore work > static void putCharsAtArrayStore(byte[] val, int index, int c1, int c2, int c3, int c4) { > val[index] = (byte) c1; > val[index + 1] = (byte) c2; > val[index + 2] = (byte) c3; > val[index + 3] = (byte) c4; > } > > static void putByte(byte[] bytes, int index, byte c) { > UNSAFE.putByte(bytes, Unsafe.ARRAY_BYTE_BASE_OFFSET + index, c); > } > > static void putNull(byte[] bytes, int index) { > putCharsAt(bytes, index, 'n', 'u', 'l', 'l'); > } > > public static void main(String[] args) { > for (int i = 0; i < 5; i++) { > testNull(); > } > System.out.println("done"); > } > > private static void testNull() { > byte[] bytes = new byte[4096]; > for (int i = 0; i < 1000; i++) { > int index = 0; > for (int j = 0; j < 1024; j++) { > putNull(bytes, index); > index += 4; > } > } > } > } @wenshao Yes, I am aware. I detected a bug with `Unsafe`, and now just disabled it. I'm trying to make it work again, but it will take some time, unfortunately. I need to be sure about the VM logic, and also sufficient testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2252675824 From liach at openjdk.org Fri Jul 26 13:19:32 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Jul 2024 13:19:32 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 08:03:01 GMT, Adam Sotona wrote: >> As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. >> >> Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. > > src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java line 67: > >> 65: this.maxLocals = Util.maxLocals(methodInfo.methodFlags(), methodInfo.methodTypeSymbol()); >> 66: if (original != null) >> 67: this.maxLocals = Math.max(this.maxLocals, original.maxLocals()); > > `original::maxLocals`set the counter for `CodeBuilder::allocateLocal` > By restricting calculation of maxLocals to "origin instanceof CodeAttribute" may cause invalid locals allocations for chained code builders. The number might not be exposed in the API, however we need to know it internally. I think we should just do `Util.maxLocals` without this `origin` check. Your said problem can happen too if a DirectMethodBuilder transforms a BufferedCodeBuilder.Model. Note that any code builder can receive a code model half way with `cob.transform(anyModel, CodeTransform.ACCEPT_ALL)`, which the buffered code builder initialization also uses. I think we should just ask users to use `CodeLocalsShifter` in that case, especially if the transform is inserting new locals. We cannot buffer existing chained builders for performance reasons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20338#discussion_r1693049481 From lancea at openjdk.org Fri Jul 26 13:39:42 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 26 Jul 2024 13:39:42 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 14:57:05 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into JDK-8322256 > - Wording tweak. > - Change concatenation policy config from booleans to new ConcatPolicy enum. > - Merge branch 'master' into JDK-8322256 > - Bump @since from 23 to 24. > - Merge branch 'master' into JDK-8322256 > - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. > - Simplify code by eliminating an impossible case. > - Field name change and Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - ... and 6 more: https://git.openjdk.org/jdk/compare/332df83e...72b60092 First thank you for your efforts and patience with this PR Archie. I am trying to better grasp the problem to be solved outside of better clarity surrounding how GZIPInputStream handles concatenated gzip files - I could see possibly providing an enum which indicates to stop decompressing after processing the first gzip file or to decompress until the end of input. - This would be similar to what the commons-compress GzipCompressorInputStream class does. - It is also what Eirik and Jai are suggesting I believe. - If support for processing multiple gzip files is enabled, which would be the default, then the existing behavior is not changed. - As I have mentioned previously, we should add more testing including taking a couple of concatenated examples created via the gzip tool (or equivalent) give how light our coverage is. I don't believe we want to do more than is needed given the age of the API and there is been minimal requests for improvements at this time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2252783484 From liach at openjdk.org Fri Jul 26 13:55:42 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Jul 2024 13:55:42 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v4] In-Reply-To: <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> Message-ID: On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/time/LocalTime.java > > Co-authored-by: Chen Liang It's my fault to not wait for sufficient reviews and downplay the importance of the comments. New comments can reveal more subtle mistakes in understanding of code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20321#issuecomment-2252820315 From duke at openjdk.org Fri Jul 26 14:29:45 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 14:29:45 GMT Subject: RFR: 8337279: Optimize format instant Message-ID: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. ------------- Commit messages: - optimize format instant Changes: https://git.openjdk.org/jdk/pull/20353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337279 Stats: 43 lines in 2 files changed: 7 ins; 31 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353 PR: https://git.openjdk.org/jdk/pull/20353 From duke at openjdk.org Fri Jul 26 14:29:45 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 14:29:45 GMT Subject: RFR: 8337279: Optimize format instant In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Fri, 26 Jul 2024 14:20:07 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. By removing redundant code logic, the codeSize can be reduced from 444 to 240, and the performance is improved. Below are the performance numbers running on MacBook M1 Pro -# master 5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea -Benchmark Mode Cnt Score Error Units -ToStringBench.instantToString thrpt 15 4.734 ? 0.547 ops/ms +24.10% +# current baf0f9ca83c111401d6e034dfba0ee2c71280e62 +Benchmark Mode Cnt Score Error Units +ToStringBench.instantToString thrpt 15 5.875 ? 0.301 ops/ms ------------- PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2252885851 From duke at openjdk.org Fri Jul 26 14:37:37 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 14:37:37 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v4] In-Reply-To: References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> Message-ID: On Fri, 26 Jul 2024 12:25:24 GMT, Stephen Colebourne wrote: > This change is fine, however the comments and performance testing assume that a date is always 10 characters long which isn't true, as the year could be greater than 9999. The scenario where year is greater than 9999 also works. This PR does not change the logic when year is greater than 9999, so there is no additional test for >9999 or <0. You can submit a PR to add testcases for scenarios >9999 and <0. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20321#issuecomment-2252902661 From liach at openjdk.org Fri Jul 26 14:41:38 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Jul 2024 14:41:38 GMT Subject: RFR: 8337168: Optimize LocalDateTime.toString [v4] In-Reply-To: <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> References: <51772pFvU-61DdntS0TQi439we5StTyZ07bF6zFvAVc=.638b6b78-5899-4137-8c55-149b4518e352@github.com> <4e1z6xXKYaJ_Ez6RS8Dhpy1SubJL2l7PpqnQGV6PXL0=.a9ce9f4e-dc80-4e73-9a2e-71c0bcce0fc4@github.com> Message-ID: On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote: >> The current LocalDateTime.toString implementation concatenates the toString results of date and time, which can be passed to StringBuilder to reduce additional object allocation and improve performance. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/time/LocalTime.java > > Co-authored-by: Chen Liang The logic is fine; it's that the comment is inaccurate, that there may be StringBuilder reallocations if the year is >9999 or <0. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20321#issuecomment-2252911244 From aph at openjdk.org Fri Jul 26 15:13:06 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Jul 2024 15:13:06 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v9] In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Fix test failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19989/files - new: https://git.openjdk.org/jdk/pull/19989/files/248f44dc..e9581019 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=07-08 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989 PR: https://git.openjdk.org/jdk/pull/19989 From scolebourne at openjdk.org Fri Jul 26 15:27:35 2024 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Fri, 26 Jul 2024 15:27:35 GMT Subject: RFR: 8337279: Optimize format instant In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Fri, 26 Jul 2024 14:20:07 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. src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3818: > 3816: } > 3817: // add fraction > 3818: if (fractionalDigits > 0) { This breaks the logic. `fractionalDigits` can be negative in the block below ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1693253379 From bpb at openjdk.org Fri Jul 26 15:30:01 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 26 Jul 2024 15:30:01 GMT Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v2] In-Reply-To: References: Message-ID: > Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8336895: s/dues/does/ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20320/files - new: https://git.openjdk.org/jdk/pull/20320/files/8ce5a299..9c024192 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20320/head:pull/20320 PR: https://git.openjdk.org/jdk/pull/20320 From duke at openjdk.org Fri Jul 26 15:34:34 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 15:34:34 GMT Subject: RFR: 8337279: Optimize format instant In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Fri, 26 Jul 2024 15:24:46 GMT, Stephen Colebourne wrote: >> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3818: > >> 3816: } >> 3817: // add fraction >> 3818: if (fractionalDigits > 0) { > > This breaks the logic. `fractionalDigits` can be negative in the block below If fractionalDigits < 0, printNano is implemented in LocalDateTime ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1693263366 From aph at openjdk.org Fri Jul 26 15:40:35 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Jul 2024 15:40:35 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v8] In-Reply-To: <2tItgZaRCa5BQrmelOWEsn6FVlHlEvY4is2L1n3HxhE=.eb2519cc-d69e-45e6-8ca3-b5b02565bb76@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> <0fk0Qo0HelMbG6l1d-hxUN504qx0ehO9uNxg9JrOeJU=.0b150931-21ea-4383-b6c2-85f6c74958d1@github.com> <2tItgZaRCa5BQrmelOWEsn6FVlHlEvY4is2L1n3HxhE=.eb2519cc-d69e-45e6-8ca3-b5b02565bb76@github.com> Message-ID: On Thu, 25 Jul 2024 23:31:21 GMT, Vladimir Ivanov wrote: > Thanks! The patch looks good, except there was one failure observed during testing with the latest patch [1]. It does look related to the latest changes you did in [54050a5](https://github.com/openjdk/jdk/pull/19989/commits/54050a5c2c0aa1d6a9e36d0240c66345765845e3) about `bitmap == SECONDARY_SUPERS_BITMAP_FULL` check. Wow! Whoever wrote that test case deserves a bouquet of roses. It's a super-edge case. If the hash slot of an interface is 63, and the secondaries array length of the Klass we're probing is 63, then the initial probe is at Offset 63, one past the array bounds. This bug happens because of an "optimization" created during the first round of reviews. If the secondaries array length is >= 62 (_not_ >= 63), we set the secondaries bitmap to `SECONDARY_SUPERS_BITMAP_FULL`. So, the initial probe sees a full bitmap, popcount returns 63, and we look at secondary_supers[63]. _Bang_. We never noticed this problem before because there's no bounds checking in the hand-coded assembly language implementations. The root cause of this bug is that we're not maintaining the invariant `popcount(bitmap) == secondary_supers()->length()`. There are a couple of ways to fix this. We could check `secondary_supers()->length()` before doing any probe. I'm very reluctant to add a memory load to the super-hot path for this edge case, though. It's better to take some pain in the case of an almost-full secondaries array, because those are very rare, and will never occur in most Java programs. So, i've corrected the bitmap at the point the hash table is constructed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2253019028 From duke at openjdk.org Fri Jul 26 15:44:59 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 15:44:59 GMT Subject: RFR: 8337279: Optimize format instant [v2] In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com> > 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: add comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20353/files - new: https://git.openjdk.org/jdk/pull/20353/files/baf0f9ca..64403d5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353 PR: https://git.openjdk.org/jdk/pull/20353 From acobbs at openjdk.org Fri Jul 26 15:47:37 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 26 Jul 2024 15:47:37 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7] In-Reply-To: References: Message-ID: <9t-8AvHkPK4bNYtMHlQ2OVRogftw3nmZAbI4cjF6esk=.d00ea61d-174a-4dcb-941b-3b1ce81b969a@github.com> On Fri, 26 Jul 2024 13:36:43 GMT, Lance Andersen wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into JDK-8322256 >> - Wording tweak. >> - Change concatenation policy config from booleans to new ConcatPolicy enum. >> - Merge branch 'master' into JDK-8322256 >> - Bump @since from 23 to 24. >> - Merge branch 'master' into JDK-8322256 >> - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. >> - Simplify code by eliminating an impossible case. >> - Field name change and Javadoc wording tweaks. >> - Merge branch 'master' into JDK-8322256 >> - ... and 6 more: https://git.openjdk.org/jdk/compare/332df83e...72b60092 > > First thank you for your efforts and patience with this PR Archie. > > I am trying to better grasp the problem to be solved outside of better clarity surrounding how GZIPInputStream handles concatenated gzip files > > - I could see possibly providing an enum which indicates to stop decompressing after processing the first gzip file or to decompress until the end of input. > - This would be similar to what the commons-compress GzipCompressorInputStream class does. > - It is also what Eirik and Jai are suggesting I believe. > - If support for processing multiple gzip files is enabled, which would be the default, then the existing behavior is not changed. > - As I have mentioned previously, we should add more testing including taking a couple of concatenated examples created via the gzip tool (or equivalent) give how light our coverage is. > > I don't believe we want to do more than is needed given the age of the API and there is been minimal requests for improvements at this time. Hi @LanceAndersen, Thanks for taking a look. Let's achieve consensus on what the goal(s) should be here, and then I think a proper API for that will come naturally. Up until now the discussion has been a shifting blend of API design and API goals which makes things a little bit chaotic (probably my fault). **Proposed Goal ?1:** This one seems relatively non-controversial: Allow creation of a `GZIPInputStream` that only decompresses one GZIP stream. OK but what does that mean exactly? * Option A: The `GZIPInputStream` will never read past the end of the GZIP trailer frame * Sounds great, but how exactly would that work? * Option A.1: Caller must provide a `BufferedInputStream`, so we can back it up if any extra bytes have been read past the trailer frame * Option A.2: `GZIPInputStream` provides a way for caller to access the extra bytes read once EOF is detected * Option A.3: `GZIPInputStream` never buffers more than 8 bytes (size of trailer frame) * Option B: `GZIPInputStream` attempts to read the byte after the trailer frame and throws `IOException` if EOF is not returned My opinion: All of the A options are unsatisfactory (although A.1 is the least bad), so it seems option B is the answer here. **Proposed Goal ?2:** This one seems more controversial: Allow the caller to configure `GZIPInputStream` for "strict mode". Just to be clear and restate what this is referring to. Currently, `GZIPInputStream` is hard-wired for "lenient mode". This means that it is indeterminate (a) how many additional bytes (if any) were read beyond the GZIP trailer frame, and (b) whether reading stopped due to EOF, invalid data, or an underlying`IOException`. My opinion: this is, at best, a random intermittent bug - **and at worst a giant security hole** - waiting to happen. Reasoning: If the caller is OK with lenient mode, then the caller obviously doesn't (or shouldn't) care about the data that follows the input stream (if any), because the caller won't even know whether there was any, how much of it has been discarded (if any), or whether it was actually another valid GZIP stream that got corrupted or threw an`IOException`. So why would any caller actually want to use this feature to concatenate anything useful after a GZIP trailer frame? In particular: if an underlying `IOException` occurs at just the wrong time, an application that wrote `GZIP-STREAM-1`, `GZIP-STREAM-2`, `GZIP-STREAM-3` could read back `GZIP-STREAM-1`, `GZIP-STREAM-2` and never know that anything was wrong. How useful is concatenated GZIP stream support if it's not even reliable?? This just seems completely wonky to me (and oh, did I mention it's a potential security hole waiting to happen? :) It seems like if concatenation is going to be a supported feature, then it should be possible to access a _reliable_ version of it. In other words, there should be a way for an application to say "I want to decode exactly ONE (or exactly N) whole GZIP streams _or else guarantee me an exception_". Maybe the answer is simply to tell people "Don't use this class, it's not reliable". I'd be OK with that I guess but it seems a bit of a cop out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2253031572 From duke at openjdk.org Fri Jul 26 15:55:34 2024 From: duke at openjdk.org (Andriy Plokhotnyuk) Date: Fri, 26 Jul 2024 15:55:34 GMT Subject: RFR: 8337279: Optimize format instant [v2] In-Reply-To: <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com> Message-ID: On Fri, 26 Jul 2024 15:44:59 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: > > add comment @jodastephen @wenshao Could you please review [these](https://github.com/openjdk/jdk/pull/11986) proposed changes for instantiation of `Instant` values with already normalized nanos? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2253044743 From duke at openjdk.org Fri Jul 26 16:04:46 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 16:04:46 GMT Subject: RFR: 8337282: Speed =?UTF-8?B?4oCL4oCLdXA=?= StringConcat with more simpleConcat Message-ID: StringConcatFactory improves startup speed and running performance through simpleConcat, but simpleConcat is currently given priority and only supports the following scenarios: // x instanceof Object prefix + x x = subfix // x instanceof Object && z instanceof Object x + y This PR improves startup and running performance by supporting more scenarios including // x instanceof byte/short/int/char/boolean/float/double prefix + x x + suffix // x instanceof byte/short/int/char/boolean/float/double/Integer/Long/Object prefix + suffix // x instanceof Object x + y + suffix // x instanceof Object x + y + suffix ------------- Commit messages: - more simpleConcat Changes: https://git.openjdk.org/jdk/pull/20355/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20355&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337282 Stats: 550 lines in 4 files changed: 509 ins; 15 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/20355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20355/head:pull/20355 PR: https://git.openjdk.org/jdk/pull/20355 From liach at openjdk.org Fri Jul 26 16:04:46 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Jul 2024 16:04:46 GMT Subject: RFR: 8337282: Speed =?UTF-8?B?4oCL4oCLdXA=?= StringConcat with more simpleConcat In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote: > StringConcatFactory improves startup speed and running performance through simpleConcat, but simpleConcat is currently given priority and only supports the following scenarios: > > // x instanceof Object > prefix + x > x = subfix > > // x instanceof Object && z instanceof Object > x + y > > > This PR improves startup and running performance by supporting more scenarios including > > // x instanceof byte/short/int/char/boolean/float/double > prefix + x > x + suffix > > // x instanceof byte/short/int/char/boolean/float/double/Integer/Long/Object > prefix + suffix > > // x instanceof Object > x + y + suffix > > // x instanceof Object > x + y + suffix I think instead of writing all these code out explicitly, we will instead aim for an approach more like `LambdaForm.Holder` or `DirectMethodHandle.Holder`; tools like `jlink` can generate these methods via `GenerateJLIClassesHelper` generating bytecode, which can be referred to by `StringConcatFactory`. Alternatively, we might check `VarHandles.GuardMethodGenerator`, where we have a dedicated generated file `VarHandleGuards` with "DO NOT EDIT" comments, also used the same way by MethodHandle linking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20355#issuecomment-2253058550 From duke at openjdk.org Fri Jul 26 16:13:30 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 16:13:30 GMT Subject: RFR: 8337282: Speed =?UTF-8?B?4oCL4oCLdXA=?= StringConcat with more simpleConcat In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote: > StringConcatFactory improves startup speed and running performance through simpleConcat, but simpleConcat is currently given priority and only supports the following scenarios: > > // x instanceof Object > prefix + x > x = subfix > > // x instanceof Object && z instanceof Object > x + y > > > This PR improves startup and running performance by supporting more scenarios including > > // x instanceof byte/short/int/char/boolean/float/double > prefix + x > x + suffix > > // x instanceof byte/short/int/char/boolean/float/double/Integer/Long/Object > prefix + suffix > > // x instanceof Object > x + y + suffix > > // x instanceof Object > x + y + suffix Below are the performance numbers running on MacBook M1 Pro -# baseline 5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea -Benchmark (intValue) Mode Cnt Score Error Units -StringConcat.concat123String 4711 avgt 15 989.444 ? 2.359 ns/op -StringConcat.concat13String 4711 avgt 15 45.880 ? 0.316 ns/op -StringConcat.concat23String 4711 avgt 15 90.688 ? 0.336 ns/op -StringConcat.concat23StringConst 4711 avgt 15 99.499 ? 0.165 ns/op -StringConcat.concat3String 4711 avgt 15 12.203 ? 0.178 ns/op -StringConcat.concat4String 4711 avgt 15 13.916 ? 0.163 ns/op -StringConcat.concat6String 4711 avgt 15 19.490 ? 0.368 ns/op -StringConcat.concatConst2String 4711 avgt 15 9.440 ? 0.093 ns/op -StringConcat.concatConst4String 4711 avgt 15 17.013 ? 3.545 ns/op -StringConcat.concatConst6Object 4711 avgt 15 50.599 ? 0.182 ns/op -StringConcat.concatConst6String 4711 avgt 15 19.641 ? 0.177 ns/op -StringConcat.concatConstBoolByte 4711 avgt 15 6.417 ? 0.028 ns/op -StringConcat.concatConstBooleanString 4711 avgt 15 7.022 ? 0.025 ns/op -StringConcat.concatConstFloat 4711 avgt 15 56.320 ? 1.348 ns/op -StringConcat.concatConstFloatString 4711 avgt 15 60.025 ? 1.879 ns/op -StringConcat.concatConstInt 4711 avgt 15 6.076 ? 0.037 ns/op -StringConcat.concatConstIntConstInt 4711 avgt 15 9.730 ? 0.151 ns/op -StringConcat.concatConstIntString 4711 avgt 15 14.339 ? 0.187 ns/op -StringConcat.concatConstInteger 4711 avgt 15 3.991 ? 0.024 ns/op -StringConcat.concatConstIntegerString 4711 avgt 15 6.895 ? 0.031 ns/op -StringConcat.concatConstString 4711 avgt 15 4.958 ? 0.021 ns/op -StringConcat.concatConstStringConstInt 4711 avgt 15 11.135 ? 1.184 ns/op -StringConcat.concatEmptyConstInt 4711 avgt 15 5.631 ? 0.066 ns/op -StringConcat.concatEmptyConstString 4711 avgt 15 2.019 ? 0.002 ns/op -StringConcat.concatEmptyLeft 4711 avgt 15 2.215 ? 0.017 ns/op -StringConcat.concatEmptyRight 4711 avgt 15 2.387 ? 0.058 ns/op -StringConcat.concatMethodConstString 4711 avgt 15 4.972 ? 0.014 ns/op -StringConcat.concatMix4String 4711 avgt 15 80.159 ? 2.225 ns/op -StringConcat.concatStringIntString 4711 avgt 15 18.138 ? 0.428 ns/op -StringConcat.concatStringIntegerString 4711 avgt 15 9.031 ? 0.034 ns/op -StringConcatStartup.MixedLarge.run N/A ss 10 310.643 ? 9.422 ms/op -StringConcatStartup.MixedSmall.run N/A ss 20 24.493 ? 0.583 ms/op -StringConcatStartup.StringLarge.run N/A ss 10 86.554 ? 3.910 ms/op -StringConcatStartup.StringSingle.constBooleanString 4711 ss 40 0.261 ? 0.010 ms/op -StringConcatStartup.StringSingle.constFloat 4711 ss 40 2.580 ? 0.083 ms/op -StringConcatStartup.StringSingle.constFloatString 4711 ss 40 4.465 ? 0.115 ms/op -StringConcatStartup.StringSingle.constInt 4711 ss 40 2.056 ? 0.056 ms/op -StringConcatStartup.StringSingle.constIntString 4711 ss 40 0.159 ? 0.009 ms/op -StringConcatStartup.StringSingle.constInteger 4711 ss 40 0.140 ? 0.008 ms/op -StringConcatStartup.StringSingle.constIntegerString 4711 ss 40 3.522 ? 0.080 ms/op -StringConcatStartup.StringSingle.constString 4711 ss 40 0.138 ? 0.010 ms/op -StringConcatStartup.StringThree.stringIntString 4711 ss 40 6.051 ? 0.156 ms/op -StringConcatStartup.StringThree.stringIntegerString 4711 ss 40 5.115 ? 0.166 ms/op +# current 37f42b1065663337acd2d91a40e0a34010ebcfa3 +Benchmark (intValue) Mode Cnt Score Error Units +StringConcat.concat123String 4711 avgt 15 992.155 ? 7.624 ns/op +StringConcat.concat13String 4711 avgt 15 45.763 ? 0.156 ns/op +StringConcat.concat23String 4711 avgt 15 90.949 ? 0.508 ns/op +StringConcat.concat23StringConst 4711 avgt 15 99.758 ? 0.517 ns/op +StringConcat.concat3String 4711 avgt 15 12.564 ? 0.303 ns/op +StringConcat.concat4String 4711 avgt 15 13.827 ? 0.129 ns/op +StringConcat.concat6String 4711 avgt 15 19.679 ? 0.372 ns/op +StringConcat.concatConst2String 4711 avgt 15 7.233 ? 0.038 ns/op +StringConcat.concatConst4String 4711 avgt 15 14.763 ? 0.077 ns/op +StringConcat.concatConst6Object 4711 avgt 15 50.771 ? 0.206 ns/op +StringConcat.concatConst6String 4711 avgt 15 19.565 ? 0.102 ns/op +StringConcat.concatConstBoolByte 4711 avgt 15 6.412 ? 0.008 ns/op +StringConcat.concatConstBooleanString 4711 avgt 15 5.259 ? 0.009 ns/op +StringConcat.concatConstFloat 4711 avgt 15 53.374 ? 0.755 ns/op +StringConcat.concatConstFloatString 4711 avgt 15 61.902 ? 2.410 ns/op +StringConcat.concatConstInt 4711 avgt 15 4.955 ? 0.017 ns/op +StringConcat.concatConstIntConstInt 4711 avgt 15 9.742 ? 0.141 ns/op +StringConcat.concatConstIntString 4711 avgt 15 8.284 ? 0.027 ns/op +StringConcat.concatConstInteger 4711 avgt 15 3.996 ? 0.016 ns/op +StringConcat.concatConstIntegerString 4711 avgt 15 5.942 ? 0.098 ns/op +StringConcat.concatConstString 4711 avgt 15 4.972 ? 0.018 ns/op +StringConcat.concatConstStringConstInt 4711 avgt 15 11.326 ? 1.466 ns/op +StringConcat.concatEmptyConstInt 4711 avgt 15 5.600 ? 0.025 ns/op +StringConcat.concatEmptyConstString 4711 avgt 15 2.043 ? 0.031 ns/op +StringConcat.concatEmptyLeft 4711 avgt 15 2.242 ? 0.030 ns/op +StringConcat.concatEmptyRight 4711 avgt 15 2.356 ? 0.035 ns/op +StringConcat.concatMethodConstString 4711 avgt 15 4.969 ? 0.016 ns/op +StringConcat.concatMix4String 4711 avgt 15 80.263 ? 2.323 ns/op +StringConcat.concatStringIntString 4711 avgt 15 18.328 ? 0.411 ns/op +StringConcat.concatStringIntegerString 4711 avgt 15 9.019 ? 0.025 ns/op +StringConcatStartup.MixedLarge.run N/A ss 10 317.535 ? 20.464 ms/op +StringConcatStartup.MixedSmall.run N/A ss 20 24.886 ? 0.607 ms/op +StringConcatStartup.StringLarge.run N/A ss 10 85.655 ? 3.967 ms/op +StringConcatStartup.StringSingle.constBooleanString 4711 ss 40 0.575 ? 0.021 ms/op +StringConcatStartup.StringSingle.constFloat 4711 ss 40 1.035 ? 0.038 ms/op +StringConcatStartup.StringSingle.constFloatString 4711 ss 40 0.747 ? 0.023 ms/op +StringConcatStartup.StringSingle.constInt 4711 ss 40 0.844 ? 0.030 ms/op +StringConcatStartup.StringSingle.constIntString 4711 ss 40 0.559 ? 0.020 ms/op +StringConcatStartup.StringSingle.constInteger 4711 ss 40 0.154 ? 0.013 ms/op +StringConcatStartup.StringSingle.constIntegerString 4711 ss 40 0.438 ? 0.017 ms/op +StringConcatStartup.StringSingle.constString 4711 ss 40 0.149 ? 0.010 ms/op +StringConcatStartup.StringThree.stringIntString 4711 ss 40 5.995 ? 0.140 ms/op +StringConcatStartup.StringThree.stringIntegerString 4711 ss 40 5.295 ? 0.112 ms/op | | baseline | current | delta | | --- | --- | --- | --- | | StringConcat.concat123String | 989.444 | 992.155 | -0.27% | | StringConcat.concat13String | 45.880 | 45.763 | 0.26% | | StringConcat.concat23String | 90.688 | 90.949 | -0.29% | | StringConcat.concat23StringConst | 99.499 | 99.758 | -0.26% | | StringConcat.concat3String | 12.203 | 12.564 | -2.87% | | StringConcat.concat4String | 13.916 | 13.827 | 0.64% | | StringConcat.concat6String | 19.490 | 19.679 | -0.96% | | StringConcat.concatConst2String | 9.440 | 7.233 | 30.51% | | StringConcat.concatConst4String | 17.013 | 14.763 | 15.24% | | StringConcat.concatConst6Object | 50.599 | 50.771 | -0.34% | | StringConcat.concatConst6String | 19.641 | 19.565 | 0.39% | | StringConcat.concatConstBoolByte | 6.417 | 6.412 | 0.08% | | StringConcat.concatConstBooleanString | 7.022 | 5.259 | 33.52% | | StringConcat.concatConstFloat | 56.320 | 53.374 | 5.52% | | StringConcat.concatConstFloatString | 60.025 | 61.902 | -3.03% | | StringConcat.concatConstInt | 6.076 | 4.955 | 22.62% | | StringConcat.concatConstIntConstInt | 9.730 | 9.742 | -0.12% | | StringConcat.concatConstIntString | 14.339 | 8.284 | 73.09% | | StringConcat.concatConstInteger | 3.991 | 3.996 | -0.13% | | StringConcat.concatConstIntegerString | 6.895 | 5.942 | 16.04% | | StringConcat.concatConstString | 4.958 | 4.972 | -0.28% | | StringConcat.concatConstStringConstInt | 11.135 | 11.326 | -1.69% | | StringConcat.concatEmptyConstInt | 5.631 | 5.600 | 0.55% | | StringConcat.concatEmptyConstString | 2.019 | 2.043 | -1.17% | | StringConcat.concatEmptyLeft | 2.215 | 2.242 | -1.20% | | StringConcat.concatEmptyRight | 2.387 | 2.356 | 1.32% | | StringConcat.concatMethodConstString | 4.972 | 4.969 | 0.06% | | StringConcat.concatMix4String | 80.159 | 80.263 | -0.13% | | StringConcat.concatStringIntString | 18.138 | 18.328 | -1.04% | | StringConcat.concatStringIntegerString | 9.031 | 9.019 | 0.13% | | StringConcatStartup.MixedLarge.run | 310.643 | 317.535 | -2.17% | | StringConcatStartup.MixedSmall.run | 24.493 | 24.886 | -1.58% | | StringConcatStartup.StringLarge.run | 86.554 | 85.655 | 1.05% | | StringConcatStartup.StringSingle.constBooleanString | 0.261 | 0.575 | -54.61% | | StringConcatStartup.StringSingle.constFloat | 2.580 | 1.035 | 149.28% | | StringConcatStartup.StringSingle.constFloatString | 4.465 | 0.747 | 497.72% | | StringConcatStartup.StringSingle.constInt | 2.056 | 0.844 | 143.60% | | StringConcatStartup.StringSingle.constIntString | 0.159 | 0.559 | -71.56% | | StringConcatStartup.StringSingle.constInteger | 0.140 | 0.154 | -9.09% | | StringConcatStartup.StringSingle.constIntegerString | 3.522 | 0.438 | 704.11% | | StringConcatStartup.StringSingle.constString | 0.138 | 0.149 | -7.38% | | StringConcatStartup.StringThree.stringIntString | 6.051 | 5.995 | 0.93% | | StringConcatStartup.StringThree.stringIntegerString | 5.115 | 5.295 | -3.40% | * Scenarios with Significantly Improved Running Performance | | baseline | current | delta | | --- | --- | --- | --- | | StringConcat.concatConst2String | 9.440 | 7.233 | 30.51% | | StringConcat.concatConstBooleanString | 7.022 | 5.259 | 33.52% | | StringConcat.concatConstInt | 6.076 | 4.955 | 22.62% | | StringConcat.concatConstIntString | 14.339 | 8.284 | 73.09% | | StringConcat.concatConstIntegerString | 6.895 | 5.942 | 16.04% | * Startup performance significantly improved | | baseline | current | delta | | --- | --- | --- | --- | | StringConcatStartup.StringSingle.constFloat | 2.580 | 1.035 | 149.28% | | StringConcatStartup.StringSingle.constFloatString | 4.465 | 0.747 | 497.72% | | StringConcatStartup.StringSingle.constInt | 2.056 | 0.844 | 143.60% | | StringConcatStartup.StringSingle.constIntegerString | 3.522 | 0.438 | 704.11% | ------------- PR Comment: https://git.openjdk.org/jdk/pull/20355#issuecomment-2253071979 From jpai at openjdk.org Fri Jul 26 16:14:34 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 26 Jul 2024 16:14:34 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 14:57:05 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into JDK-8322256 > - Wording tweak. > - Change concatenation policy config from booleans to new ConcatPolicy enum. > - Merge branch 'master' into JDK-8322256 > - Bump @since from 23 to 24. > - Merge branch 'master' into JDK-8322256 > - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. > - Simplify code by eliminating an impossible case. > - Field name change and Javadoc wording tweaks. > - Merge branch 'master' into JDK-8322256 > - ... and 6 more: https://git.openjdk.org/jdk/compare/332df83e...72b60092 Hello Archie, I don't think we need any enum in the API. GZIPInputStream class should only allow parsing GZIP streams. The InputStream passed to the GZIPInputStream constructor must be a InputStream which has either 1 GZIP stream or N GZIP streams (concatenated). The user should be allowed to state whether the passed InputStream is expected contain more than 1 GZIP stream. This is the only addition that I think we should be introducing. The way to allow users to state that the InputStream being passed is allowed to have more than 1 GZIP stream is through the new proposed boolean to the constructor. The boolean can be named "allowConcatenated". When allowConcatenated is true, then during the read() operation on the GZIPInputStream, when we internally read a GZIP stream trailer, we should check if the underlying InputStream has a next GZIP stream header: - If there's no bytes present after the trailer, we just return whatever data we have inflated so far and that also would be the end-of-stream of the GZIPInputStream. - If there's bytes after the trailer, then those next bytes MUST be the next GZIP stream header. If those bytes aren't a GZIP stream header, then we throw an IOException. This implies whatever data we had deflated and any additional bytes that we had read after the trailer will not be returned to the user. That's fine because the underlying InputStream was "corrupt" - the GZIPInputStream shouldn't expect any other data other than GZIP stream(s) in the underlying InputStream. When allowConcatenated is false, then during the read() operation on the GZIPInputStream, when we internally read a GZIP stream trailer, we should check if the underlying InputStream has any more bytes remaining: - If there are bytes remaining then we consider that an error and raise an IOException. We do this because we were instructed not to allow concatenated GZIP streams. So presence of any data after the first GZIP stream trailer should be an exception. - If there are no more bytes remaining then we have reached the end-of-stream and we return back whatever GZIP data we have inflated during the read operation and that also would be the end-of-stream of the GZIPStream instance. The default value for allowConcatenated should be true to allow for supporting concatenated GZIP streams (like we do now). There however will be a change in behaviour if the stream content after the trailer isn't a GZIP stream. With this new proposed change we will throw an IOException (unlike previously). I think that's fine and in fact the correct thing to do. It of course will need a CSR and a release note to note this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2253075317 From acobbs at openjdk.org Fri Jul 26 16:49:34 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 26 Jul 2024 16:49:34 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 16:12:11 GMT, Jaikiran Pai wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into JDK-8322256 >> - Wording tweak. >> - Change concatenation policy config from booleans to new ConcatPolicy enum. >> - Merge branch 'master' into JDK-8322256 >> - Bump @since from 23 to 24. >> - Merge branch 'master' into JDK-8322256 >> - Relabel "trailing garbage" as "extra bytes" to sound less accusatory. >> - Simplify code by eliminating an impossible case. >> - Field name change and Javadoc wording tweaks. >> - Merge branch 'master' into JDK-8322256 >> - ... and 6 more: https://git.openjdk.org/jdk/compare/332df83e...72b60092 > > Hello Archie, I don't think we need any enum in the API. GZIPInputStream class should only allow parsing GZIP streams. The InputStream passed to the GZIPInputStream constructor must be a InputStream which has either 1 GZIP stream or N GZIP streams (concatenated). The user should be allowed to state whether the passed InputStream is expected contain more than 1 GZIP stream. This is the only addition that I think we should be introducing. > > The way to allow users to state that the InputStream being passed is allowed to have more than 1 GZIP stream is through the new proposed boolean to the constructor. The boolean can be named "allowConcatenated". > > When allowConcatenated is true, then during the read() operation on the GZIPInputStream, when we internally read a GZIP stream trailer, we should check if the underlying InputStream has a next GZIP stream header: > - If there's no bytes present after the trailer, we just return whatever data we have inflated so far and that also would be the end-of-stream of the GZIPInputStream. > - If there's bytes after the trailer, then those next bytes MUST be the next GZIP stream header. If those bytes aren't a GZIP stream header, then we throw an IOException. This implies whatever data we had deflated and any additional bytes that we had read after the trailer will not be returned to the user. That's fine because the underlying InputStream was "corrupt" - the GZIPInputStream shouldn't expect any other data other than GZIP stream(s) in the underlying InputStream. > > When allowConcatenated is false, then during the read() operation on the GZIPInputStream, when we internally read a GZIP stream trailer, we should check if the underlying InputStream has any more bytes remaining: > - If there are bytes remaining then we consider that an error and raise an IOException. We do this because we were instructed not to allow concatenated GZIP streams. So presence of any data after the first GZIP stream trailer should be an exception. > - If there are no more bytes remaining then we have reached the end-of-stream and we return back whatever GZIP data we have inflated during the read operation and that also would be the end-of-stream of the GZIPStream instance. > > The default value for allowConcatenated should be true to allow for supporting concatenated GZIP streams (like we do now). There however will be a change in behaviour if the stream content after the trailer isn't a GZIP stream. With this new proposed change we will throw an IOException ... Hi @jaikiran, > There however will be a change in behaviour if the stream content after the trailer isn't a GZIP stream. With this new proposed change we will throw an IOException (unlike previously). I think that's fine and in fact the correct thing to do. Ah! This simplifies everything. I was just assuming that preserving the existing behavior was a hard requirement - but if not, we can make this class "always precise", and the only thing left to configure is whether to allow 1 stream or N streams. I am in complete agreement with you now, especially because this eliminates the aforementioned security concern. I'm assuming you and @LanceAndersen have communicated and he is OK with this as well. I will update the PR and CSR. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2253125776 From duke at openjdk.org Fri Jul 26 16:50:15 2024 From: duke at openjdk.org (fabioromano1) Date: Fri, 26 Jul 2024 16:50:15 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v41] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Code simplification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/27f0c8c7..608c05c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=40 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=39-40 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From rriggs at openjdk.org Fri Jul 26 18:05:35 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 26 Jul 2024 18:05:35 GMT Subject: RFR: 8337279: Optimize format instant [v2] In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com> Message-ID: On Fri, 26 Jul 2024 15:53:11 GMT, Andriy Plokhotnyuk wrote: > Could you please review [these](https://github.com/openjdk/jdk/pull/11986) proposed changes for instantiation of `Instant` values with already normalized nanos? @plokhotnyuk Your contribution cannot be acted upon until the OCA is confirmed. If you have not submitted an OCA, please do so. See https://oca.opensource.oracle.com/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2253234822 From vlivanov at openjdk.org Fri Jul 26 18:43:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 26 Jul 2024 18:43:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v9] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: On Fri, 26 Jul 2024 15:13:06 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix test failure Oh, it comes as a surprise to me... I was under impression that the first thing hand-coded assembly variants do is check for `bitmap != SECONDARY_SUPERS_BITMAP_FULL`. At least, it was my recollection from working on [JDK-8180450](https://bugs.openjdk.org/browse/JDK-8180450). (And the initial version of the patch with the check in `Klass::lookup_secondary_supers_table()` and `_bitmap(SECONDARY_SUPERS_BITMAP_FULL)` only reassured me that's still the case.) > The root cause of this bug is that we're not maintaining the invariant popcount(bitmap) == secondary_supers()->length(). The invariant holds only when `bitmap != SECONDARY_SUPERS_BITMAP_FULL`. It does help that even in case of non-hashed `secondary_supers` list `secondary_supers()->length() >= popcount(bitmap)`, but initial probing becomes much less efficient (a random probe followed by a full linear pass over secondary supers list). Alternatively, all table lookups can be adjusted to start with `bitmap != SECONDARY_SUPERS_BITMAP_FULL` checks before probing the table. It does add a branch on the fast path (and slightly increases inlined snippet code size), but the branch is highly predictable and works on a value we need anyway. So, I would be surprised to see any performance effects from it. IMO it's easier to reason and more flexible: `SECONDARY_SUPERS_BITMAP_FULL == bitmap` simply disables all table lookups and unconditionally falls back to linear search. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2253281836 From phh at openjdk.org Fri Jul 26 18:58:30 2024 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Jul 2024 18:58:30 GMT Subject: RFR: 8337245: Fix wrong comment of StringConcatHelper In-Reply-To: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> References: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> Message-ID: On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote: > 8337245: Fix wrong comment of StringConcatHelper Trivial. ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20344#pullrequestreview-2202564779 From jlu at openjdk.org Fri Jul 26 19:21:39 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 26 Jul 2024 19:21:39 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage Message-ID: Please review this PR which is a simple doc only change to java.text.DecimalFormat. Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/20361/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337285 Stats: 43 lines in 1 file changed: 13 ins; 16 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361 PR: https://git.openjdk.org/jdk/pull/20361 From bpb at openjdk.org Fri Jul 26 19:40:24 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 26 Jul 2024 19:40:24 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v2] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: 8337143: Move natives to /native/libjava/nio/{ch,fs} as a function of their original location in libnio ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20317/files - new: https://git.openjdk.org/jdk/pull/20317/files/744fa359..48519737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=00-01 Stats: 0 lines in 21 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From naoto at openjdk.org Fri Jul 26 20:09:31 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 26 Jul 2024 20:09:31 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 19:17:34 GMT, Justin Lu wrote: > Please review this PR which is a simple doc only change to java.text.DecimalFormat. > > Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. > > A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. src/java.base/share/classes/java/text/DecimalFormat.java line 441: > 439: * @see NumberFormat#getNumberInstance() > 440: * @see NumberFormat#getCurrencyInstance() > 441: * @see NumberFormat#getPercentInstance() The paragraph is for a "given" locale, probably factories that take Locale would be more appropriate than no-arg ones. (applies to other locations too) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693536829 From jlu at openjdk.org Fri Jul 26 20:45:43 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 26 Jul 2024 20:45:43 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v2] In-Reply-To: References: Message-ID: <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com> > Please review this PR which is a simple doc only change to java.text.DecimalFormat. > > Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. > > A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20361/files - new: https://git.openjdk.org/jdk/pull/20361/files/562a44ed..c16bfab1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361 PR: https://git.openjdk.org/jdk/pull/20361 From jlu at openjdk.org Fri Jul 26 20:45:43 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 26 Jul 2024 20:45:43 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v2] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 20:05:53 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect review > > src/java.base/share/classes/java/text/DecimalFormat.java line 441: > >> 439: * @see NumberFormat#getNumberInstance() >> 440: * @see NumberFormat#getCurrencyInstance() >> 441: * @see NumberFormat#getPercentInstance() > > The paragraph is for a "given" locale, probably factories that take Locale would be more appropriate than no-arg ones. (applies to other locations too) I picked the no-arg methods because I imagine most users want the default locale instance. But I agree that it makes sense to use the Locale arg methods, since the phrasing does say "given locale" (twice). Updated here and in the other instances, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693589378 From liach at openjdk.org Fri Jul 26 21:07:31 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Jul 2024 21:07:31 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v2] In-Reply-To: <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com> References: <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com> Message-ID: On Fri, 26 Jul 2024 20:45:43 GMT, Justin Lu wrote: >> Please review this PR which is a simple doc only change to java.text.DecimalFormat. >> >> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. >> >> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review src/java.base/share/classes/java/text/DecimalFormat.java line 438: > 436: * NumberFormat#getNumberInstance(Locale)}. These factories will return the most > 437: * appropriate subclass of NumberFormat for a given locale. > 438: * @see NumberFormat#getInstance() Suggestion: * @see NumberFormat#getInstance(Locale) and for other such links. I second @naotoj's remark. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693605351 From jlu at openjdk.org Fri Jul 26 21:22:58 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 26 Jul 2024 21:22:58 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v3] In-Reply-To: References: Message-ID: > Please review this PR which is a simple doc only change to java.text.DecimalFormat. > > Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. > > A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: update see links with Locale arg link ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20361/files - new: https://git.openjdk.org/jdk/pull/20361/files/c16bfab1..344d82c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=01-02 Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361 PR: https://git.openjdk.org/jdk/pull/20361 From jlu at openjdk.org Fri Jul 26 21:22:59 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 26 Jul 2024 21:22:59 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v2] In-Reply-To: References: <7vGY09-oOSMdnpjiX2n5YziB4QrixDZQr3n4dZw6bdE=.f8212f3e-1793-43bc-b330-9f860e675702@github.com> Message-ID: On Fri, 26 Jul 2024 21:05:07 GMT, Chen Liang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect review > > src/java.base/share/classes/java/text/DecimalFormat.java line 438: > >> 436: * NumberFormat#getNumberInstance(Locale)}. These factories will return the most >> 437: * appropriate subclass of NumberFormat for a given locale. >> 438: * @see NumberFormat#getInstance() > > Suggestion: > > * @see NumberFormat#getInstance(Locale) > > and for other such links. I second @naotoj's remark. Thanks, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693615845 From liach at openjdk.org Fri Jul 26 21:26:31 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Jul 2024 21:26:31 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v3] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 21:22:58 GMT, Justin Lu wrote: >> Please review this PR which is a simple doc only change to java.text.DecimalFormat. >> >> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. >> >> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > update see links with Locale arg link Thanks for the fixes. Reviewed the up-to-date CSR too. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20361#pullrequestreview-2202768206 From liach at openjdk.org Fri Jul 26 21:31:30 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Jul 2024 21:31:30 GMT Subject: RFR: 8337282: Speed =?UTF-8?B?4oCL4oCLdXA=?= StringConcat with more simpleConcat In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote: > StringConcatFactory improves startup speed and running performance through simpleConcat, but simpleConcat is currently given priority and only supports the following scenarios: > > // x instanceof Object > prefix + x > x = subfix > > // x instanceof Object && z instanceof Object > x + y > > > This PR improves startup and running performance by supporting more scenarios including > > // x instanceof byte/short/int/char/boolean/float/double > prefix + x > x + suffix > > // x instanceof byte/short/int/char/boolean/float/double/Integer/Long/Object > prefix + suffix > > // x instanceof Object > x + y + suffix > > // x instanceof Object > x + y + suffix I don't think this pr will ever get merged, but this will be a good experiment mailing list thread for investigating whether to generate similar simpleConcat in bytecode for String concatenation. || baseline | current | delta -- | -- | -- | -- StringConcatStartup.StringSingle.constIntString | 0.159 | 0.559 | -71.56% StringConcatStartup.StringSingle.constBooleanString | 0.261 | 0.575 | -54.61% StringConcatStartup.StringSingle.constInteger | 0.140 | 0.154 | -9.09% StringConcatStartup.StringSingle.constString | 0.138 | 0.149 | -7.38% There are non-trivial slowdowns. Can you explain why these slowdowns happen, and is there some particular types of simpleConcat that benefit more from your specialization that they indeed should be specialized? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20355#issuecomment-2253532207 From bpb at openjdk.org Fri Jul 26 21:36:33 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 26 Jul 2024 21:36:33 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com> References: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com> Message-ID: On Thu, 25 Jul 2024 10:05:03 GMT, Alan Bateman wrote: > Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use. Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only by classes involved in networking? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2253537627 From aph at openjdk.org Fri Jul 26 21:36:34 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Jul 2024 21:36:34 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v9] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: On Fri, 26 Jul 2024 18:39:27 GMT, Vladimir Ivanov wrote: > Oh, it comes as a surprise to me... I was under impression that the first thing hand-coded assembly variants do is check for `bitmap != SECONDARY_SUPERS_BITMAP_FULL`. At least, it was my recollection from working on [JDK-8180450](https://bugs.openjdk.org/browse/JDK-8180450). (And the initial version of the patch with the check in `Klass::lookup_secondary_supers_table()` and `_bitmap(SECONDARY_SUPERS_BITMAP_FULL)` only reassured me that's still the case.) > > > The root cause of this bug is that we're not maintaining the invariant popcount(bitmap) == secondary_supers()->length(). > > The invariant holds only when `bitmap != SECONDARY_SUPERS_BITMAP_FULL`. Yes, exactly so. That's what I intended to mean. > It does help that even in case of non-hashed `secondary_supers` list `secondary_supers()->length() >= popcount(bitmap)`, but initial probing becomes much less efficient (a random probe followed by a full linear pass over secondary supers list). > > Alternatively, all table lookups can be adjusted to start with `bitmap != SECONDARY_SUPERS_BITMAP_FULL` checks before probing the table. It does add a branch on the fast path (and slightly increases inlined snippet code size), but the branch is highly predictable and works on a value we need anyway. True enough. I've been trying to move as much as I can out of the inlined code, though. > So, I would be surprised to see any performance effects from it. IMO it's easier to reason and more flexible: `SECONDARY_SUPERS_BITMAP_FULL == bitmap` simply disables all table lookups and unconditionally falls back to linear search. I take your point. But that seems like it's a bit of a sledgehammer to crack a walnut, don't you think? Given that it's only necessary to fix a rare edge case. But I'm not going to be precious about this choice, I'll test for a full bitmap first if you prefer. It's only a couple of instructions, but they are in the fast path that is successful in almost 99% of cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2253537338 From bpb at openjdk.org Fri Jul 26 21:44:36 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 26 Jul 2024 21:44:36 GMT Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v2] In-Reply-To: References: Message-ID: <9q1y7kg3_IMvY34zK4_2mvHtcdGNrKpXBQpWZD29sc0=.25b0b772-0b57-4277-bf02-870bef75be6b@github.com> On Fri, 26 Jul 2024 04:40:35 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8336895: s/dues/does/ > > src/java.base/share/classes/java/io/BufferedInputStream.java line 56: > >> 54: * to read from the same {@code InputStream}. There is no way for a >> 55: * {@code BufferedInputStream} to know what another {@code BufferedInputStream} >> 56: * has read from the underlying {@code InputStream}, nor dues it have access > > Hello Brian, there's a typo here - should have been "does" instead of "dues". Same in the other class in this PR. Fixed in [9c02419](https://github.com/openjdk/jdk/pull/20320/commits/9c02419241f31ff5c2c665eb3d934599f216445f), thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1693628891 From vlivanov at openjdk.org Fri Jul 26 22:01:38 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 26 Jul 2024 22:01:38 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v9] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: <6elom8uMJFqHyYuOgOk56W_YuIczI5vTlDcYKXUKr2Q=.51a5c0e5-6342-4e57-af8e-0fe9b1f3648e@github.com> On Fri, 26 Jul 2024 15:13:06 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix test failure Yes, I'm in favor of avoiding probing the table when `SECONDARY_SUPERS_BITMAP_FULL == bitmap`. It doesn't look right when the code treats `secondary_supers` as a table irrespective of whether it was hashed or not. IMO it unnecessarily complicates things and may continue to be a source of bugs. Also, you can rearrange fast path checks: probe the home slot bit first, then check for `SECONDARY_SUPERS_BITMAP_FULL != bitmap` before accessing `secondary_supers`. It won't help with inlined code size increase, but negative lookups will stay mostly unaffected by the additional check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2253563566 From rriggs at openjdk.org Fri Jul 26 22:28:59 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 26 Jul 2024 22:28:59 GMT Subject: RFR: 8336934: Clean up JavaLangReflectAccess [v2] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 22:33:44 GMT, Chen Liang wrote: >> Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`. >> >> The cleanup in `JavaLangReflectAccess` is: >> - Converted `newConstructor` taking parameters to taking another constructor and a new accessor. The old existing API essentially does a copy and sets an accessor. >> - Removed lots of constructor getters, unused after `newConstructor` cleanup. >> - Removed accessor getter/setters, unused after `newConstructor` cleanup. >> - Removed `leafCopyMethod`. We can already use `getRoot` plus `copyMethod` to achieve the same effect. > > 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: > > - Remove editor folds, improve comments > - Merge branch 'm5' into cleanup/reflect-access > - 8336934: Clean up JavaLangReflectAccess looks good to me. Thanks for the comments and updated description. Another person familiar with the reflection implementation should review this also ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20290#pullrequestreview-2202820120 PR Comment: https://git.openjdk.org/jdk/pull/20290#issuecomment-2253589168 From bpb at openjdk.org Fri Jul 26 22:32:40 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 26 Jul 2024 22:32:40 GMT Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3] In-Reply-To: References: Message-ID: > Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8336895: Modified verbiage per reviewer comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20320/files - new: https://git.openjdk.org/jdk/pull/20320/files/9c024192..268b5eec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=01-02 Stats: 21 lines in 4 files changed: 10 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20320/head:pull/20320 PR: https://git.openjdk.org/jdk/pull/20320 From naoto at openjdk.org Fri Jul 26 22:55:41 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 26 Jul 2024 22:55:41 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v3] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 21:22:58 GMT, Justin Lu wrote: >> Please review this PR which is a simple doc only change to java.text.DecimalFormat. >> >> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. >> >> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > update see links with Locale arg link src/java.base/share/classes/java/text/DecimalFormat.java line 478: > 476: * @see NumberFormat#getCurrencyInstance(Locale) > 477: * @see NumberFormat#getPercentInstance(Locale) > 478: * @see NumberFormat#getPercentInstance(Locale) This seems to be a dup ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693663620 From jlu at openjdk.org Fri Jul 26 23:02:14 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 26 Jul 2024 23:02:14 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v4] In-Reply-To: References: Message-ID: > Please review this PR which is a simple doc only change to java.text.DecimalFormat. > > Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. > > A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: remove duplicate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20361/files - new: https://git.openjdk.org/jdk/pull/20361/files/344d82c9..98670109 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20361&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20361/head:pull/20361 PR: https://git.openjdk.org/jdk/pull/20361 From jlu at openjdk.org Fri Jul 26 23:02:14 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 26 Jul 2024 23:02:14 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v3] In-Reply-To: References: Message-ID: <-pfU6d7RoajUXUSFVbLqmcb3J45Xdt5eXYCUZD6kfgw=.19696350-ab3e-4d7b-b80e-7c358a90fdc8@github.com> On Fri, 26 Jul 2024 22:51:26 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> update see links with Locale arg link > > src/java.base/share/classes/java/text/DecimalFormat.java line 478: > >> 476: * @see NumberFormat#getCurrencyInstance(Locale) >> 477: * @see NumberFormat#getPercentInstance(Locale) >> 478: * @see NumberFormat#getPercentInstance(Locale) > > This seems to be a dup Removed, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20361#discussion_r1693677723 From naoto at openjdk.org Fri Jul 26 23:26:41 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 26 Jul 2024 23:26:41 GMT Subject: RFR: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage [v4] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 23:02:14 GMT, Justin Lu wrote: >> Please review this PR which is a simple doc only change to java.text.DecimalFormat. >> >> Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. >> >> A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > remove duplicate LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20361#pullrequestreview-2202861133 From duke at openjdk.org Fri Jul 26 23:51:30 2024 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 26 Jul 2024 23:51:30 GMT Subject: RFR: 8337282: Speed =?UTF-8?B?4oCL4oCLdXA=?= StringConcat with more simpleConcat In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote: > StringConcatFactory improves startup speed and running performance through simpleConcat, but simpleConcat is currently given priority and only supports the following scenarios: > > // x instanceof Object > prefix + x > x = subfix > > // x instanceof Object && z instanceof Object > x + y > > > This PR improves startup and running performance by supporting more scenarios including > > // x instanceof byte/short/int/char/boolean/float/double > prefix + x > x + suffix > > // x instanceof byte/short/int/char/boolean/float/double/Integer/Long/Object > prefix + suffix > > // x instanceof Object > x + y + suffix > > // x instanceof Object > x + y + suffix To balance the number of methods, runtime performance, and startup performance, manually writing simpleConcat may still be necessary. The four scenarios where the startup performance degraded seem a bit unbelievable, and I?m still looking for the reasons ------------- PR Comment: https://git.openjdk.org/jdk/pull/20355#issuecomment-2253654995 From vlivanov at openjdk.org Sat Jul 27 00:03:33 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 27 Jul 2024 00:03:33 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v9] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: On Fri, 26 Jul 2024 15:13:06 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix test failure BTW it makes sense to assert the invariant. Here's a patch (accompanied by a minor cleanup): diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp index b050784dfc5..5413e29defb 100644 --- a/src/hotspot/share/oops/instanceKlass.cpp +++ b/src/hotspot/share/oops/instanceKlass.cpp @@ -647,7 +647,7 @@ void InstanceKlass::deallocate_contents(ClassLoaderData* loader_data) { !secondary_supers()->is_shared()) { MetadataFactory::free_array(loader_data, secondary_supers()); } - set_secondary_supers(nullptr); + set_secondary_supers(nullptr, SECONDARY_SUPERS_BITMAP_EMPTY); deallocate_interfaces(loader_data, super(), local_interfaces(), transitive_interfaces()); set_transitive_interfaces(nullptr); diff --git a/src/hotspot/share/oops/klass.cpp b/src/hotspot/share/oops/klass.cpp index 26ec25d1c80..b1012810be4 100644 --- a/src/hotspot/share/oops/klass.cpp +++ b/src/hotspot/share/oops/klass.cpp @@ -319,16 +319,16 @@ bool Klass::can_be_primary_super_slow() const { return true; } -void Klass::set_secondary_supers(Array* secondaries) { - assert(!UseSecondarySupersTable || secondaries == nullptr, ""); - set_secondary_supers(secondaries, SECONDARY_SUPERS_BITMAP_EMPTY); -} - void Klass::set_secondary_supers(Array* secondaries, uintx bitmap) { #ifdef ASSERT if (secondaries != nullptr) { uintx real_bitmap = compute_secondary_supers_bitmap(secondaries); assert(bitmap == real_bitmap, "must be"); + if (bitmap != SECONDARY_SUPERS_BITMAP_FULL) { + assert(((uint)secondaries->length() == population_count(bitmap)), "required"); + } + } else { + assert(bitmap == SECONDARY_SUPERS_BITMAP_EMPTY, ""); } #endif _secondary_supers_bitmap = bitmap; diff --git a/src/hotspot/share/oops/klass.hpp b/src/hotspot/share/oops/klass.hpp index 2f733e11eef..a9e73e7bcbd 100644 --- a/src/hotspot/share/oops/klass.hpp +++ b/src/hotspot/share/oops/klass.hpp @@ -236,7 +236,6 @@ class Klass : public Metadata { void set_secondary_super_cache(Klass* k) { _secondary_super_cache = k; } Array* secondary_supers() const { return _secondary_supers; } - void set_secondary_supers(Array* k); void set_secondary_supers(Array* k, uintx bitmap); uint8_t hash_slot() const { return _hash_slot; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2253660006 From acobbs at openjdk.org Sat Jul 27 02:56:31 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 27 Jul 2024 02:56:31 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 16:46:28 GMT, Archie Cobbs wrote: > With this new proposed change we will throw an IOException (unlike previously). I think that's fine and in fact the correct thing to do. I've run into a problem. With this change, `GZIPInZip.java` fails; the test is annotated like this: /* @test * @bug 7021870 8023431 8026756 * @summary Reading last gzip chain member must not close the input stream. * Garbage following gzip entry must be ignored. */ Note the "Garbage following gzip entry must be ignored" line. This must be what bugs 8023431 8026756 refer to, but those bugs are not accessible ("You can't view this issue. It may have been deleted or you don't have permission to view it.") so I can't see what the problem was that required ignoring the extra garbage. Maybe you guys have access or know what this was about? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2253721455 From dev at anthonyv.be Sat Jul 27 06:57:31 2024 From: dev at anthonyv.be (Anthony Vanelverdinghe) Date: Sat, 27 Jul 2024 08:57:31 +0200 Subject: Stream Gatherers (JEP 473) feedback Message-ID: When writing factory methods for Gatherers, there's sometimes a degenerate case that requires returning a no-op Gatherer. So I'd like a way to mark a no-op Gatherer as such, allowing the Stream implementation to recognize and eliminate it from the pipeline. One idea is to add Gatherer.defaultIntegrator(), analogous to the other default? methods. Another is to add Gatherers.identity(), analogous to Function.identity(). Sometimes a factory method returns a Gatherer that only works correctly if the upstream has certain characteristics, for example Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods like Gatherers.sorted() and Gatherers.distinct(), where the Stream implementation would be able to recognize and eliminate these from the pipeline if the upstream already has these characteristics. That way we'd be able to write `return Gatherers.sorted().andThen(?);`. Another idea is to provide a Gatherer with a way to inspect the upstream characteristics. If the upstream is missing the required characteristic(s), it could then throw an IllegalStateException. The returns clause of Gatherer.Integrator::integrate just states "true if subsequent integration is desired, false if not". In particular, it doesn't document the behavior I'm observing, that returning false also causes downstream to reject any further output elements. In the Implementation Requirements section of Gatherer, rephrasing "Outputs and state later in the input sequence will be discarded if processing an earlier partition short-circuits." to something like the following would be clearer to me: "As soon as any partition short-circuits, the whole Gatherer short-circuits. The state of other partitions is discarded, i.e. there are no further invocations of the combiner. The finisher is invoked with the short-circuiting partition's state." I wouldn't mention discarding of outputs, since that's implied by the act of short-circuiting. Anthony From duke at openjdk.org Sat Jul 27 09:40:54 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 09:40:54 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v42] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: More accurate condition for MBI.safeRightShift() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/608c05c5..a0fa2a85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=41 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=40-41 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Sat Jul 27 10:37:07 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 27 Jul 2024 10:37:07 GMT Subject: RFR: 8337282: Speed =?UTF-8?B?4oCL4oCLdXA=?= StringConcat with more simpleConcat [v2] In-Reply-To: References: Message-ID: > StringConcatFactory improves startup speed and running performance through simpleConcat, but simpleConcat is currently given priority and only supports the following scenarios: > > // x instanceof Object > prefix + x > x = subfix > > // x instanceof Object && z instanceof Object > x + y > > > This PR improves startup and running performance by supporting more scenarios including > > // x instanceof byte/short/int/char/boolean/float/double > prefix + x > x + suffix > > // x instanceof byte/short/int/char/boolean/float/double/Integer/Long/Object > prefix + suffix > > // x instanceof Object > x + y + suffix > > // x instanceof Object > x + y + suffix Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: 1. rename simpleConcat -> makeSimpleConcat 2. add comments 3. support none-constants 3 parameters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20355/files - new: https://git.openjdk.org/jdk/pull/20355/files/37f42b10..9099527c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20355&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20355&range=00-01 Stats: 21 lines in 1 file changed: 5 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/20355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20355/head:pull/20355 PR: https://git.openjdk.org/jdk/pull/20355 From rgiulietti at openjdk.org Sat Jul 27 11:50:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 27 Jul 2024 11:50:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v42] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 09:40:54 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > More accurate condition for MBI.safeRightShift() Some comments on the benchmarks. test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.java line 57: > 55: public void setup() { > 56: Random r = new Random(1123); > 57: int numbits = r.nextInt(16384); This value is not used. In fact, the benchmarks only exercise integers up to about 2^66, which can hardly be defined as "huge". test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.java line 74: > 72: > 73: for (int i = 0; i < TESTSIZE; i++) { > 74: int value = Math.abs(r.nextInt()); There's a risk of an overflow here if the random `int` is `MIN_VALUE`, which would throw an exception later. ------------- PR Review: https://git.openjdk.org/jdk/pull/19710#pullrequestreview-2203164205 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1693945489 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1693945509 From duke at openjdk.org Sat Jul 27 12:20:37 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 12:20:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v42] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 11:47:23 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> More accurate condition for MBI.safeRightShift() > > test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.java line 74: > >> 72: >> 73: for (int i = 0; i < TESTSIZE; i++) { >> 74: int value = Math.abs(r.nextInt()); > > There's a risk of an overflow here if the random `int` is `MIN_VALUE`, which would throw an exception later. The benchmark `BigIntegers.java`, on which I based this, has the same problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1693949478 From duke at openjdk.org Sat Jul 27 12:31:14 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 12:31:14 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v43] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Avoid overflow in benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/a0fa2a85..7aa9e7a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=42 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=41-42 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Sat Jul 27 12:48:50 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 12:48:50 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v44] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Range checks are already done by the BigInteger class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/7aa9e7a2..b7ca7bcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=42-43 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Sat Jul 27 13:01:05 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 27 Jul 2024 13:01:05 GMT Subject: RFR: 8335791: Speed =?UTF-8?B?4oCL4oCLdXA=?= j.u.Formatter & String.format [v5] In-Reply-To: References: Message-ID: > String.format is widely used, and improving its performance is very meaningful. This PR can significantly improve the performance of String.format. Sorry, there are many changes, which will take a lot of time. I hope you can review it patiently. > > > Improved performance includes the following: > > ## 1. Write directly during the parse process to reduce object allocation. > > In the current Formatter implementation, some objects do not need to be allocated, such as: > > > class Formatter { > public Formatter format(Locale l, String format, Object ... args) { > List fsa = parse(format); > // ... > } > > static List parse(String s) { > ArrayList al = new ArrayList<>(); > > while (i < max) { > int n = s.indexOf('%', i); > if (n < 0) { > // > al.add(new FixedString(s, i, max)); > } > } > } > } > > In the process of parsing, the content that is not a Specifier is directly appended without going through FixedString. By directly printing the parsed FormatString object, there is no need to construct a `List fsa` to store it. > > ## 2. Fast path print > Use specialized FormatString implementations for single-character and single-width specifiers to avoid calling the large FormatSpecifier#print method. > > ## 3. String.format directly calls j.u.Formatter > String.format directly calls j.u.Formatter via SharedSecrets to improve performance Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407 # Conflicts: # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java - Implementing JavaUtilFormatterAccess using anonymous class - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407 - use unknownFormatConversion method construct UnknownFormatConversionException - uppercase static final field name & code format - add stable annotation - replace cast to pattern matching - speed up j.u.Formatter & String.format ------------- Changes: https://git.openjdk.org/jdk/pull/20055/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20055&range=04 Stats: 680 lines in 6 files changed: 554 ins; 60 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/20055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20055/head:pull/20055 PR: https://git.openjdk.org/jdk/pull/20055 From duke at openjdk.org Sat Jul 27 13:04:23 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 27 Jul 2024 13:04:23 GMT Subject: RFR: 8335366: Improve String.format performance with fastpath [v14] In-Reply-To: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> References: <7UuohcnXK5YTn1--FaQc0Pf6SA99Dau6PJWE6U9NjEk=.db32c5d6-d59d-40fe-85bc-e64223a2693c@github.com> Message-ID: > We need a String format solution with good performance. String Template was once expected, but it has been removed. j.u.Formatter is powerful, but its performance is not good enough. > > This PR implements a subset of j.u.Formatter capabilities. The performance is good enough that it is a fastpath for commonly used functions. When the supported functions are exceeded, it will fall back to using j.u.Formatter. > > The performance of this implementation is good enough, the fastpath has low detection cost, There is no noticeable performance degradation when falling back to j.u.Formatter via fastpath. > > Below is a comparison of String.format and concat-based and StringBuilder: > > * benchmark java code > > public class StringFormat { > @Benchmark > public String stringIntFormat() { > return "%s %d".formatted(s, i); > } > > @Benchmark > public String stringIntConcat() { > return s + " " + i; > } > > @Benchmark > public String stringIntStringBuilder() { > return new StringBuilder(s).append(" ").append(i).toString(); > } > } > > > * benchmark number on macbook m1 pro > > Benchmark Mode Cnt Score Error Units > StringFormat.stringIntConcat avgt 15 6.541 ? 0.056 ns/op > StringFormat.stringIntFormat avgt 15 17.399 ? 0.133 ns/op > StringFormat.stringIntStringBuilder avgt 15 8.004 ? 0.063 ns/op > > > From the above data, we can see that the implementation of fastpath reduces the performance difference between String.format and StringBuilder from 10 times to 2~3 times. > > The implementation of fastpath supports the following four specifiers, which can appear at most twice and support a width of 1 to 9. > > d > x > X > s > > If necessary, we can add a few more. > > > Below is a comparison of performance numbers running on a MacBook M1, showing a significant performance improvement. > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringFormat.complexFormat avgt 15 895.954 ? 52.541 ns/op > -StringFormat.decimalFormat avgt 15 277.420 ? 18.254 ns/op > -StringFormat.stringFormat avgt 15 66.787 ? 2.715 ns/op > -StringFormat.stringIntFormat avgt 15 81.046 ? 1.879 ns/op > -StringFormat.widthStringFormat avgt 15 38.897 ? 0.114 ns/op > -StringFormat.widthStringIntFormat avgt 15 109.841 ? 1.028 ns/op > > +Benchmark Mode Cnt Score Error Units (current f925339e93fdf7a281462554ce5d73139bd0f0cd) > +StringFormat.complexF... Shaojin Wen 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 19 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407_fastpath - last specifier support %n - optimize width padding - improve StringFormat benchmark - add more test - add StringFormat test - code style - Update src/java.base/share/classes/java/lang/StringFormat.java Co-authored-by: David Schlosnagle - laze init for `decimal fast path locale` - isBigInt -> isLong - ... and 9 more: https://git.openjdk.org/jdk/compare/e840c78a...7313cdbd ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19956/files - new: https://git.openjdk.org/jdk/pull/19956/files/f1ae26a0..7313cdbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19956&range=12-13 Stats: 35144 lines in 1152 files changed: 21627 ins; 8503 del; 5014 mod Patch: https://git.openjdk.org/jdk/pull/19956.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19956/head:pull/19956 PR: https://git.openjdk.org/jdk/pull/19956 From rgiulietti at openjdk.org Sat Jul 27 13:48:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 27 Jul 2024 13:48:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v42] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 12:18:19 GMT, fabioromano1 wrote: >> test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.java line 74: >> >>> 72: >>> 73: for (int i = 0; i < TESTSIZE; i++) { >>> 74: int value = Math.abs(r.nextInt()); >> >> There's a risk of an overflow here if the random `int` is `MIN_VALUE`, which would throw an exception later. > > The benchmark `BigIntegers.java`, on which I based this, has the same problem. It wasn't the overflow by itself that worried me, but that a later invocation of `sqrt*()` could throw. Again, the "huge" numbers are less than 2^66. You might to take a look at `shiftArray` in `BigInteger.java` for inspiration, and adding some leading `0` bits to exercise the normalization/denormalization impact. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1693960748 From duke at openjdk.org Sat Jul 27 14:00:37 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 14:00:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v42] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 13:46:14 GMT, Raffaello Giulietti wrote: >> The benchmark `BigIntegers.java`, on which I based this, has the same problem. > > It wasn't the overflow by itself that worried me, but that a later invocation of `sqrt*()` could throw. > > Again, the "huge" numbers are less than 2^66. You might to take a look at `shiftArray` in `BigInteger.java` for inspiration, and adding some leading `0` bits to exercise the normalization/denormalization impact. Actually, the problem rises already when constructing the BigInteger, by invalid decimal string construction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1693962226 From duke at openjdk.org Sat Jul 27 14:44:15 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 14:44:15 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v45] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: - Correct test method name - Updated sqrt speed test benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/b7ca7bcc..cdda3386 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=44 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=43-44 Stats: 23 lines in 1 file changed: 15 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From rgiulietti at openjdk.org Sat Jul 27 14:57:38 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 27 Jul 2024 14:57:38 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v45] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 14:44:15 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: > > - Correct test method name > - Updated sqrt speed test benchmark On my M1 Pro/32 GiB Current Benchmark Mode Cnt Score Error Units BigIntegerSquareRoot.testBigSqrtAndRemainder avgt 15 45.655 ? 0.273 ns/op BigIntegerSquareRoot.testHugeSqrtAndRemainder avgt 15 1200587.822 ? 7358.024 ns/op BigIntegerSquareRoot.testLargeSqrtAndRemainder avgt 15 27.052 ? 0.143 ns/op BigIntegerSquareRoot.testSmallSqrtAndRemainder avgt 15 33.098 ? 0.207 ns/op New Benchmark Mode Cnt Score Error Units BigIntegerSquareRoot.testBigSqrtAndRemainder avgt 15 21.110 ? 0.151 ns/op BigIntegerSquareRoot.testHugeSqrtAndRemainder avgt 15 21525.493 ? 36.219 ns/op BigIntegerSquareRoot.testLargeSqrtAndRemainder avgt 15 14.897 ? 0.257 ns/op BigIntegerSquareRoot.testSmallSqrtAndRemainder avgt 15 15.539 ? 0.146 ns/op Nice! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2254170586 From acobbs at openjdk.org Sat Jul 27 15:00:51 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 27 Jul 2024 15:00:51 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: > `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. > > There are several issues with this: > > 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. > 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). > 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. > > On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). > > So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java). - Add GZIP input test for various gzip(1) command outputs. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18385/files - new: https://git.openjdk.org/jdk/pull/18385/files/72b60092..f3939c05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=06-07 Stats: 282 lines in 3 files changed: 137 ins; 89 del; 56 mod Patch: https://git.openjdk.org/jdk/pull/18385.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385 PR: https://git.openjdk.org/jdk/pull/18385 From duke at openjdk.org Sat Jul 27 15:04:38 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 15:04:38 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v45] In-Reply-To: References: Message-ID: <00cyd6u6wYE2j3LCDOu-gn0zMbUsAecSoQA5en7Qsjk=.fa0493f4-747a-46a1-bf32-775fd7e45cd3@github.com> On Sat, 27 Jul 2024 14:55:04 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Correct test method name >> - Updated sqrt speed test benchmark > > On my M1 Pro/32 GiB > > Current > > Benchmark Mode Cnt Score Error Units > BigIntegerSquareRoot.testBigSqrtAndRemainder avgt 15 45.655 ? 0.273 ns/op > BigIntegerSquareRoot.testHugeSqrtAndRemainder avgt 15 1200587.822 ? 7358.024 ns/op > BigIntegerSquareRoot.testLargeSqrtAndRemainder avgt 15 27.052 ? 0.143 ns/op > BigIntegerSquareRoot.testSmallSqrtAndRemainder avgt 15 33.098 ? 0.207 ns/op > > > New > > Benchmark Mode Cnt Score Error Units > BigIntegerSquareRoot.testBigSqrtAndRemainder avgt 15 21.110 ? 0.151 ns/op > BigIntegerSquareRoot.testHugeSqrtAndRemainder avgt 15 21525.493 ? 36.219 ns/op > BigIntegerSquareRoot.testLargeSqrtAndRemainder avgt 15 14.897 ? 0.257 ns/op > BigIntegerSquareRoot.testSmallSqrtAndRemainder avgt 15 15.539 ? 0.146 ns/op > > > Nice! @rgiulietti Should the current implementation of the square root algorithm be deleted or should it be preserved? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2254172367 From duke at openjdk.org Sat Jul 27 19:25:30 2024 From: duke at openjdk.org (Andriy Plokhotnyuk) Date: Sat, 27 Jul 2024 19:25:30 GMT Subject: RFR: 8337279: Optimize format instant [v2] In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com> Message-ID: On Fri, 26 Jul 2024 18:03:18 GMT, Roger Riggs wrote: > > Could you please review [these](https://github.com/openjdk/jdk/pull/11986) proposed changes for instantiation of `Instant` values with already normalized nanos? > > @plokhotnyuk Your contribution cannot be acted upon until the OCA is confirmed. If you have not submitted an OCA, please do so. See https://oca.opensource.oracle.com/ @RogerRiggs Thanks for your support! I've submitted a signed OCA more than year ago and nobody answered me yet. Today's attempt shows the following notification: ![image](https://github.com/user-attachments/assets/2161d087-c7ab-4411-9cf6-4eba0bdcec29) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2254233234 From sergei.tsypanov at yandex.ru Sat Jul 27 20:19:55 2024 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Sat, 27 Jul 2024 22:19:55 +0200 Subject: Concurrency issue with virtual threads Message-ID: <50631722106703@mail.yandex.ru> An HTML attachment was scrubbed... URL: From sergei.tsypanov at yandex.ru Sat Jul 27 20:24:01 2024 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Sat, 27 Jul 2024 22:24:01 +0200 Subject: Corrected mail formatting: concurrency issue with virtual threads Message-ID: <6882721722111841@o5ump4w73ck7ppml.iva.yp-c.yandex.net> Hello, I've run into a concurrency issue manifested in application becoming frozen due to pinned virtual threads. Here I've described the reproduction steps in details: https://stackoverflow.com/questions/78790376/spring-boot-application-gets-stuck-when-virtual-threads-are-used-on-java-21 The problem is manifested when you run the Spring Boot application having virtual threads enabled. Under the hood my demo application has a feign client using connection pool with up to 20 connections (threshold cannot be increased due to a configuration bug), and as soon as you try to make more than 20 simultaneous request (even 21), the pool gets exhausted, meaning that upcoming requests have to wait for a connection released, and the application gets stuck (though it doesn't when platform threads are used i.e. when configuration property spring.threads.virtual.enabled is false). Running the code with -Djdk.tracePinnedThreads=full I've identified the cause more precisely: it is located within AbstractConnPool.getPoolEntryBlocking(). Here's the link to the pinned threads stack trace: https://github.com/stsypanov/concurrency-demo/blob/master/pinned-threads.txt In the file pay attention to these lines: 12 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:319) 92 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:391) Now let's examine the source code of o.a.h.p.AbstractConnPool.getPoolEntryBlocking over here: https://github.com/apache/httpcomponents-core/blob/4.4.x/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java In this class we have a ReentrantLock (encouraged to be used with virtual threads instead of synchronized blocks) and its Condition: private final Lock lock; private final Condition condition; public AbstractConnPool() { this.lock = new ReentrantLock(); this.condition = this.lock.newCondition(); } Later in method AbstractConnPool.getPoolEntryBlocking() we have this logic: private E getPoolEntryBlocking() { this.lock.lock(); // line 319 try { for (;;) { try { if (deadline != null) { success = this.condition.awaitUntil(deadline); } else { this.condition.await(); // line 391 success = true; } } } } finally { this.lock.unlock(); } } This code works with platform threads but gets stuck with virtual ones. If one gets thread dump of the stuck application there'll be 20 workers in ForkJoinPool and each will have the same stack trace (with different ids, of course): "ForkJoinPool-1-worker-1" prio=0 tid=0x0 nid=0x0 waiting on condition java.lang.Thread.State: WAITING on java.lang.VirtualThread at 121c8328 owned by "tomcat-handler-123" Id=214 at java.base at 22.0.2/jdk.internal.vm.Continuation.run(Continuation.java:248) at java.base at 22.0.2/java.lang.VirtualThread.runContinuation(VirtualThread.java:245) at java.base at 22.0.2/java.lang.VirtualThread$$Lambda/0x000001579b475d08.run(Unknown Source) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1726) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1717) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(ForkJoinTask.java:1641) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507) at java.base at 22.0.2/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1489) at java.base at 22.0.2/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2071) at java.base at 22.0.2/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2033) at java.base at 22.0.2/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187) As you see from the code above, the issue is still there on Java 22, also it's reproducible with other distributions of JDK (e.g. Liberica JDK). I think this is a bug somewhere in the JVM, as the ending point of the stacktrace is native Continuation.enterSpecial(), otherwise the behavior would be the same regardless of platform or virtual threads. Regards, Sergey Tsypanov From rgiulietti at openjdk.org Sat Jul 27 20:56:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 27 Jul 2024 20:56:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v45] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 14:44:15 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with two additional commits since the last revision: > > - Correct test method name > - Updated sqrt speed test benchmark At the end of the day the existing method should be removed, as it serves no purpose. But I'll comment further on `MBI.java` next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2254251900 From duke at openjdk.org Sat Jul 27 21:06:51 2024 From: duke at openjdk.org (fabioromano1) Date: Sat, 27 Jul 2024 21:06:51 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v46] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Removed MBI.sqrt() old method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/cdda3386..9ca2a814 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=45 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=44-45 Stats: 90 lines in 1 file changed: 0 ins; 90 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Sat Jul 27 22:21:30 2024 From: duke at openjdk.org (duke) Date: Sat, 27 Jul 2024 22:21:30 GMT Subject: RFR: 8337245: Fix wrong comment of StringConcatHelper In-Reply-To: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> References: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> Message-ID: On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote: > 8337245: Fix wrong comment of StringConcatHelper @wenshao Your change (at version d453e6c2837cf7d8802f7fea624324361e085edf) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20344#issuecomment-2254268638 From duke at openjdk.org Sat Jul 27 22:43:36 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 27 Jul 2024 22:43:36 GMT Subject: Withdrawn: 8337282: Speed =?UTF-8?B?4oCL4oCLdXA=?= StringConcat with more simpleConcat In-Reply-To: References: Message-ID: <6jYIfcYtP6IIzLK84ZLMe-f1DrzBOxh79nC56hw7O2M=.df13bf75-c944-467b-be94-4760830c35d7@github.com> On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote: > StringConcatFactory improves startup speed and running performance through simpleConcat, but simpleConcat is currently given priority and only supports the following scenarios: > > // x instanceof Object > prefix + x > x = subfix > > // x instanceof Object && z instanceof Object > x + y > > > This PR improves startup and running performance by supporting more scenarios including > > // x instanceof byte/short/int/char/boolean/float/double > prefix + x > x + suffix > > // x instanceof byte/short/int/char/boolean/float/double/Integer/Long/Object > prefix + suffix > > // x instanceof Object > x + y + suffix > > // x instanceof Object > x + y + suffix This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20355 From redestad at openjdk.org Sat Jul 27 22:57:41 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 27 Jul 2024 22:57:41 GMT Subject: RFR: 8337245: Fix wrong comment of StringConcatHelper In-Reply-To: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> References: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> Message-ID: On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote: > 8337245: Fix wrong comment of StringConcatHelper Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20344#pullrequestreview-2203242433 From duke at openjdk.org Sat Jul 27 22:57:41 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sat, 27 Jul 2024 22:57:41 GMT Subject: Integrated: 8337245: Fix wrong comment of StringConcatHelper In-Reply-To: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> References: <5FzLFBcyFuizdDK2LG6JlvZGAjhAF4t35xhznHjmQ9Y=.1fec4467-2de9-45bb-b3f9-9216e62690f2@github.com> Message-ID: On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote: > 8337245: Fix wrong comment of StringConcatHelper This pull request has now been integrated. Changeset: 2fbdbaca Author: Shaojin Wen Committer: Claes Redestad URL: https://git.openjdk.org/jdk/commit/2fbdbacad7ad45055a482c764f84da4568383020 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8337245: Fix wrong comment of StringConcatHelper Reviewed-by: phh, redestad ------------- PR: https://git.openjdk.org/jdk/pull/20344 From liach at openjdk.org Sun Jul 28 02:39:23 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 28 Jul 2024 02:39:23 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v2] In-Reply-To: References: Message-ID: > As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. > > Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. 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: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/codemodel-maxes - Reuse local var management from buffered code builders - 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20338/files - new: https://git.openjdk.org/jdk/pull/20338/files/a1023837..6b93ad70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20338&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20338&range=00-01 Stats: 2948 lines in 126 files changed: 587 ins; 2154 del; 207 mod Patch: https://git.openjdk.org/jdk/pull/20338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20338/head:pull/20338 PR: https://git.openjdk.org/jdk/pull/20338 From liach at openjdk.org Sun Jul 28 03:07:35 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 28 Jul 2024 03:07:35 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v2] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 13:17:11 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java line 67: >> >>> 65: this.maxLocals = Util.maxLocals(methodInfo.methodFlags(), methodInfo.methodTypeSymbol()); >>> 66: if (original != null) >>> 67: this.maxLocals = Math.max(this.maxLocals, original.maxLocals()); >> >> `original::maxLocals`set the counter for `CodeBuilder::allocateLocal` >> By restricting calculation of maxLocals to "origin instanceof CodeAttribute" may cause invalid locals allocations for chained code builders. The number might not be exposed in the API, however we need to know it internally. > > I think we should just do `Util.maxLocals` without this `origin` check. Your said problem can happen too if a DirectMethodBuilder transforms a BufferedCodeBuilder.Model. > > Note that any code builder can receive a code model half way with `cob.transform(anyModel, CodeTransform.ACCEPT_ALL)`, which the buffered code builder initialization also uses. > I think we should just ask users to use `CodeLocalsShifter` in that case, especially if the transform is inserting new locals. We cannot buffer existing chained builders for performance reasons. Updated this to internal API that accesses the existing local variable management on BufferedCodeBuilder. We can discuss this consistency problem later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20338#discussion_r1694050104 From ysuenaga at openjdk.org Sun Jul 28 06:27:38 2024 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 28 Jul 2024 06:27:38 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote: > We cannot pass GNU style options like `--enable-preview` to `jlink --add-option`. It is hard to use for complex application. > > We have workaround for this issue (see JBS), but I think it is better to fix on JDK side. So how should we proceed this? This problem is critical for some modularized applications as I said before. I agree that we need to consider the approach for this, but it is worth to provide the fix even if it is short-term, I think. I believe we can ensure not to break current behavior with jtreg tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19987#issuecomment-2254360949 From Alan.Bateman at oracle.com Sun Jul 28 06:48:11 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Jul 2024 07:48:11 +0100 Subject: Corrected mail formatting: concurrency issue with virtual threads In-Reply-To: <6882721722111841@o5ump4w73ck7ppml.iva.yp-c.yandex.net> References: <6882721722111841@o5ump4w73ck7ppml.iva.yp-c.yandex.net> Message-ID: <508a9a9a-c8f2-4054-bd2f-616ae223de1b@oracle.com> On 27/07/2024 21:24, ?????? ??????? wrote: > Hello, > > I've run into a concurrency issue manifested in application becoming frozen due to pinned virtual threads. > Can you bring it to loom-dev as this looks like another case where all carriers are pinned, there is a mix of object monitors and j.u.concurrent locks, and a virtual thread that is scheduled to continue will not execute because there are no carriers available. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Jul 28 09:31:55 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 09:31:55 GMT Subject: RFR: 8336856: Optimize String Concat [v17] In-Reply-To: References: Message-ID: <8RQ-d-fPYlQta9RcQDpjI5esKmyiqrKhSQyPOWbXeKE=.776df297-4704-4b3d-b0b8-3c0e7ab3602d@github.com> > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - fix mix Integer null error - fix stringSize build error - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202407 - mix & prepend support Boolean/Integer/Long - more micro benchmark - rename simpleConcat -> makeSimpleConcat - remove benchmark - common simpleConcat - add benchmark - Descending mixer, same order as prepend - ... and 34 more: https://git.openjdk.org/jdk/compare/2fbdbaca...f241462c ------------- Changes: https://git.openjdk.org/jdk/pull/20273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=16 Stats: 716 lines in 5 files changed: 583 ins; 42 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From duke at openjdk.org Sun Jul 28 09:31:56 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 09:31:56 GMT Subject: RFR: 8336856: Optimize String Concat [v16] In-Reply-To: <1ZwToSQZXTiMjFU2iH1yj5y6yUnii2bwtMPo7sARJSo=.752f9553-db8c-463c-8e21-b94804dc8a08@github.com> References: <1ZwToSQZXTiMjFU2iH1yj5y6yUnii2bwtMPo7sARJSo=.752f9553-db8c-463c-8e21-b94804dc8a08@github.com> Message-ID: On Thu, 25 Jul 2024 14:52:11 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - remove benchmark > - common simpleConcat Should mixer and prepend add the two types of Integer and Long? Now we need to do integer.toString and then concatenate, which leads to performance degradation. Now Integer.getChar and Long.getChar are implemented with pepend, and StringConcat is forced to use prepend. If we use the append-based Integer.getChar and Long.getChar algorithms, then String.Concat can be implemented based on append, which should give us better performance. Of course, modifying the algorithm of Integer.getChars is a big change, oh, what a hassle. The following is an algorithm for implementing Integer.getChars based on append: static Unsafe UNSAFE = JDKUtils.UNSAFE; private static final byte[] MIN_INT_BYTES = "-2147483648".getBytes(); public static final int[] DIGITS_K_32 = new int[1000]; static { for (int i = 0; i < 1000; i++) { int c0 = i < 10 ? 2 : i < 100 ? 1 : 0; int c1 = (i / 100) + '0'; int c2 = ((i / 10) % 10) + '0'; int c3 = i % 10 + '0'; DIGITS_K_32[i] = c0 + (c1 << 8) + (c2 << 16) + (c3 << 24); } } @Native public static final int MIN_VALUE = 0x80000000; public static int writeInt32(final byte[] buf, int pos, final int value) { int i; if (value < 0) { if (value == Integer.MIN_VALUE) { System.arraycopy(MIN_INT_BYTES, 0, buf, pos, MIN_INT_BYTES.length); return pos + MIN_INT_BYTES.length; } i = -value; buf[pos++] = '-'; } else { i = value; } if (i < 1000) { int v = DIGITS_K_32[i]; final int start = (byte) v; if (start == 0) { putShort(buf, pos, (short) (v >> 8)); pos += 2; } else if (start == 1) { buf[pos++] = (byte) (v >> 16); } buf[pos] = (byte) (v >> 24); return pos + 1; } final int q1 = i / 1000; final int r1 = i - q1 * 1000; final int v1 = DIGITS_K_32[r1]; if (i < 1000000) { final int v2 = DIGITS_K_32[q1]; int start = (byte) v2; if (start == 0) { putShort(buf, pos, (short) (v2 >> 8)); pos += 2; } else if (start == 1) { buf[pos++] = (byte) (v2 >> 16); } putInt(buf, pos, v1 & 0xffffff00 | (v2 >> 24)); return pos + 4; } final int q2 = q1 / 1000; final int r2 = q1 - q2 * 1000; final int q3 = q2 / 1000; final int v2 = DIGITS_K_32[r2]; if (q3 == 0) { int v = DIGITS_K_32[q2]; final int start = (byte) v; if (start == 0) { putShort(buf, pos, (short) (v >> 8)); pos += 2; } else if (start == 1) { buf[pos++] = (byte) (v >> 16); } buf[pos++] = (byte) (v >> 24); } else { putInt(buf, pos, DIGITS_K_32[q2 - q3 * 1000] & 0xffffff00 | (q3 + '0')); pos += 4; } putShort(buf, pos, (short) (v2 >> 8)); putInt(buf, pos + 2, v1 & 0xffffff00 | (v2 >> 24)); return pos + 6; } private static void putShort(byte[] buf, int pos, short v) { UNSAFE.putShort( buf, ARRAY_BYTE_BASE_OFFSET + pos, BIG_ENDIAN ? Short.reverseBytes(v) : v ); } private static void putInt(byte[] buf, int pos, int v) { UNSAFE.putInt( buf, ARRAY_BYTE_BASE_OFFSET + pos, BIG_ENDIAN ? Integer.reverseBytes(v) : v ); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2254277745 PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2254354750 From redestad at openjdk.org Sun Jul 28 13:03:09 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 28 Jul 2024 13:03:09 GMT Subject: RFR: 8336856: Optimize String Concat [v16] In-Reply-To: References: <1ZwToSQZXTiMjFU2iH1yj5y6yUnii2bwtMPo7sARJSo=.752f9553-db8c-463c-8e21-b94804dc8a08@github.com> Message-ID: <3HuzL-B75jnm1s1nWHGDnuuSyAsiF5gFqFoBnI13yLw=.fef6e9b9-1c75-4434-88b7-2dfe0ab4b5be@github.com> On Sat, 27 Jul 2024 23:08:36 GMT, Shaojin Wen wrote: > Should mixer and prepend add the two types of Integer and Long? Now we need to do integer.toString and then concatenate, which leads to performance degradation. I think the generic problem with specializing on types is that this leads to a exponential explosion in the upper bound of classes which can be generated. Currently `concat_expr + Object`, `concat_expr + Integer`, `concat_expr + Long` all get translated into a single implementation class (which stringifies the argument up front in a generic way). If we specialize we'd get a new set of distinct implementation classes any time there's any combination of `Integer` or `Long`. Of course for the very high arity expressions where we are already specializing for the exact expression then specializing as precisely as we can does not cause an influx in new classes. So it might make sense here, but needs more data. For the very high-arity expressions I think the added cost of the extra `toString`s is likely negligible, though. Let's think about the trade-offs: by default we need something that makes sure low-arity expressions can be reasonably shared, otherwise even smallish apps might see thousands of excess classes generated to support string concatenation. But if we don't share, we can specialize precisely. So it might turn out we can produce something that optimizes better when specializing precisely and creating a class at the call site. What value the threshold should have then becomes an interesting question (which I know you asked elsewhere). Right now it's set pretty high simply because the current high-arity implementation is decidedly worse than the MH-based one. With this PR it gets an equal footing. So perhaps it should be lowered. (But let's defer that decision to a separate PR.) With deeper specialization (optimizing for `Integer`, `Long`, `StringBuilder` etc arguments) the implementations could hypothetically become a bit faster. It might make sense to apply such optimizations to either the high-arity translation, or both. The decision to specialize and the threshold then becomes a classic space-time trade-off tuning decision: OK to generate more classes which has a chance at optimizing significantly better? Lower the threshold/specialize deeper. Save space, get faster startup and shorter warmup, but perhaps lose a few percent raw performance? Raise the threshold/disable specialization. I think these are interesting questions, but I don't think we should rush into this. Let's wean us off the MH-based implementation first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2254463494 From redestad at openjdk.org Sun Jul 28 13:03:09 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 28 Jul 2024 13:03:09 GMT Subject: RFR: 8336856: Optimize String Concat [v15] In-Reply-To: References: <0EQa3rOXnTed-C0CAgTBAcNGn1hEpF9oRngYdp_yWAw=.d03d88dc-c4aa-4a2e-830d-84b51f1fc156@github.com> Message-ID: <8fk49ded8eL_OylLgpVsBmSq5_5el-pGXD8Sav7tvyk=.beb8c0c0-ab47-469e-b238-b2bd33b322f4@github.com> On Thu, 25 Jul 2024 23:36:02 GMT, Shaojin Wen wrote: >> test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47: >> >>> 45: @Measurement(iterations = 5, time = 1000, timeUnit = TimeUnit.MILLISECONDS) >>> 46: @Fork(value = 3, jvmArgsAppend = "-Djava.lang.invoke.StringConcat.highArityThreshold=0") >>> 47: public class StringConcatGenerate extends StringConcat { >> >> Adding a subclass with an overridden `@Fork` to pass a different `jvmArgsAppend` is a reasonable trick, but could be moved to a nested class within `StringConcat` to keep it in the same context. I'm not sure if this micro brings a persistent added value, though: for experimentation we can just run `StringConcat` with different `-Djava.lang.invoke.StringConcat.highArityThreshold` settings, while for continuous regression testing we're more interested in validating the default settings. Supplying the new `main` method doesn't add anything here, either, since a standalone execution wouldn't pick up the `jvmArgsAppend` value. > > I have removed the newly added micro benchmark. But I don't know how to add jvmArgs in make test. > > This will give an error > > make test TEST="micro:java.lang.StringConcat.concat6String" -Djava.lang.invoke.StringConcat.highArityThreshold=0 make test TEST=micro:StringConcatStartup MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=0" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1694226342 From duke at openjdk.org Sun Jul 28 13:03:09 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 13:03:09 GMT Subject: RFR: 8336856: Optimize String Concat [v18] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with five additional commits since the last revision: - code style & add comments - Revert "add none-MH benchmark" This reverts commit 8abba288fb403aeb621016154453c6b3393033fa. - add none-MH benchmark - reduce change - remove mix & prepend Boolean/Integer/Long ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/f241462c..64ce59d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=16-17 Stats: 262 lines in 3 files changed: 4 ins; 163 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From scolebourne at openjdk.org Sun Jul 28 13:39:31 2024 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Sun, 28 Jul 2024 13:39:31 GMT Subject: RFR: 8337279: Optimize format instant [v2] In-Reply-To: <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> <0rRenYTABuRAzJxLQ7llecvge7VUEUab5wU_M78_e5c=.88b3b0c7-f6e2-4dfa-bbf8-3820fdf43e5d@github.com> Message-ID: On Fri, 26 Jul 2024 15:44:59 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: > > add comment src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3812: > 3810: int inNano = NANO_OF_SECOND.checkValidIntValue(inNanos != null ? inNanos : 0); > 3811: // use LocalDateTime.toString, If fractionalDigits < 0, printNano is implemented in LocalDateTime > 3812: LocalDateTime ldt = LocalDateTime.ofEpochSecond(inSecs, fractionalDigits >= 0 ? 0 : inNano, ZoneOffset.UTC); I believe this whole approach is flawed. The comment above says: `// use INSTANT_SECONDS, thus this code is not bound by Instant.MAX` which indicates that the instant value may not fit in `LocalDateTime`. You may be able to special case certain code paths to use `LocalDateTime`, but that makes things more complex, and not necessarily faster. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1694249198 From scolebourne at openjdk.org Sun Jul 28 13:39:32 2024 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Sun, 28 Jul 2024 13:39:32 GMT Subject: RFR: 8337279: Optimize format instant [v2] In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Fri, 26 Jul 2024 15:32:18 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3818: >> >>> 3816: } >>> 3817: // add fraction >>> 3818: if (fractionalDigits > 0) { >> >> This breaks the logic. `fractionalDigits` can be negative in the block below > > If fractionalDigits < 0, printNano is implemented in LocalDateTime `fractionalDigits == -2` is used to output 0, 3, 6 or 9 fractional digits as needed. This can be handled by `LocalDateTime`. `fractionalDigits == -1` is used to output as many fractional digits as needed, from 0 to 9 digits. This is NOT handled by `LocalDateTime`. Furthermore, if the `-2` branch is handled by `LocalDateTime` then the logic below for `-2` is redundant. If the tests did not fail as a result of this change, then I imagine the tests need improving. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1694248869 From duke at openjdk.org Sun Jul 28 13:58:05 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 13:58:05 GMT Subject: RFR: 8336856: Optimize String Concat [v19] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: cache generate MethodHandle ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/64ce59d2..996ffb5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=17-18 Stats: 20 lines in 1 file changed: 17 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From duke at openjdk.org Sun Jul 28 14:02:33 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 14:02:33 GMT Subject: RFR: 8336856: Optimize String Concat [v19] In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > cache generate MethodHandle I will aim to remove the MH-based implementation with minimal changes. I added METHOD_HANDLE_CACHE to prevent the same pattern from being created repeatedly, but I'm not sure if this can make the class unloadable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2254529197 From redestad at openjdk.org Sun Jul 28 14:31:33 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 28 Jul 2024 14:31:33 GMT Subject: RFR: 8336856: Optimize String Concat [v19] In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > cache generate MethodHandle Making the recipe part of the key in such a cache is probably not what we want since it means that we'll produce different classes for `"foo" + bar` and `"baz" + bar` and only return the cached handle on exact recipe match. This will do little to reduce class generation pressure. We would need a slightly different code generation strategy for this to fly: cache only on method handle, cache the constructor to the generated class which takes the array of constants. This is a larger commitment which is why I suggested we do it as a follow-up. To make the class unloadable (which we need here and now for this PR) it might be sufficient to replace `SET_OF_STRONG` with the empty set, `Set.of()`. The hidden class will be strongly reachable from callsites. I'm working on a test to verify this, I might have something ready and send you a PR soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2254539133 From duke at openjdk.org Sun Jul 28 15:52:03 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 15:52:03 GMT Subject: RFR: 8337279: Optimize format instant [v3] In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: > 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: 1. fix handle fraction == -1 2. Split two methods to make codeSize less than 325 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20353/files - new: https://git.openjdk.org/jdk/pull/20353/files/64403d5f..75798425 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=01-02 Stats: 200 lines in 2 files changed: 194 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353 PR: https://git.openjdk.org/jdk/pull/20353 From duke at openjdk.org Sun Jul 28 15:59:05 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 15:59:05 GMT Subject: RFR: 8336856: Optimize String Concat [v20] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Revert "cache generate MethodHandle" This reverts commit 996ffb5ba46aa2861b48cc783d5c824d3721f976. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/996ffb5b..be9952c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=18-19 Stats: 20 lines in 1 file changed: 0 ins; 17 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From duke at openjdk.org Sun Jul 28 17:09:31 2024 From: duke at openjdk.org (Shaojin Wen) Date: Sun, 28 Jul 2024 17:09:31 GMT Subject: RFR: 8337279: Optimize format instant [v3] In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Sun, 28 Jul 2024 15:52:03 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: > > 1. fix handle fraction == -1 > 2. Split two methods to make codeSize less than 325 @jodastephen thank you for your patience in answering my questions. Now I've used a new way to implement it, splitting it into two sub-methods without changing the original logic, which also makes codeSize < 325, and the performance is also faster than before. Here are the performance numbers running on a MacBook M1 Pro: - # master 5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea -Benchmark Mode Cnt Score Error Units -ToStringBench.instantToString thrpt 15 4.558 ? 0.561 ops/ms + # current 757984258257fd82c389f3ee7bd9be927375e2e0 +Benchmark Mode Cnt Score Error Units +ToStringBench.instantToString thrpt 15 5.564 ? 0.465 ops/ms +22.07% I also added relevant tests to prevent errors from being discovered in future related changes. I hope to reuse LocalDateTime.toString for the most common paths, so that we can also use LocalDateTime.formatTo method, which can reduce object allocation. I plan to continue to optimize the formatTo method of LocalTime and LocalDate, so that InstantPrinterParser.format can also benefit from it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2254582635 From duke at openjdk.org Mon Jul 29 00:40:37 2024 From: duke at openjdk.org (ExE Boss) Date: Mon, 29 Jul 2024 00:40:37 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v2] In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 02:39:23 GMT, Chen Liang wrote: >> As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. >> >> Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. > > 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/codemodel-maxes > - Reuse local var management from buffered code builders > - 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java line 41: > 39: } > 40: if (original instanceof CodeAttribute attr) { > 41: return Math.max(paramSlots, attr.codeLength()); Suggestion: return Math.max(paramSlots, attr.maxLocals()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20338#discussion_r1694387536 From liach at openjdk.org Mon Jul 29 00:50:35 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 00:50:35 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v2] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 00:37:21 GMT, ExE Boss 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: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/codemodel-maxes >> - Reuse local var management from buffered code builders >> - 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute > > src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java line 41: > >> 39: } >> 40: if (original instanceof CodeAttribute attr) { >> 41: return Math.max(paramSlots, attr.codeLength()); > > Suggestion: > > return Math.max(paramSlots, attr.maxLocals()); Good point, will add a test too to verify. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20338#discussion_r1694390946 From liach at openjdk.org Mon Jul 29 02:22:11 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 02:22:11 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v3] In-Reply-To: References: Message-ID: > As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. > > Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix typo, and add tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20338/files - new: https://git.openjdk.org/jdk/pull/20338/files/6b93ad70..e1575ab7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20338&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20338&range=01-02 Stats: 115 lines in 2 files changed: 100 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20338/head:pull/20338 PR: https://git.openjdk.org/jdk/pull/20338 From jkratochvil at openjdk.org Mon Jul 29 05:05:40 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 29 Jul 2024 05:05:40 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v15] In-Reply-To: References: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> Message-ID: On Mon, 22 Jul 2024 09:07:31 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: >> >> Unify 4 copies of adjust_controller() > > src/hotspot/os/linux/cgroupUtil_linux.cpp line 64: > >> 62: return cpu->adjust_controller(cpu_total); >> 63: } >> 64: return cpu; > > I guess an alternative - and maybe more readable solution - would be to inline `cpu->adjust_controller()` and `mem->adjust_controller()` code here. We have cg version agnostic api to query the limits. We'd just need accessors for `cgroup_path()` and a setter, `set_cgroup_path()` in `CgroupCpuController/CgroupMemoryController` impls. Currently (before my refactorization) the same code is duplicated 4 times. Do I understand the plan correctly it should be still duplicated but just 2 times? As without the duplication I do not see how to inline it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1694556054 From jpai at openjdk.org Mon Jul 29 07:32:34 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 29 Jul 2024 07:32:34 GMT Subject: RFR: 8328995: Launcher can't open jar files where the offset of the manifest is >4GB [v9] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 15:36:10 GMT, Liam Miller-Cushon wrote: >> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Use /* instead of /** comments Hello Liam, > At that point there were three including pack200, and now we're down to two, but consolidating zip_util.c and parse_manifest.c still seems like a big job. In a different context, I was experimenting with some changes in the launcher code (one part of which involves this parsing of the manifest). While at it, we realized that some of the changes I am looking into will allow us to move away from having to parse the manifest of the jar in this code path. What that then means is that we won't have to do any of this jar parsing within the C code of the launcher and can rely on existing java code to do the necessary jar parsing. That should then allow us to support zip64 jars without this added complexity and maintenance in the C code. I have some prototype change which I'm experimenting with. Please give me some more days so that I can bring it to a state where it can be reviewed. As such, I request you to put on hold, for a few more days, the changes that are being proposed in this current PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2255174629 From jpai at openjdk.org Mon Jul 29 07:38:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 29 Jul 2024 07:38:31 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided In-Reply-To: References: Message-ID: <3w_CS0W06ES5CDlG3bzTKWQ7Xie-dQyXZcK78JmG0Vw=.a7a174f3-3d26-43e9-84ae-7bc8a9b36538@github.com> On Sun, 28 Jul 2024 06:24:38 GMT, Yasumasa Suenaga wrote: >> We cannot pass GNU style options like `--enable-preview` to `jlink --add-option`. It is hard to use for complex application. >> >> We have workaround for this issue (see JBS), but I think it is better to fix on JDK side. > > So how should we proceed this? This problem is critical for some modularized applications as I said before. > > I agree that we need to consider the approach for this, but it is worth to provide the fix even if it is short-term, I think. I believe we can ensure not to break current behavior with jtreg tests. Hello @YaSuenag, like Alan noted, I believe the options parsing for jlink will need a bigger change. The current proposed change has the potential to have unexpected side effects where an option that wasn't expected to be passed to a plugin for parsing, might now end up being passed to the plugin. The fact that the current tests aren't catching that issue is also a sign that we might need additional test coverage in this area. > This problem is critical for some modularized applications as I said before. Do you have an example `jlink` command line where you are running into problems with the `--add-options`? As far as I know, there are workarounds to get `--add-options` to behave correctly and be able to pass along the expected values in the generated image. Depending on your example, we might be able to suggest a workaround until the options parsing is reworked. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19987#issuecomment-2255205235 From asotona at openjdk.org Mon Jul 29 07:39:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 29 Jul 2024 07:39:32 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v3] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 02:22:11 GMT, Chen Liang wrote: >> As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. >> >> Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo, and add tests Looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20338#pullrequestreview-2204161711 From aturbanov at openjdk.org Mon Jul 29 10:05:32 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 29 Jul 2024 10:05:32 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v3] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 02:22:11 GMT, Chen Liang wrote: >> As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. >> >> Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo, and add tests test/jdk/jdk/classfile/BuilderBlockTest.java line 353: > 351: // not managed for now > 352: @Test > 353: void testAllocateLocalTransformingCodeAttribute() throws IOException { Suggestion: void testAllocateLocalTransformingCodeAttribute() throws IOException { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20338#discussion_r1694951218 From liach at openjdk.org Mon Jul 29 12:32:10 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 12:32:10 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v4] In-Reply-To: References: Message-ID: > As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. > > Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Spacing style issue Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20338/files - new: https://git.openjdk.org/jdk/pull/20338/files/e1575ab7..8cf6b47f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20338&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20338&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20338/head:pull/20338 PR: https://git.openjdk.org/jdk/pull/20338 From asotona at openjdk.org Mon Jul 29 12:42:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 29 Jul 2024 12:42:33 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v4] In-Reply-To: References: Message-ID: <7KsSfBrM7HOaD6u3S2DwbnDH9g1DbfFdp5IWTuDfEIM=.594e8238-6251-4c3b-a386-77cef89d6a5a@github.com> On Mon, 29 Jul 2024 12:32:10 GMT, Chen Liang wrote: >> As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. >> >> Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Spacing style issue > > Co-authored-by: Andrey Turbanov Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20338#pullrequestreview-2204820542 From ysuenaga at openjdk.org Mon Jul 29 12:57:32 2024 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 29 Jul 2024 12:57:32 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided In-Reply-To: <3w_CS0W06ES5CDlG3bzTKWQ7Xie-dQyXZcK78JmG0Vw=.a7a174f3-3d26-43e9-84ae-7bc8a9b36538@github.com> References: <3w_CS0W06ES5CDlG3bzTKWQ7Xie-dQyXZcK78JmG0Vw=.a7a174f3-3d26-43e9-84ae-7bc8a9b36538@github.com> Message-ID: On Mon, 29 Jul 2024 07:36:15 GMT, Jaikiran Pai wrote: >> So how should we proceed this? This problem is critical for some modularized applications as I said before. >> >> I agree that we need to consider the approach for this, but it is worth to provide the fix even if it is short-term, I think. I believe we can ensure not to break current behavior with jtreg tests. > > Hello @YaSuenag, like Alan noted, I believe the options parsing for jlink will need a bigger change. The current proposed change has the potential to have unexpected side effects where an option that wasn't expected to be passed to a plugin for parsing, might now end up being passed to the plugin. The fact that the current tests aren't catching that issue is also a sign that we might need additional test coverage in this area. > >> This problem is critical for some modularized applications as I said before. > > Do you have an example `jlink` command line where you are running into problems with the `--add-options`? As far as I know, there are workarounds to get `--add-options` to behave correctly and be able to pass along the expected values in the generated image. Depending on your example, we might be able to suggest a workaround until the options parsing is reworked. @jaikiran This is the case what I want to do. https://github.com/YaSuenag/perfreader/blob/4844ac54b375d73b4ee981a90cd3b3b3e0245ab6/pom.xml#L71-L76 --add-options -XX:+HeapDumpOnOutOfMemoryError --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=perfreader --add-exports=jdk.internal.jvmstat/sun.jvmstat.perfdata.monitor=perfreader We cannot pass `--add-exports` straightly as you know, but we can avoid the issue to add the option which starts with `-` to the top of args (it is similar with the workaround which is shown in JDK-8303884). So I've added `-XX:+HeapDumpOnOutOfMemoryError`, but it is ugly a bit I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19987#issuecomment-2255858298 From lancea at openjdk.org Mon Jul 29 13:08:34 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 29 Jul 2024 13:08:34 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java). > - Add GZIP input test for various gzip(1) command outputs. > > With this new proposed change we will throw an IOException (unlike previously). I think that's fine and in fact the correct thing to do. > > I've run into a problem. > > With this change, `GZIPInZip.java` fails; the test is annotated like this: > > ```java > /* @test > * @bug 7021870 8023431 8026756 > * @summary Reading last gzip chain member must not close the input stream. > * Garbage following gzip entry must be ignored. > */ > ``` > > Note the "Garbage following gzip entry must be ignored" line. This must be what bugs 8023431 8026756 refer to, but those bugs are not accessible ("You can't view this issue. It may have been deleted or you don't have permission to view it.") so I can't see what the problem was that required ignoring the extra garbage. Maybe you guys have access or know what this was about? Thanks. See also [this stackoverflow question](https://stackoverflow.com/questions/4928560/how-can-i-work-with-gzip-files-which-contain-extra-data) - it seems to be a thing with ZIP files. I don't know the full history, but [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425) added support for concatenated gzip files and also the code for ignoring extra trailing garbage bytes. As part of the fix for [JDK-8026756](https://bugs.openjdk.org/browse/JDK-8026756) a test was added for validating that trailing garbage bytes after the end header are ignored, but was not mentioned in the bug. In [gzip manual](https://www.gnu.org/software/gzip/manual/gzip.html): > 6 Using gzip on tapes > > When writing compressed data to a tape, it is generally necessary to pad the output with zeroes up to a block > boundary. When the data is read and the whole block is passed to gunzip for decompression, gunzip detects > that there is extra trailing garbage after the compressed data and emits a warning by default if the garbage > contains nonzero bytes. You can use the --quiet option to suppress the warning. Based on the above and the test that was added via [JDK-8026756](https://bugs.openjdk.org/browse/JDK-8026756), the existing behavior for the handling of extra garbage bytes should be left as is. So where does that leave us: - Keep the code as is and document the current behavior - Continue to add additional test coverage for the current API - We probably do not need a new constructor given it probably adds no new additional value the existing API ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2255888787 From duke at openjdk.org Mon Jul 29 13:18:16 2024 From: duke at openjdk.org (fabioromano1) Date: Mon, 29 Jul 2024 13:18:16 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: If the input is a square, then s0 == 0, so testing for non-zero remainder is redundant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/9ca2a814..53b7adca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=46 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=45-46 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From acobbs at openjdk.org Mon Jul 29 13:55:37 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 29 Jul 2024 13:55:37 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 13:06:24 GMT, Lance Andersen wrote: > So where does that leave us: > > Keep the code as is and document the current behavior > Continue to add additional test coverage for the current API > We probably do not need a new constructor given it probably adds no new additional value the existing API Just so I understand... are you saying that you are OK with this class being fundamentally unreliable _and_ providing no way to avoid that unreliability? (Just to restate a previous example of this: if an underlying `IOException` occurs at just the wrong time, an application that wrote `GZIP-STREAM-1`, `GZIP-STREAM-2`, `GZIP-STREAM-3` could read back `GZIP-STREAM-1`, `GZIP-STREAM-2` and never know that anything was wrong.) If that's _not_ what you're saying, then I don't the understand "We probably do not need a new constructor" part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2256010579 From jkratochvil at openjdk.org Mon Jul 29 14:14:50 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 29 Jul 2024 14:14:50 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v17] In-Reply-To: References: Message-ID: > The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 260 commits: - Implement vm.cgroup.tools - Use Metrics.systemMetrics().getProvider() - Fix testcase compatibility with Alpine Linux 3.20.1 - 8335922: Incorrect @Stable usage of LambdaForm$Name.index Reviewed-by: jvernee, shade - 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved Reviewed-by: jvernee - 8336935: Test sun/security/krb5/auto/RealmSpecificValues.java fails: java.lang.RuntimeException: Should not reach here Reviewed-by: hchao, dholmes - 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep Reviewed-by: lmesnik, amenkov - 8334145: missing from vm_memory_map_.txt in System.dump_map help text Reviewed-by: dholmes, stuefe - 8333728: ubsan: shenandoahFreeSet.cpp:1347:24: runtime error: division by zero Reviewed-by: shade, rkennke - 8333088: ubsan: shenandoahAdaptiveHeuristics.cpp:245:44: runtime error: division by zero Reviewed-by: shade, rkennke - ... and 250 more: https://git.openjdk.org/jdk/compare/537d20af...ba7f5282 ------------- Changes: https://git.openjdk.org/jdk/pull/17198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=16 Stats: 10751 lines in 451 files changed: 7122 ins; 1968 del; 1661 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From jkratochvil at openjdk.org Mon Jul 29 14:17:42 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 29 Jul 2024 14:17:42 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v15] In-Reply-To: References: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> Message-ID: <94HhbIibbZJp4nZe9rhQnobYklTXiVoPQ8cVn3_84hQ=.9cc0b2a1-c95f-4777-a389-3d3e0a41c6c9@github.com> On Mon, 22 Jul 2024 13:48:29 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 193: > >> 191: } >> 192: } >> 193: private static class TestNoController extends Test { > > This logic doesn't seem to detect `cgv1` and `cgv2` correctly. When I run this on a cgv1 system (hybrid) then I get a failure that looks like this: > > > ----------System.err:(33/2506)---------- > -------------------------------------------------------------------------------- command: cgdelete -r -g memory:jdktest150899 > -------------------------------------------------------------------------------- stdout > -------------------------------------------------------------------------------- stderr > cgdelete: cannot remove group 'jdktest150899': No such file or directory > -------------------------------------------------------------------------------- > -------------------------------------------------------------------------------- command: cgcreate -g memory:jdktest150899/inner > -------------------------------------------------------------------------------- stdout > -------------------------------------------------------------------------------- stderr > -------------------------------------------------------------------------------- > isCgroup2 = true > -------------------------------------------------------------------------------- cgroup2 mount point: /sys/fs/cgroup/unified > java.nio.file.NoSuchFileException: /sys/fs/cgroup/unified/jdktest150899/memory.max > at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:262) > at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:482) > at java.base/java.nio.file.Files.newOutputStream(Files.java:228) > at java.base/java.nio.file.Files.write(Files.java:3516) > at java.base/java.nio.file.Files.writeString(Files.java:3738) > at java.base/java.nio.file.Files.writeString(Files.java:3678) > at NestedCgroup$Test.(NestedCgroup.java:161) > at NestedCgroup$TestTwoLimits.(NestedCgroup.java:190) > at NestedCgroup.main(NestedCgroup.java:221) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.r... I have used `Metrics.systemMetrics()`. But it still needs to parse `Metrics.systemMetrics()` to find out the mount point (`sysFsCgroup`) to write into the `memory.max` file. I have tried to combine both. Please tell me if it works or not on your system. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1695317939 From sgehwolf at openjdk.org Mon Jul 29 14:18:24 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 29 Jul 2024 14:18:24 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v2] In-Reply-To: References: Message-ID: > 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 proposed 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20280/files - new: https://git.openjdk.org/jdk/pull/20280/files/179791a1..179791a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280 From lancea at openjdk.org Mon Jul 29 14:30:34 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 29 Jul 2024 14:30:34 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: <4HHjduhWA5-s6nsWHiD_f3At_Y1lYrySqaXwu4ACjzA=.15250263-e9db-42cf-9e2d-0bef27ede81d@github.com> On Mon, 29 Jul 2024 13:52:57 GMT, Archie Cobbs wrote: > > So where does that leave us: > > Keep the code as is and document the current behavior > > Continue to add additional test coverage for the current API > > We probably do not need a new constructor given it probably adds no new additional value the existing API > > Just so I understand... are you saying that you are OK with this class being fundamentally unreliable _and_ providing no way to avoid that unreliability? (Just to restate a previous example of this: if an underlying `IOException` occurs at just the wrong time, an application that wrote `GZIP-STREAM-1`, `GZIP-STREAM-2`, `GZIP-STREAM-3` could read back `GZIP-STREAM-1`, `GZIP-STREAM-2` and never know that anything was wrong.) > > If that's _not_ what you're saying, then I don't the understand "We probably do not need a new constructor" part. What I am suggesting is before we move forward, we really need: - More test coverage - An understanding of what other gzip API and tools(commons-compress, gzip, python, etc...) might do (or do not do) with the problem you are trying to address The Java ZIP APIs date back to the early days of Java (1.1/1.2) and changes(fixes) often can cause unexpected regressions so we have to thread lightly. I am not opposed to making the API more robust, we really need more datapoint to better understand the risks/benefits in order to make an informed decision. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2256096016 From naoto at openjdk.org Mon Jul 29 15:54:59 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 29 Jul 2024 15:54:59 GMT Subject: RFR: 8337300: java/lang/Process/WaitForDuration.java leaves child process behind Message-ID: This fix is to address the tier_1 test run on Windows taking much longer time than before. The test case creates child processes that remain behind after the test run has completed, which is problematic on Windows as the make command waits for the process to terminate. Confirmed tier_1/part_1 finishes around 10+min on Windows as before. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/20379/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20379&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337300 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20379.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20379/head:pull/20379 PR: https://git.openjdk.org/jdk/pull/20379 From alanb at openjdk.org Mon Jul 29 16:08:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 29 Jul 2024 16:08:31 GMT Subject: RFR: 8337300: java/lang/Process/WaitForDuration.java leaves child process behind In-Reply-To: References: Message-ID: <7p_6vt4xGW-kONynqJoyr4YB6gE4G9qUvHHBpYSvpCk=.488fa094-ad3d-4ad1-8fec-283e38996c5d@github.com> On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote: > This fix is to address the tier_1 test run on Windows taking much longer time than before. The test case creates child processes that remain behind after the test run has completed, which is problematic on Windows as the make command waits for the process to terminate. Confirmed tier_1/part_1 finishes around 10+min on Windows as before. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20379#pullrequestreview-2205396025 From iris at openjdk.org Mon Jul 29 16:12:32 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 29 Jul 2024 16:12:32 GMT Subject: RFR: 8337300: java/lang/Process/WaitForDuration.java leaves child process behind In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote: > This fix is to address the tier_1 test run on Windows taking much longer time than before. The test case creates child processes that remain behind after the test run has completed, which is problematic on Windows as the make command waits for the process to terminate. Confirmed tier_1/part_1 finishes around 10+min on Windows as before. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20379#pullrequestreview-2205405569 From bpb at openjdk.org Mon Jul 29 16:17:41 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 29 Jul 2024 16:17:41 GMT Subject: RFR: 8337300: java/lang/Process/WaitForDuration.java leaves child process behind In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote: > This fix is to address the tier_1 test run on Windows taking much longer time than before. The test case creates child processes that remain behind after the test run has completed, which is problematic on Windows as the make command waits for the process to terminate. Confirmed tier_1/part_1 finishes around 10+min on Windows as before. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20379#pullrequestreview-2205415797 From naoto at openjdk.org Mon Jul 29 16:46:35 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 29 Jul 2024 16:46:35 GMT Subject: Integrated: 8337300: java/lang/Process/WaitForDuration.java leaves child process behind In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote: > This fix is to address the tier_1 test run on Windows taking much longer time than before. The test case creates child processes that remain behind after the test run has completed, which is problematic on Windows as the make command waits for the process to terminate. Confirmed tier_1/part_1 finishes around 10+min on Windows as before. This pull request has now been integrated. Changeset: c23d37e1 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/c23d37e10a429c0e7248593b07ef1ccdcd34bd1c Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod 8337300: java/lang/Process/WaitForDuration.java leaves child process behind Reviewed-by: alanb, iris, bpb ------------- PR: https://git.openjdk.org/jdk/pull/20379 From naoto at openjdk.org Mon Jul 29 16:46:34 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 29 Jul 2024 16:46:34 GMT Subject: RFR: 8337300: java/lang/Process/WaitForDuration.java leaves child process behind In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote: > This fix is to address the tier_1 test run on Windows taking much longer time than before. The test case creates child processes that remain behind after the test run has completed, which is problematic on Windows as the make command waits for the process to terminate. Confirmed tier_1/part_1 finishes around 10+min on Windows as before. Thanks for the reviews. I'll integrate it now as it affects all Windows test tasks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20379#issuecomment-2256409591 From rgiulietti at openjdk.org Mon Jul 29 17:02:44 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 29 Jul 2024 17:02:44 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 13:18:16 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > If the input is a square, then s0 == 0, so testing for non-zero remainder is redundant Just some quick reviews. Expect a more definitive review in the next days. src/java.base/share/classes/java/math/MutableBigInteger.java line 550: > 548: */ > 549: void safeRightShift(int n) { > 550: if (n >= bitLength()) { The commit message for this reads `More accurate condition for MBI.safeRightShift()`. If the old version works, please switch back. But if this is a genuine bug, then it needs a separate bug issue and PR. src/java.base/share/classes/java/math/MutableBigInteger.java line 1891: > 1889: int shift = Integer.numberOfLeadingZeros(x.value[x.offset]) & ~1; // shift must be even > 1890: if ((x.intLen & 1) != 0) > 1891: shift += 32; // x.intLen must be even Suggestion: int shift = (Integer.numberOfLeadingZeros(x.value[x.offset]) & ~1) + ((x.intLen & 1) << 32); src/java.base/share/classes/java/math/MutableBigInteger.java line 1922: > 1920: } > 1921: > 1922: private static long ulongSqrt(long x) { Since there is a `unisgnedLongCompare` already, it would be better to name this `unsignedLongSqrt`. src/java.base/share/classes/java/math/MutableBigInteger.java line 1946: > 1944: * @implNote The implementation is based on Zimmermann's works available > 1945: * here and > 1946: * here The following variant should be preferred, as it has a readable figure on p. 21, whereas the same figure in the variant linked in the PR seems broken for some reason. https://inria.hal.science/inria-00072113/document src/java.base/share/classes/java/math/MutableBigInteger.java line 1948: > 1946: * here > 1947: */ > 1948: private MutableBigInteger[] sqrtRemZimmermann(int len, boolean needRemainder) { This should be called `sqrtRemKaratsuba()`. This is the name chosen by Paul Zimmermann himself. Also, I wonder if it wouldn't be simpler for `len` to represent the `int` length of the square root rather than the `int` length of the argument. It would be more consistent with the Bertot, Magaud, Zimmermann paper and might slightly simplify some later computation. But I'm not sure. src/java.base/share/classes/java/math/MutableBigInteger.java line 1968: > 1966: final int halfLen = len >> 1; > 1967: // Recursive invocation > 1968: MutableBigInteger[] sr = sqrtRemZimmermann((halfLen & 1) == 0 ? halfLen : halfLen + 1, true); Suggestion: final int halfLen = len >> 1; // Recursive invocation MutableBigInteger[] sr = sqrtRemZimmermann(halfLen + (halfLen & 1), true); src/java.base/share/classes/java/math/MutableBigInteger.java line 2018: > 2016: * {@code this} number, ending at {@code blockIndex*blockLen} (exclusive). > 2017: */ > 2018: private MutableBigInteger getBlockZimmermann(int blockIndex, int len, int blockLen) { Should be named `getBlockKaratsuba()` or similar. test/jdk/java/math/BigInteger/BigIntegerTest.java line 299: > 297: /* For every long value n in [0, 2^32) such that x == n * n, > 298: * n - 1 <= (long) Math.sqrt(x >= 0 ? x : x + 0x1p64) <= n > 299: * must be true. Suggestion: * must be true. * This property is used to implement MutableBigInteger.unsignedLongSqrt(). test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.java line 85: > 83: largeArray[i] = new BigInteger("" + (value / 1000)); > 84: smallArray[i] = new BigInteger("" + hi); > 85: } I think it would be more representative to have 5 arrays, from extra-small (XS) to extra-large (XL), with elements created by `new BigInteger(r.nextInt(maxLen), r)`, where `maxLen` is 64, 256, 1_024, 4_096, 16_384, resp., and drop the logic with the string parsing. ------------- PR Review: https://git.openjdk.org/jdk/pull/19710#pullrequestreview-2205484016 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695548820 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695549452 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695549943 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695550713 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695551231 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695558116 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695558368 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695558651 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695559743 From rgiulietti at openjdk.org Mon Jul 29 17:02:44 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 29 Jul 2024 17:02:44 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: <6Cl-wKqogKapN7nqnrv8nyOYizAr8mXrmnNle3yWjRo=.981bb071-cb9e-43ef-9f0d-e59fa75838a0@github.com> On Mon, 29 Jul 2024 16:49:04 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> If the input is a square, then s0 == 0, so testing for non-zero remainder is redundant > > src/java.base/share/classes/java/math/MutableBigInteger.java line 1891: > >> 1889: int shift = Integer.numberOfLeadingZeros(x.value[x.offset]) & ~1; // shift must be even >> 1890: if ((x.intLen & 1) != 0) >> 1891: shift += 32; // x.intLen must be even > > Suggestion: > > int shift = (Integer.numberOfLeadingZeros(x.value[x.offset]) & ~1) + ((x.intLen & 1) << 32); Sorry, not `<<` but `*` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695564832 From acobbs at openjdk.org Mon Jul 29 17:09:36 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 29 Jul 2024 17:09:36 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: <4HHjduhWA5-s6nsWHiD_f3At_Y1lYrySqaXwu4ACjzA=.15250263-e9db-42cf-9e2d-0bef27ede81d@github.com> References: <4HHjduhWA5-s6nsWHiD_f3At_Y1lYrySqaXwu4ACjzA=.15250263-e9db-42cf-9e2d-0bef27ede81d@github.com> Message-ID: On Mon, 29 Jul 2024 14:27:28 GMT, Lance Andersen wrote: > ... we really need more datapoint to better understand the risks/benefits in order to make an informed decision. Agreed. Here's some what I've come up with after a little bit of research: First, we shouldn't confuse GZIP with ZIP files. They are only indirectly related: * The [DEFLATE format](https://en.wikipedia.org/wiki/Deflate) is a single file compression format * The [GZIP format](https://en.wikipedia.org/wiki/Gzip) is a wrapper around the DEFLATE format. * Individual entries in a [ZIP archive](https://en.wikipedia.org/wiki/ZIP_(file_format)) is typically DEFLATE'd, but never GZIP'd The "overlap" that is relevant here is simply when the file you are storing in a ZIP file happens to itself be a GZIP file e.g. `foo.gz` (so yes, you are likely compressing `foo` twice). Specifically, the failing test `GZIPInZip.java` is doing this: 1. Create a normal GZIP data file `b.gz` 1. Create a normal ZIP file 1. Write `b.gz` _plus one extra byte_ into the ZIP file 1. Close the ZIP file 1. Open the ZIP file 1. Find the `InputStream` corresponding to the entry for `b.gz` 1. Read and decompress it with a `GZIPInputStream` 1. Verify the extra byte was ignored So this has nothing to do with the ZIP file format itself, rather it's related to the behavior of how other software might build ZIP files. Nor does it directly relate to the GZIP format or how any GZIP decoder (taken in isolation) should behave. So what I don't understand is what is the motivation for the behavior this test is verifying? It looks like, at best, a bug workaround for some unknown other broken software. Here's the commit it was added: commit 71f33254816a17ff741e0119e16db28181d7b43b Author: Ivan Gerasimov Date: Tue Oct 15 21:15:17 2013 +0400 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed Properly close PipedStreams. Additional testing for malformed input Reviewed-by: darcy, sherman Did you double check the unviewable issues? What does JDK-8023431 say? I also took a look at how Apache's commons-compress `GzipCompressorInputStream` behaves. `GzipCompressorInputStream` is the commons-compress version of `GZIPInputStream`. From what I can infer, part of its original motivation was that pre-JDK7 `GZIPInputStream` didn't support concatenated streams. This class provides an optional `decompressConcatenated` boolean constructor parameter (default `false`). So how does `GzipCompressorInputStream` behave...? * `IOException`'s thrown by the underlying input stream are never suppressed; this includes `IOException`'s thrown while reading "extra garbage" that may follow the first (if `decompressConcatenated = false`) or any (if `decompressConcatenated = true`) GZIP trailer frame. * When `decompressConcatenated = false`, after reading the first GZIP trailer frame, the underlying input is `reset()` if possible to the stream's boundary. If `reset()` is not supported, some indeterminate number of extra bytes will have been read (note, this exception is missing from the Javadoc). * When `decompressConcatenated = true`, the entire input stream is read, and it must contain only whole, valid GZIP streams with no trailing garbage. Summary: GzipCompressorInputStream is never "lenient"; it either reads the whole stream (if `decompressConcatenated = true`) or else just the first GZIP stream and stops as soon as it can thereafter (exactly if `markSupported()`, othewise inexactly). Side note: the reliance on `mark()`/`reset()` is a nice trick so to speak: if you can provide an input stream that supports it, you get precision in return, and this is accomplished without requiring any new API surface. This brings up the question, how would commons-compress behave in the scenario being tested by the `GZIPInZip.java` test? Answer: Let's assume you replace `new GZIPInputStream(zis)` with `new GzipCompressorInputStream(zis)` in that test. Then the test would succeed, because: * By default, `GzipCompressorInputStream` sets `decompressConcatenated = false`. * The extra byte might get read, but because `decompressConcatenated = false` decompression stops after the last byte of `b.gz` Overall the API and behavior design of `GzipCompressorInputStream` seems like a good one. I would even recommend that we adopt it, except that it's incompatible with the current behavior (we assume `decompressConcatenated = true` by default). So here's a stab at what we might do (opening debate): Basically, we replicate the `GzipCompressorInputStream` behavior with the exception that our `allowConcatenated` defaults to `true` to preserve existing behavior. In summary: * We utilize `mark()`/`reset()` to guarantee precise stopping behavior when `allowConcatenated = false` - but only if `markSupported()` returns true; otherwise, best effort/imprecise stop that may read past the GZIP end. * We eliminate all "lenient" behavior - e.g., underlying `IOException`'s are never suppressed, and if concatenation is enabled, non-empty GZIP header frames must always be valid and the entire stream is consumed. * Update `GZIPInZip.java` to replace `new GZIPInputStream(zis)` with `new GZIPInputStream(zis, false)` to unbreak it ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2256461082 From duke at openjdk.org Mon Jul 29 18:01:40 2024 From: duke at openjdk.org (fabioromano1) Date: Mon, 29 Jul 2024 18:01:40 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: <6Cl-wKqogKapN7nqnrv8nyOYizAr8mXrmnNle3yWjRo=.981bb071-cb9e-43ef-9f0d-e59fa75838a0@github.com> References: <6Cl-wKqogKapN7nqnrv8nyOYizAr8mXrmnNle3yWjRo=.981bb071-cb9e-43ef-9f0d-e59fa75838a0@github.com> Message-ID: On Mon, 29 Jul 2024 17:00:09 GMT, Raffaello Giulietti wrote: > Sorry, not `<<` but `*` or `(x.intLen & 1) << 5` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695649080 From duke at openjdk.org Mon Jul 29 18:07:43 2024 From: duke at openjdk.org (fabioromano1) Date: Mon, 29 Jul 2024 18:07:43 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: <-qgPy6DG7wQIs-cDgg3S5ezNuiZ_kQ3e8oEe-ogvPUw=.f5d28595-2adb-42ae-8874-510c22a81143@github.com> On Mon, 29 Jul 2024 16:50:10 GMT, Raffaello Giulietti wrote: > The following variant should be preferred, as it has a readable figure on p. 21, whereas the same figure in the variant linked in the PR seems broken for some reason. https://inria.hal.science/inria-00072113/document What is the figure? I can view the same things in both versions... maybe it's a problem of the pdf reader or of the file? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695655924 From viktor.klang at oracle.com Mon Jul 29 18:08:45 2024 From: viktor.klang at oracle.com (Viktor Klang) Date: Mon, 29 Jul 2024 18:08:45 +0000 Subject: Stream Gatherers (JEP 473) feedback In-Reply-To: References: Message-ID: Hi Anthony, Thank you for your patience, and for providing feedback, it is always much appreciated. >When writing factory methods for Gatherers, there's sometimes a degenerate case that requires returning a no-op Gatherer. So I'd like a way to mark a no-op Gatherer as such, allowing the Stream implementation to recognize and eliminate it from the pipeline. One idea is to add Gatherer.defaultIntegrator(), analogous to the other default? methods. Another is to add Gatherers.identity(), analogous to Function.identity(). I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it, but rather adding it in case it was deemed necessary. Do you have a concrete use-case (code) that you could share? >Sometimes a factory method returns a Gatherer that only works correctly if the upstream has certain characteristics, for example Spliterator.SORTED or Spliterator.DISTINCT. Do you have a concrete use-case (code) that you could share? >One idea is to add methods like Gatherers.sorted() and Gatherers.distinct(), where the Stream implementation would be able to recognize and eliminate these from the pipeline if the upstream already has these characteristics. That way we'd be able to write `return Gatherers.sorted().andThen(?);`. Another idea is to provide a Gatherer with a way to inspect the upstream characteristics. If the upstream is missing the required characteristic(s), it could then throw an IllegalStateException. For a rather long time Gatherer had characteristics, however, what I noticed is that given composition of Gatherers what ended up happening almost always was that the combination of characteristics added overhead and devolved into the empty set real fast. Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming. >The returns clause of Gatherer.Integrator::integrate just states "true if subsequent integration is desired, false if not". In particular, it doesn't document the behavior I'm observing, that returning false also causes downstream to reject any further output elements. Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea) Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Anthony Vanelverdinghe Sent: Saturday, 27 July 2024 08:57 To: core-libs-dev at openjdk.org Subject: Stream Gatherers (JEP 473) feedback When writing factory methods for Gatherers, there's sometimes a degenerate case that requires returning a no-op Gatherer. So I'd like a way to mark a no-op Gatherer as such, allowing the Stream implementation to recognize and eliminate it from the pipeline. One idea is to add Gatherer.defaultIntegrator(), analogous to the other default? methods. Another is to add Gatherers.identity(), analogous to Function.identity(). Sometimes a factory method returns a Gatherer that only works correctly if the upstream has certain characteristics, for example Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods like Gatherers.sorted() and Gatherers.distinct(), where the Stream implementation would be able to recognize and eliminate these from the pipeline if the upstream already has these characteristics. That way we'd be able to write `return Gatherers.sorted().andThen(?);`. Another idea is to provide a Gatherer with a way to inspect the upstream characteristics. If the upstream is missing the required characteristic(s), it could then throw an IllegalStateException. The returns clause of Gatherer.Integrator::integrate just states "true if subsequent integration is desired, false if not". In particular, it doesn't document the behavior I'm observing, that returning false also causes downstream to reject any further output elements. In the Implementation Requirements section of Gatherer, rephrasing "Outputs and state later in the input sequence will be discarded if processing an earlier partition short-circuits." to something like the following would be clearer to me: "As soon as any partition short-circuits, the whole Gatherer short-circuits. The state of other partitions is discarded, i.e. there are no further invocations of the combiner. The finisher is invoked with the short-circuiting partition's state." I wouldn't mention discarding of outputs, since that's implied by the act of short-circuiting. Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jul 29 18:14:39 2024 From: duke at openjdk.org (fabioromano1) Date: Mon, 29 Jul 2024 18:14:39 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 16:50:32 GMT, Raffaello Giulietti wrote: > Also, I wonder if it wouldn't be simpler for `len` to represent the `int` length of the square root rather than the `int` length of the argument. It would be more consistent with the Bertot, Magaud, Zimmermann paper and might slightly simplify some later computation. But I'm not sure. Maybe. I think rather that representing the length of the square root is a bit confusing, since in recursive algorithms it's a more common practice to use the length of the input as an argument... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695663269 From duke at openjdk.org Mon Jul 29 18:28:40 2024 From: duke at openjdk.org (fabioromano1) Date: Mon, 29 Jul 2024 18:28:40 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 16:48:32 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> If the input is a square, then s0 == 0, so testing for non-zero remainder is redundant > > src/java.base/share/classes/java/math/MutableBigInteger.java line 550: > >> 548: */ >> 549: void safeRightShift(int n) { >> 550: if (n >= bitLength()) { > > The commit message for this reads `More accurate condition for MBI.safeRightShift()`. > If the old version works, please switch back. But if this is a genuine bug, then it needs a separate bug issue and PR. @rgiulietti The code of `MBI.safeRightShift()` works, but it seems that its correctness relies on the implementation of `MBI.rightShift()`, rather than on its own documentation or on that of `MBI.rightShift()`. The real problem is that, as usual, the preconditions of `MBI.rightShift()` are not clearly specified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695677987 From jlu at openjdk.org Mon Jul 29 19:30:36 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 29 Jul 2024 19:30:36 GMT Subject: Integrated: 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 19:17:34 GMT, Justin Lu wrote: > Please review this PR which is a simple doc only change to java.text.DecimalFormat. > > Mainly, the DecimalFormat constructors have wording that recommends using the NumberFormat factory methods for a standard formatting. This would be better tagged as an `@apiNote`. Minor wording updates included as well. > > A corresponding [CSR](https://bugs.openjdk.org/browse/JDK-8337286) has also been drafted. This pull request has now been integrated. Changeset: bd36b6ae Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/bd36b6ae5d0d760670a0bd722878614a6cd553d6 Stats: 43 lines in 1 file changed: 13 ins; 16 del; 14 mod 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage Reviewed-by: naoto, liach ------------- PR: https://git.openjdk.org/jdk/pull/20361 From liach at openjdk.org Mon Jul 29 19:42:05 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 19:42:05 GMT Subject: RFR: 8336032: Enforce immutability of Lists used by ClassFile API Message-ID: In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of mutable and immutable lists. Though the mutability of the list returned by `verify` has no particular importance, as the mutable list is constructed on every call and does not mutate the models, there are a few scenarios that they matter. Since ClassFile API is designed with immutability in mind, we should change all lists in ClassFile API to be immutable. Change summary: - Critical scenarios where ClassFile API stores mutable objects: - `ClassSignature.typeParameters` - keeps user mutable list - `CompoundElement.elementList` - buffered models expose the underlying mutable list - `RuntimeInvisibleParameterAnnotationsAttribute`(and Visible) - keeps users' nest mutable lists in an immutable list - `StackMapFrameInfo.locals/stack` - keeps user mutable lists - Optional scenarios to return immutable for good practice - `ClassFile.verify` - mutable for full verified results - `CompoundElement.elementList` - safe mutable for bound models - Fail fast on user null `Attribute`s in `BoundAttribute.readAttributes` to prevent unmodifiable list containing null I have also checked if we should stick with null-hostile `List.of` lists instead of `Collections.unmodifiableList` lists; we are using `unmodifiableList` (extensively in Signature parsing, for example) or other ad-hoc immutable lists, so it is somewhat impractical and not meaningful to enforce null-hostility. (See the list in JBS) These use sites are too sporadic so I made no unit tests. ------------- Commit messages: - 8336032: Enforce immutability of Lists used by ClassFile API Changes: https://git.openjdk.org/jdk/pull/20380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336032 Stats: 30 lines in 11 files changed: 17 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20380/head:pull/20380 PR: https://git.openjdk.org/jdk/pull/20380 From ecki at zusammenkunft.net Mon Jul 29 20:00:01 2024 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 29 Jul 2024 22:00:01 +0200 (CEST) Subject: jpackage nits Message-ID: <20240729200001.CD29D66412A@dd33810.kasserver.com> Hello, I noticed some jpackage pecularities: 1 - if you use "-i ." (and no target) it will not ignore its target directory and recursively copy itself generating a massive deep directory tree hard to remove. Sample command: jpackage --type app-image -n MyApp --main-class myapp.Main --main-jar myapp.jar -i . creates MyApp\app\MyApp\app\... It should either ignore its output dir or at least exit with an usage error 2 - when using additional launchers it prints a exception with not much more info: mkdir in type in\A.cfg [Application] app.classpath=$APPDIR\myapp.jar app.mainclass=myapp.Main [JavaOptions] java-options=-Djpackage.app-version=1.0 echo > in\myapp.jar # yes broken jpackage --type app-image -n myapp --main-class myapp.Main --main-jar myapp.jar -i in --win-console --add-launcher A=A.cfg [21:38:14.825] Exception: A.cfg It does contain the launcher and has the myapp\app\A.cfg file in there, so I am not sure what the Exception is - does it try to start it? Gruss Bernd PS: can i change the native launcher to not search the config in app\ but in its own directory and also have it relative to bin\ directory (on Windows similar to Linux). It does write the interName into the binary, but it searches only .cfg files based on the filename. From rgiulietti at openjdk.org Mon Jul 29 20:54:44 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 29 Jul 2024 20:54:44 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 18:25:54 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 550: >> >>> 548: */ >>> 549: void safeRightShift(int n) { >>> 550: if (n >= bitLength()) { >> >> The commit message for this reads `More accurate condition for MBI.safeRightShift()`. >> If the old version works, please switch back. But if this is a genuine bug, then it needs a separate bug issue and PR. > > @rgiulietti The code of `MBI.safeRightShift()` works, but it seems that its correctness relies on the implementation of `MBI.rightShift()`, rather than on its own documentation or on that of `MBI.rightShift()`. The real problem is that, as usual, the preconditions of `MBI.rightShift()` are not clearly specified. I tend to agree with your point of view, but - it is a bug: then it needs to be tracked and improved in a separate JBS issue and a separate PR - or it is not a bug, then it should not be modified in the scope of this PR if it works in the original version You can, of course, add a comment about the precondition you identified by working on this PR, as you did in other methods ("Assumes that ...). >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1946: >> >>> 1944: * @implNote The implementation is based on Zimmermann's works available >>> 1945: * here and >>> 1946: * here >> >> The following variant should be preferred, as it has a readable figure on p. 21, whereas the same figure in the variant linked in the PR seems broken for some reason. >> https://inria.hal.science/inria-00072113/document > >> The following variant should be preferred, as it has a readable figure on p. 21, whereas the same figure in the variant linked in the PR seems broken for some reason. https://inria.hal.science/inria-00072113/document > > What is the figure? I can view the same things in both versions... maybe it's a problem of the pdf reader or of the file? I'm referring to the figure that depicts the memory layout during the core algorithm (p.22 resp. p.21, depending on the variant). I tried on macOS with the standard Preview app, on Windows with Adobe Reader, on kubuntu with the standard reader, and with the reader built in Firefox. >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1948: >> >>> 1946: * here >>> 1947: */ >>> 1948: private MutableBigInteger[] sqrtRemZimmermann(int len, boolean needRemainder) { >> >> This should be called `sqrtRemKaratsuba()`. This is the name chosen by Paul Zimmermann himself. >> >> Also, I wonder if it wouldn't be simpler for `len` to represent the `int` length of the square root rather than the `int` length of the argument. It would be more consistent with the Bertot, Magaud, Zimmermann paper and might slightly simplify some later computation. But I'm not sure. > >> Also, I wonder if it wouldn't be simpler for `len` to represent the `int` length of the square root rather than the `int` length of the argument. It would be more consistent with the Bertot, Magaud, Zimmermann paper and might slightly simplify some later computation. But I'm not sure. > > Maybe. I think rather that representing the length of the square root is a bit confusing, since in recursive algorithms it's a more common practice to use the length of the input as an argument... Up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695899148 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695900955 PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695901939 From liach at openjdk.org Mon Jul 29 22:00:40 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 22:00:40 GMT Subject: RFR: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute [v4] In-Reply-To: References: Message-ID: <-WRK-eIhoqEcv9oZXu4UB0SbE0OsJ4bcJP-LxW_RzIQ=.f8ea33b4-d4da-46ce-99e1-16dca9041e27@github.com> On Mon, 29 Jul 2024 12:32:10 GMT, Chen Liang wrote: >> As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. >> >> Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Spacing style issue > > Co-authored-by: Andrey Turbanov Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20338#issuecomment-2257080060 From liach at openjdk.org Mon Jul 29 22:00:41 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 22:00:41 GMT Subject: Integrated: 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 22:41:08 GMT, Chen Liang wrote: > As discussed in offline meeting, the max stack and locals information are part of the code attribute and not meaningful for buffered code elements. Computation would be costly and these see no real usage during transformations. Thus, the proposed solution is to move these APIs to be CodeAttribute specific, as this is already how all these APIs' users are using. > > Also removed useless `Writable` on buffered models, and fixed `BufferedMethodBuilder::code` implementation. This pull request has now been integrated. Changeset: ab27090a Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/ab27090aa085283233851410827767785b3b7b1f Stats: 229 lines in 13 files changed: 142 ins; 64 del; 23 mod 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20338 From alexey.semenyuk at oracle.com Mon Jul 29 22:28:50 2024 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 29 Jul 2024 18:28:50 -0400 Subject: jpackage nits In-Reply-To: <20240729200001.CD29D66412A@dd33810.kasserver.com> References: <20240729200001.CD29D66412A@dd33810.kasserver.com> Message-ID: <834c8649-6a3e-4b4c-b2c5-565446ab5821@oracle.com> Hi Bernd, The issue with the infinite directory tree you observe looks like a duplicate of [1]. You can add "--verbose" option to jpackage command line to get more details on what is going on with jpackage. There is no way to configure the list of directories where native launcher is looking for the corresponding config file. [1] https://bugs.openjdk.org/browse/JDK-8325089 - Alexey On 7/29/2024 4:00 PM, Bernd Eckenfels wrote: > Hello, > > > I noticed some jpackage pecularities: > > 1 - if you use "-i ." (and no target) it will not ignore its target > directory and recursively copy itself generating a massive deep directory > tree hard to remove. > > Sample command: > > jpackage --type app-image -n MyApp --main-class myapp.Main --main-jar > myapp.jar -i . > > creates MyApp\app\MyApp\app\... > > It should either ignore its output dir or at least exit with an usage error > > 2 - when using additional launchers it prints a exception with not much more > info: > > mkdir in > > type in\A.cfg > [Application] > app.classpath=$APPDIR\myapp.jar > app.mainclass=myapp.Main > > [JavaOptions] > java-options=-Djpackage.app-version=1.0 > > echo > in\myapp.jar # yes broken > jpackage --type app-image -n myapp --main-class myapp.Main --main-jar > myapp.jar -i in --win-console --add-launcher A=A.cfg > [21:38:14.825] Exception: A.cfg > > It does contain the launcher and has the myapp\app\A.cfg file in there, so I > am not sure what the Exception is - does it try to start it? > > Gruss > Bernd > > PS: can i change the native launcher to not search the config in app\ but in > its own directory and also have it relative to bin\ directory (on Windows > similar to Linux). It does write the interName into the binary, but it > searches only .cfg files based on the filename. > From duke at openjdk.org Mon Jul 29 23:05:39 2024 From: duke at openjdk.org (fabioromano1) Date: Mon, 29 Jul 2024 23:05:39 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v47] In-Reply-To: References: Message-ID: <3c8Vy03Ze9QDuqRfShSMaBJP8q0C6TEMhS4ozGa_MzA=.3461c8fa-6909-4279-a9e5-0b4a656efad5@github.com> On Mon, 29 Jul 2024 20:51:39 GMT, Raffaello Giulietti wrote: >>> The following variant should be preferred, as it has a readable figure on p. 21, whereas the same figure in the variant linked in the PR seems broken for some reason. https://inria.hal.science/inria-00072113/document >> >> What is the figure? I can view the same things in both versions... maybe it's a problem of the pdf reader or of the file? > > I'm referring to the figure that depicts the memory layout during the core algorithm (p.22 resp. p.21, depending on the variant). > I tried on macOS with the standard Preview app, on Windows with Adobe Reader, on kubuntu with the standard reader, and with the reader built in Firefox. Now I noticed. I went to the wrong page. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1696059322 From liach at openjdk.org Mon Jul 29 23:11:32 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 23:11:32 GMT Subject: RFR: 8250659: Clarify in ParameterizedType.getRawType() doc that only Class is returned In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 19:20:48 GMT, Chen Liang wrote: > Clarify that only `Class` is returned for core reflection implementation, and the return type is `Type` to support other implementations, such as ones modeling unloaded or remote types. Keep-alive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19978#issuecomment-2257159982 From liach at openjdk.org Mon Jul 29 23:11:30 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 23:11:30 GMT Subject: RFR: 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 18:22:48 GMT, Chen Liang wrote: > Clarify that `ParameterizedType.getOwnerType()` always return `null` in a few scenarios. Keep-alive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2257160095 From liach at openjdk.org Mon Jul 29 23:30:48 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 23:30:48 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments [v2] In-Reply-To: References: Message-ID: <54Vm9cESCel67_6T83MfcPkoQVYP-_evYbeBQAL9YDI=.2eb7457e-2dfd-4900-a15c-f3d6ca3e4775@github.com> > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Reapply import changes after merge - Merge branch 'master' of https://github.com/openjdk/jdk into fix/accessflags-factory - 8337219: AccessFlags factories do not require necessary arguments ------------- Changes: https://git.openjdk.org/jdk/pull/20341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20341&range=01 Stats: 211 lines in 21 files changed: 71 ins; 80 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/20341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20341/head:pull/20341 PR: https://git.openjdk.org/jdk/pull/20341 From liach at openjdk.org Mon Jul 29 23:30:48 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 29 Jul 2024 23:30:48 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments In-Reply-To: References: Message-ID: <93I9hQSJh0LGonXvDVhgohzf2ydmej2gWzDuixkHoKw=.4363b0f1-1c17-4188-97eb-6e95fe5c7af0@github.com> On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote: > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. Fixed the merge conflict in BuilderBlockTest due to import reordering. Please re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20341#issuecomment-2257177179 From duke at openjdk.org Tue Jul 30 05:59:44 2024 From: duke at openjdk.org (Vanitha B P) Date: Tue, 30 Jul 2024 05:59:44 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive [v3] In-Reply-To: References: Message-ID: > tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Vanitha B P ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20312/files - new: https://git.openjdk.org/jdk/pull/20312/files/d3cae3b9..00786ad5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20312&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20312&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20312/head:pull/20312 PR: https://git.openjdk.org/jdk/pull/20312 From duke at openjdk.org Tue Jul 30 06:15:32 2024 From: duke at openjdk.org (duke) Date: Tue, 30 Jul 2024 06:15:32 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 05:59:44 GMT, Vanitha B P wrote: >> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Vanitha B P @Vanitha-bp Your change (at version 00786ad55bbddd204cdf573041855fff7a3859dc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20312#issuecomment-2257545253 From duke at openjdk.org Tue Jul 30 06:15:32 2024 From: duke at openjdk.org (Vanitha B P) Date: Tue, 30 Jul 2024 06:15:32 GMT Subject: RFR: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 16:42:52 GMT, Alexey Semenyuk wrote: >> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. > > @sashamatveev please review @alexeysemenyukoracle @sashamatveev Can you please sponsor? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20312#issuecomment-2257546695 From jkratochvil at openjdk.org Tue Jul 30 06:41:50 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 30 Jul 2024 06:41:50 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v18] In-Reply-To: References: Message-ID: > The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Implement vm.cgroup.tools - Use Metrics.systemMetrics().getProvider() - Fix testcase compatibility with Alpine Linux 3.20.1 - Reapply the patch ------------- Changes: https://git.openjdk.org/jdk/pull/17198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=17 Stats: 602 lines in 12 files changed: 531 ins; 52 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From jkratochvil at openjdk.org Tue Jul 30 07:47:55 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 30 Jul 2024 07:47:55 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v19] In-Reply-To: References: Message-ID: > The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision: - Inline adjust_controller() twice - Revert "Unify 4 copies of adjust_controller()" This reverts commit 77a81d07d74c8ae9bf34bfd8df9bcaca451ede9a. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17198/files - new: https://git.openjdk.org/jdk/pull/17198/files/7d954ea3..4aec7a6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=17-18 Stats: 202 lines in 6 files changed: 109 ins; 87 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198 PR: https://git.openjdk.org/jdk/pull/17198 From jkratochvil at openjdk.org Tue Jul 30 07:47:55 2024 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 30 Jul 2024 07:47:55 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v15] In-Reply-To: References: <9pLtIIpt-odEl5IjXSDphZU6_ldLK8_A5sfHAyc_Thw=.f147c70a-9eb6-4ca8-bc66-18baa86006c9@github.com> Message-ID: On Mon, 29 Jul 2024 05:03:22 GMT, Jan Kratochvil wrote: >> src/hotspot/os/linux/cgroupUtil_linux.cpp line 64: >> >>> 62: return cpu->adjust_controller(cpu_total); >>> 63: } >>> 64: return cpu; >> >> I guess an alternative - and maybe more readable solution - would be to inline `cpu->adjust_controller()` and `mem->adjust_controller()` code here. We have cg version agnostic api to query the limits. We'd just need accessors for `cgroup_path()` and a setter, `set_cgroup_path()` in `CgroupCpuController/CgroupMemoryController` impls. > > Currently (before my refactorization) the same code is duplicated 4 times. Do I understand the plan correctly it should be still duplicated but just 2 times? As without the duplication I do not see how to inline it. I have committed something, not sure if it is what was intended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1696483665 From asotona at openjdk.org Tue Jul 30 08:34:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 30 Jul 2024 08:34:32 GMT Subject: RFR: 8336032: Enforce immutability of Lists used by ClassFile API In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 19:36:31 GMT, Chen Liang wrote: > In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of mutable and immutable lists. > > Though the mutability of the list returned by `verify` has no particular importance, as the mutable list is constructed on every call and does not mutate the models, there are a few scenarios that they matter. Since ClassFile API is designed with immutability in mind, we should change all lists in ClassFile API to be immutable. > > Change summary: > - Critical scenarios where ClassFile API stores mutable objects: > - `ClassSignature.typeParameters` - keeps user mutable list > - `CompoundElement.elementList` - buffered models expose the underlying mutable list > - `RuntimeInvisibleParameterAnnotationsAttribute`(and Visible) - keeps users' nest mutable lists in an immutable list > - `StackMapFrameInfo.locals/stack` - keeps user mutable lists > - Optional scenarios to return immutable for good practice > - `ClassFile.verify` - mutable for full verified results > - `CompoundElement.elementList` - safe mutable for bound models > - Fail fast on user null `Attribute`s in `BoundAttribute.readAttributes` to prevent unmodifiable list containing null > > I have also checked if we should stick with null-hostile `List.of` lists instead of `Collections.unmodifiableList` lists; we are using `unmodifiableList` (extensively in Signature parsing, for example) or other ad-hoc immutable lists, so it is somewhat impractical and not meaningful to enforce null-hostility. (See the list in JBS) > > These use sites are too sporadic so I made no unit tests. Nice cleanup, thank you. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20380#pullrequestreview-2207025233 From asotona at openjdk.org Tue Jul 30 08:37:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 30 Jul 2024 08:37:32 GMT Subject: RFR: 8337219: AccessFlags factories do not require necessary arguments [v2] In-Reply-To: <54Vm9cESCel67_6T83MfcPkoQVYP-_evYbeBQAL9YDI=.2eb7457e-2dfd-4900-a15c-f3d6ca3e4775@github.com> References: <54Vm9cESCel67_6T83MfcPkoQVYP-_evYbeBQAL9YDI=.2eb7457e-2dfd-4900-a15c-f3d6ca3e4775@github.com> Message-ID: On Mon, 29 Jul 2024 23:30:48 GMT, Chen Liang wrote: >> Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. >> >> `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. >> >> However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. >> >> As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. >> >> This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Reapply import changes after merge > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/accessflags-factory > - 8337219: AccessFlags factories do not require necessary arguments Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20341#pullrequestreview-2207034646 From vklang at openjdk.org Tue Jul 30 09:28:56 2024 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 30 Jul 2024 09:28:56 GMT Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns about size method complexity Message-ID: Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result. ------------- Commit messages: - Improving the JavaDoc of ConcurrentSkipListSet::size() to reflect current reality Changes: https://git.openjdk.org/jdk/pull/20388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336462 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20388/head:pull/20388 PR: https://git.openjdk.org/jdk/pull/20388 From vklang at openjdk.org Tue Jul 30 09:28:56 2024 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 30 Jul 2024 09:28:56 GMT Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns about size method complexity In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang wrote: > Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result. @DougLea Please let me know what you think about this change. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20388#issuecomment-2257892314 From dl at openjdk.org Tue Jul 30 11:53:31 2024 From: dl at openjdk.org (Doug Lea) Date: Tue, 30 Jul 2024 11:53:31 GMT Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns about size method complexity In-Reply-To: References: Message-ID: <0C2QtJKfw20Sid8FitY6Gwlf3QdHr3mP38vtmQZMyYc=.7d9bb2bb-eb24-446f-92f6-2ca6039fcb03@github.com> On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang wrote: > Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result. Yes, thanks for fixing wording that should have been updated a long time ago. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20388#issuecomment-2258162995 From duke at openjdk.org Tue Jul 30 15:07:36 2024 From: duke at openjdk.org (Vanitha B P) Date: Tue, 30 Jul 2024 15:07:36 GMT Subject: Integrated: 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 12:20:05 GMT, Vanitha B P wrote: > tools/jpackage/windows/WinChildProcessTest.java was failing intermittently, fixed the issue and changes are tested. This pull request has now been integrated. Changeset: 2c9fd901 Author: Vanitha B P Committer: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/2c9fd9016f4675448a62380ff2b86533020e690f Stats: 20 lines in 2 files changed: 5 ins; 1 del; 14 mod 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/20312 From dev at anthonyv.be Tue Jul 30 15:20:41 2024 From: dev at anthonyv.be (Anthony Vanelverdinghe) Date: Tue, 30 Jul 2024 15:20:41 +0000 Subject: Stream Gatherers (JEP 473) feedback In-Reply-To: References: Message-ID: July 29, 2024 at 8:08 PM, "Viktor Klang" wrote: > > Hi Anthony, Hi Viktor > Thank you for your patience, and for providing feedback, it is always much appreciated. > > >When writing factory methods for Gatherers, there's sometimes a > degenerate case that requires returning a no-op Gatherer. So I'd like a > way to mark a no-op Gatherer as such, allowing the Stream implementation > to recognize and eliminate it from the pipeline. One idea is to add > Gatherer.defaultIntegrator(), analogous to the other default? methods. > Another is to add Gatherers.identity(), analogous to Function.identity(). > > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it, > but rather adding it in case it was deemed necessary. > > Do you have a concrete use-case (code) that you could share? The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer withInterpolationAt(NavigableSet instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. ` Gatherer append(T... elements)` would be another example. `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`. > >Sometimes a factory method returns a Gatherer that only works correctly > if the upstream has certain characteristics, for example > Spliterator.SORTED or Spliterator.DISTINCT. > > Do you have a concrete use-case (code) that you could share? All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results. > >One idea is to add methods > like Gatherers.sorted() and Gatherers.distinct(), where the Stream > implementation would be able to recognize and eliminate these from the > pipeline if the upstream already has these characteristics. That way > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another > idea is to provide a Gatherer with a way to inspect the upstream > characteristics. If the upstream is missing the required > characteristic(s), it could then throw an IllegalStateException. I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case. > For a rather long time Gatherer had characteristics, however, > what I noticed is that given composition of Gatherers what ended up happening > almost always was that the combination of characteristics added overhead and devolved into the empty set > real fast. > > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming. In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay. That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary. > >The returns clause of Gatherer.Integrator::integrate just states "true > if subsequent integration is desired, false if not". In particular, it > doesn't document the behavior I'm observing, that returning false also > causes downstream to reject any further output elements. > > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea) I've uploaded a test case ( https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000 ), but this is indeed already fixed in JDK 23-ea. This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases? > Cheers, > > ? > > **Viktor Klang** > Software Architect, Java Platform Group > > Oracle Kind regards, Anthony > ???????????????????????????????????????????????????????????????? > > **From:** core-libs-dev on behalf of Anthony Vanelverdinghe > **Sent:** Saturday, 27 July 2024 08:57 > **To:** core-libs-dev at openjdk.org > **Subject:** Stream Gatherers (JEP 473) feedback > ? > > When writing factory methods for Gatherers, there's sometimes a > > degenerate case that requires returning a no-op Gatherer. So I'd like a > > way to mark a no-op Gatherer as such, allowing the Stream implementation > > to recognize and eliminate it from the pipeline. One idea is to add > > Gatherer.defaultIntegrator(), analogous to the other default? methods. > > Another is to add Gatherers.identity(), analogous to Function.identity(). > > Sometimes a factory method returns a Gatherer that only works correctly > > if the upstream has certain characteristics, for example > > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream > > implementation would be able to recognize and eliminate these from the > > pipeline if the upstream already has these characteristics. That way > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another > > idea is to provide a Gatherer with a way to inspect the upstream > > characteristics. If the upstream is missing the required > > characteristic(s), it could then throw an IllegalStateException. > > The returns clause of Gatherer.Integrator::integrate just states "true > > if subsequent integration is desired, false if not". In particular, it > > doesn't document the behavior I'm observing, that returning false also > > causes downstream to reject any further output elements. > > In the Implementation Requirements section of Gatherer, rephrasing > > "Outputs and state later in the input sequence will be discarded if > > processing an earlier partition short-circuits." to something like the > > following would be clearer to me: "As soon as any partition > > short-circuits, the whole Gatherer short-circuits. The state of other > > partitions is discarded, i.e. there are no further invocations of the > > combiner. The finisher is invoked with the short-circuiting partition's > > state." I wouldn't mention discarding of outputs, since that's implied > > by the act of short-circuiting. > > Anthony > From lancea at openjdk.org Tue Jul 30 17:38:36 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 30 Jul 2024 17:38:36 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java). > - Add GZIP input test for various gzip(1) command outputs. Consider the following simple gzip test gz % cat batman.txt I am batman gz % cat hello.txt hello % cat robin.txt Robin Here gz % cat Joker.txt I am the Joker gz % gzip -c batman.txt hello.txt >> bats.gz gz % gunzip -c bats I am batman hello gz % cp bats.gz joker.gz gz % cat Joker.txt >> joker.gz gz % gunzip -c joker I am batman hello gunzip: joker.gz: trailing garbage ignored gz % cp joker.gz badRobin.gz gz % gzip -c robin.txt >> badRobin.gz gz % gunzip -c badRobin I am batman hello gunzip: badRobin.gz: trailing garbage ignored Here is the hexdump of the badRobin.gz gz % hexdump -C badRobin.gz 00000000 1f 8b 08 08 81 13 a9 66 00 03 62 61 74 6d 61 6e |.......f..batman| 00000010 2e 74 78 74 00 f3 54 48 cc 55 48 4a 2c c9 4d cc |.txt..TH.UHJ,.M.| 00000020 e3 02 00 f0 49 dd 72 0c 00 00 00 1f 8b 08 08 8f |....I.r.........| 00000030 13 a9 66 00 03 68 65 6c 6c 6f 2e 74 78 74 00 cb |..f..hello.txt..| 00000040 48 cd c9 c9 e7 02 00 20 30 3a 36 06 00 00 00 49 |H...... 0:6....I| 00000050 20 61 6d 20 74 68 65 20 4a 6f 6b 65 72 0a 1f 8b | am the Joker...| 00000060 08 08 66 0f a9 66 00 03 72 6f 62 69 6e 2e 74 78 |..f..f..robin.tx| 00000070 74 00 0b ca 4f ca cc 53 f0 48 2d 4a e5 02 00 b3 |t...O..S.H-J....| 00000080 74 fc c1 0b 00 00 00 |t......| 00000087 The following program will use GZIPInputStream and GzipCompressorinputStream to access badRobin.gz package gzip; import org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream; import org.testng.annotations.Test; import java.io.FileInputStream; import java.io.IOException; import java.util.zip.GZIPInputStream; public class GZipInputStreamTest { @Test public void openWithGZipInputStream() throws IOException { String f = "gz/badRobin.gz"; try (var is = new FileInputStream(f); var gis = new GZIPInputStream(is)) { var bytes = gis.readAllBytes(); System.out.printf("contents: %s%n", new String(bytes)); } } @Test public void openWithGzipCompressorInputStream() throws IOException { String f = "gz/badRobin.gz";; try (var is = new FileInputStream(f); var giz = new GzipCompressorInputStream(is, true)) { var bytes = giz.readAllBytes(); System.out.printf("contents: %s%n", new String(bytes)); } } } The output from openWithGZipInputStream(): contents: I am batman hello The output from openWithGzipCompressorInputStream(): java.io.IOException: Garbage after a valid .gz stream at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:193) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.read(GzipCompressorInputStream.java:356) at java.base/java.io.InputStream.readNBytes(InputStream.java:412) at java.base/java.io.InputStream.readAllBytes(InputStream.java:349) at gzip.GZipInputStreamTest.openWithGzipCompressorInputStream(GZipInputStreamTest.java:31) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) at org.testng.TestRunner.privateRun(TestRunner.java:764) at org.testng.TestRunner.run(TestRunner.java:585) at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) at org.testng.SuiteRunner.run(SuiteRunner.java:286) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) at org.testng.TestNG.runSuites(TestNG.java:1069) at org.testng.TestNG.run(TestNG.java:1037) at com.intellij.rt.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:66) at com.intellij.rt.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:105) The behavior of GZIPInputStream is in-line with gzip and gunzip where it stops processing after encountering bad data after the 8 byte end trailer containing the CRC32 and ISIZE fields . GzipCompressorInputStream throws an IOException without returning any data. WinZip on my Mac also opens badRobin.gz similar to gunzip, that is does not return an error. Based on the above, I am reluctant to change the current behavior given it appears to have been modeled after gzip/gunzip as well as WinZip. As far as providing a means to fail whenever there is bad data after the end trailer, I think we would need more input on the merits supporting this and how the behavior would be model if GZIPInputStream was enhanced. > Did you double check the unviewable issues? What does JDK-8023431 say? It is just a fix for an internal intermittent test run failure. No additional details ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2258868069 From liach at openjdk.org Tue Jul 30 17:44:34 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 30 Jul 2024 17:44:34 GMT Subject: Integrated: 8337219: AccessFlags factories do not require necessary arguments In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote: > Removes 6 `AccessFlags` factories that do not take class-file versions as its arguments. > > `AccessFlags` is a wrapper around a bit mask to support modifier streaming in ClassFile API. It additionally supports advanced validation based on location. > > However, as class file versions evolve, we may also need a class file version argument to ensure that the flags are correctly constructed. For example, a pre-valhalla class modifier without `ACC_SUPER` should not be interpreted as a value class. The current factories cannot find good default class file versions, and if they always assume latest, they will fail in this scenario. > > As a result, we should remove these 6 factories; note that users can still set the flags via `XxxBuilder::withFlags` with either `int` or `AccessFlag...` flags. In contrast, these builder APIs can fetch the previously-passed class file versions, and correctly validate or interpret these flags. Same story goes for parsing, which can also construct the right flags with available information. > > This enables us to add methods to interpret the logical flags with version-specific information. If there's need, we can always add a new `AccessFlags.of(int, AccessFlag.Location, ClassFileFormatVersion)` factory, given the flexibility from this removal. This pull request has now been integrated. Changeset: 93c19ac7 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/93c19ac73c2feb8d6191bc5da98b4a9c8e2b5590 Stats: 211 lines in 21 files changed: 71 ins; 80 del; 60 mod 8337219: AccessFlags factories do not require necessary arguments Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20341 From liach at openjdk.org Tue Jul 30 17:44:36 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 30 Jul 2024 17:44:36 GMT Subject: Integrated: 8336032: Enforce immutability of Lists used by ClassFile API In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 19:36:31 GMT, Chen Liang wrote: > In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of mutable and immutable lists. > > Though the mutability of the list returned by `verify` has no particular importance, as the mutable list is constructed on every call and does not mutate the models, there are a few scenarios that they matter. Since ClassFile API is designed with immutability in mind, we should change all lists in ClassFile API to be immutable. > > Change summary: > - Critical scenarios where ClassFile API stores mutable objects: > - `ClassSignature.typeParameters` - keeps user mutable list > - `CompoundElement.elementList` - buffered models expose the underlying mutable list > - `RuntimeInvisibleParameterAnnotationsAttribute`(and Visible) - keeps users' nest mutable lists in an immutable list > - `StackMapFrameInfo.locals/stack` - keeps user mutable lists > - Optional scenarios to return immutable for good practice > - `ClassFile.verify` - mutable for full verified results > - `CompoundElement.elementList` - safe mutable for bound models > - Fail fast on user null `Attribute`s in `BoundAttribute.readAttributes` to prevent unmodifiable list containing null > > I have also checked if we should stick with null-hostile `List.of` lists instead of `Collections.unmodifiableList` lists; we are using `unmodifiableList` (extensively in Signature parsing, for example) or other ad-hoc immutable lists, so it is somewhat impractical and not meaningful to enforce null-hostility. (See the list in JBS) > > These use sites are too sporadic so I made no unit tests. This pull request has now been integrated. Changeset: 6154a212 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/6154a2129ba505b7163a1998792296827a056750 Stats: 30 lines in 11 files changed: 17 ins; 1 del; 12 mod 8336032: Enforce immutability of Lists used by ClassFile API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/20380 From acobbs at openjdk.org Tue Jul 30 18:09:35 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 30 Jul 2024 18:09:35 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: <4GNj_u_APxeY3aAUGDVecfvksHP53FvNgA_oktKzr80=.68d7b6c3-ddb0-49fd-966f-b64cfb384d98@github.com> On Tue, 30 Jul 2024 17:35:33 GMT, Lance Andersen wrote: > Based on the above, I am reluctant to change the current behavior given it appears to have been modeled after gzip/gunzip as well as WinZip. That's a reasonable conclusion... and I have no problem with preserving the existing behavior if that's what we want. But in that case I would lobby that we should also provide some new way to configure a `GZIPInputStream` that guarantees reliable behavior. The key question here is: "Exactly what current behavior of `new GZIPInputStream(in)` do we want to preserve?" Let's start by assuming that we want your above test to pass. Putting that into words: "Given a single GZIP stream followed by trailing garbage, `new GZIPInputStream(in)` should successfully decode the GZIP stream and ignore the trailing garbage". Note however that what `new GZIPInputStream(in)` currently provides is stronger than that: 1. Trailing garbage is ignored 1. Any `IOException` thrown while reading trailing garbage is ignored 1. Concatenated streams are automatically decoded So we know we want to preserve 1 - What about 2 and/or 3? Your thoughts? My personal opinions: * I think 2 is inherently bad and it should not be implemented in any variant * I think 3 is not required _by default_, but one should be able to enable it somehow If we were to accept those opinions (preserving only 1), then we would end up at the same place as `GzipCompressorInputStream`: * Underlying `IOException`'s are never suppressed * `new GZIPInputStream(in)` decodes only one GIZP stream and ignores any trailing garbage * `new GZIPInputStream(in, true)` decodes concatenated streams; trailing garbage causes `IOException` ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2258919532 From acobbs at openjdk.org Tue Jul 30 19:02:35 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 30 Jul 2024 19:02:35 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java). > - Add GZIP input test for various gzip(1) command outputs. Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration. Then basically all we would be changing is no longer suppressing `IOException`'s. And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage. (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2259012402 From darcy at openjdk.org Wed Jul 31 01:46:09 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 31 Jul 2024 01:46:09 GMT Subject: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} [v4] In-Reply-To: References: Message-ID: > First pass at adding some quality of implementation discussions around the overridable methods of Object. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8336043 - Respond to review feedback. - Merge branch 'master' into JDK-8336043 - Appease jcheck. - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20128/files - new: https://git.openjdk.org/jdk/pull/20128/files/95f890bf..80cabee0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20128&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20128&range=02-03 Stats: 12515 lines in 364 files changed: 7143 ins; 4052 del; 1320 mod Patch: https://git.openjdk.org/jdk/pull/20128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20128/head:pull/20128 PR: https://git.openjdk.org/jdk/pull/20128 From redestad at openjdk.org Wed Jul 31 13:16:35 2024 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 31 Jul 2024 13:16:35 GMT Subject: RFR: 8336856: Optimize String Concat [v20] In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 15:59:05 GMT, Shaojin Wen wrote: >> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. >> >> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "cache generate MethodHandle" > > This reverts commit 996ffb5ba46aa2861b48cc783d5c824d3721f976. Sent a couple of suggestions in form of a PR here: https://github.com/wenshao/jdk/pull/8 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2260497537 From jvernee at openjdk.org Wed Jul 31 13:48:05 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 31 Jul 2024 13:48:05 GMT Subject: RFR: 8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp Message-ID: This test spawns 2 forked processes, which then try to trigger a code cache OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow, which increases dramatically with `-Xcomp`, since startup Java code has to be compiled 3 times, once for the main test process, and then 2 more times for forks. There is seemingly no/very little benefit of running this test with `-Xcomp`, since the test targets hotspot, not Java code. That and the test is sensitive to code cache usage, which is changed by `-Xcomp`. So, to avoid instabilities, this PR proposes to disable the test when running with `-Xcomp`. Another option is to not forward the VM flags of the parent process to the forks, but, on the off chance that this is useful for testing some other flags, this PR chooses the approach of disabling the test when running with `-Xcomp` instead. ------------- Commit messages: - disable TestStubAllocFailure with -Xcomp Changes: https://git.openjdk.org/jdk/pull/20407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324260 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20407/head:pull/20407 PR: https://git.openjdk.org/jdk/pull/20407 From alanb at openjdk.org Wed Jul 31 13:51:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 31 Jul 2024 13:51:31 GMT Subject: RFR: 8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote: > This test spawns 2 forked processes, which then try to trigger a code cache OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow, which increases dramatically with `-Xcomp`, since startup Java code has to be compiled 3 times, once for the main test process, and then 2 more times for forks. > > There is seemingly no/very little benefit of running this test with `-Xcomp`, since the test targets hotspot, not Java code. That and the test is sensitive to code cache usage, which is changed by `-Xcomp`. > > So, to avoid instabilities, this PR proposes to disable the test when running with `-Xcomp`. Another option is to not forward the VM flags of the parent process to the forks, but, on the off chance that this is useful for testing some other flags, this PR chooses the approach of disabling the test when running with `-Xcomp` instead. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20407#pullrequestreview-2210229445 From duke at openjdk.org Wed Jul 31 13:56:10 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 31 Jul 2024 13:56:10 GMT Subject: RFR: 8336856: Optimize String Concat [v21] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with three additional commits since the last revision: - Merge pull request #8 from cl4es/pr_20273_fixes Simplify, erase, remove ClassOption.STRONG - Merged - Simplify, remove STRONG relationship, erase argument types, repurpose argument slots ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/be9952c5..f897301c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=19-20 Stats: 99 lines in 1 file changed: 36 ins; 58 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From jpai at openjdk.org Wed Jul 31 15:09:30 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Jul 2024 15:09:30 GMT Subject: RFR: 8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote: > This test spawns 2 forked processes, which then try to trigger a code cache OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow, which increases dramatically with `-Xcomp`, since startup Java code has to be compiled 3 times, once for the main test process, and then 2 more times for forks. > > There is seemingly no/very little benefit of running this test with `-Xcomp`, since the test targets hotspot, not Java code. That and the test is sensitive to code cache usage, which is changed by `-Xcomp`. > > So, to avoid instabilities, this PR proposes to disable the test when running with `-Xcomp`. Another option is to not forward the VM flags of the parent process to the forks, but, on the off chance that this is useful for testing some other flags, this PR chooses the approach of disabling the test when running with `-Xcomp` instead. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20407#pullrequestreview-2210452842 From lancea at openjdk.org Wed Jul 31 15:54:35 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 31 Jul 2024 15:54:35 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 19:00:13 GMT, Archie Cobbs wrote: > Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration. > > Then basically all we would be changing is no longer suppressing `IOException`'s. > > And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage. > > (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.) We don't want to change this long standing behavior as it has the potential of breaking existing applications and it is consistent with gzip and also winzip. So through this PR, we should clarify the javadoc as to what current GZIPInputStream implementation does and add additional tests to expand the coverage A separate discussion can take place to discuss the merits of whether there is perceived value in throwing an IOException when trailing garbage is encountered as well as any benefit of not supporting concatenated gzip files. It will also allow time for further review of other tools/apis that support gzip to see what they may or may not do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2260843724 From rgiulietti at openjdk.org Wed Jul 31 17:35:40 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 31 Jul 2024 17:35:40 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v45] In-Reply-To: <00cyd6u6wYE2j3LCDOu-gn0zMbUsAecSoQA5en7Qsjk=.fa0493f4-747a-46a1-bf32-775fd7e45cd3@github.com> References: <00cyd6u6wYE2j3LCDOu-gn0zMbUsAecSoQA5en7Qsjk=.fa0493f4-747a-46a1-bf32-775fd7e45cd3@github.com> Message-ID: On Sat, 27 Jul 2024 15:01:30 GMT, fabioromano1 wrote: >> On my M1 Pro/32 GiB >> >> Current >> >> Benchmark Mode Cnt Score Error Units >> BigIntegerSquareRoot.testBigSqrtAndRemainder avgt 15 45.655 ? 0.273 ns/op >> BigIntegerSquareRoot.testHugeSqrtAndRemainder avgt 15 1200587.822 ? 7358.024 ns/op >> BigIntegerSquareRoot.testLargeSqrtAndRemainder avgt 15 27.052 ? 0.143 ns/op >> BigIntegerSquareRoot.testSmallSqrtAndRemainder avgt 15 33.098 ? 0.207 ns/op >> >> >> New >> >> Benchmark Mode Cnt Score Error Units >> BigIntegerSquareRoot.testBigSqrtAndRemainder avgt 15 21.110 ? 0.151 ns/op >> BigIntegerSquareRoot.testHugeSqrtAndRemainder avgt 15 21525.493 ? 36.219 ns/op >> BigIntegerSquareRoot.testLargeSqrtAndRemainder avgt 15 14.897 ? 0.257 ns/op >> BigIntegerSquareRoot.testSmallSqrtAndRemainder avgt 15 15.539 ? 0.146 ns/op >> >> >> Nice! > > @rgiulietti Should the current implementation of the square root algorithm be deleted or should it be preserved? @fabioromano1 The code is in good shape. I'll probably add some other comments once the suggestions above, and other changes you might want to add, have been committed. No need to rush, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2261020319 From shade at openjdk.org Wed Jul 31 17:42:31 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 31 Jul 2024 17:42:31 GMT Subject: RFR: 8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote: > This test spawns 2 forked processes, which then try to trigger a code cache OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow, which increases dramatically with `-Xcomp`, since startup Java code has to be compiled 3 times, once for the main test process, and then 2 more times for forks. > > There is seemingly no/very little benefit of running this test with `-Xcomp`, since the test targets hotspot, not Java code. That and the test is sensitive to code cache usage, which is changed by `-Xcomp`. > > So, to avoid instabilities, this PR proposes to disable the test when running with `-Xcomp`. Another option is to not forward the VM flags of the parent process to the forks, but, on the off chance that this is useful for testing some other flags, this PR chooses the approach of disabling the test when running with `-Xcomp` instead. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20407#pullrequestreview-2210769865 From viktor.klang at oracle.com Wed Jul 31 17:58:16 2024 From: viktor.klang at oracle.com (Viktor Klang) Date: Wed, 31 Jul 2024 17:58:16 +0000 Subject: [External] : Re: Stream Gatherers (JEP 473) feedback In-Reply-To: References: Message-ID: Hi Anthony, >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer withInterpolationAt(NavigableSet instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. ` Gatherer append(T... elements)` would be another example. `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`. Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument? >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary. Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers). >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases? Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Anthony Vanelverdinghe Sent: Tuesday, 30 July 2024 17:20 To: Viktor Klang ; core-libs-dev at openjdk.org Subject: [External] : Re: Stream Gatherers (JEP 473) feedback July 29, 2024 at 8:08 PM, "Viktor Klang" wrote: > > Hi Anthony, Hi Viktor > Thank you for your patience, and for providing feedback, it is always much appreciated. > > >When writing factory methods for Gatherers, there's sometimes a > degenerate case that requires returning a no-op Gatherer. So I'd like a > way to mark a no-op Gatherer as such, allowing the Stream implementation > to recognize and eliminate it from the pipeline. One idea is to add > Gatherer.defaultIntegrator(), analogous to the other default? methods. > Another is to add Gatherers.identity(), analogous to Function.identity(). > > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it, > but rather adding it in case it was deemed necessary. > > Do you have a concrete use-case (code) that you could share? The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer withInterpolationAt(NavigableSet instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. ` Gatherer append(T... elements)` would be another example. `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`. > >Sometimes a factory method returns a Gatherer that only works correctly > if the upstream has certain characteristics, for example > Spliterator.SORTED or Spliterator.DISTINCT. > > Do you have a concrete use-case (code) that you could share? All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results. > >One idea is to add methods > like Gatherers.sorted() and Gatherers.distinct(), where the Stream > implementation would be able to recognize and eliminate these from the > pipeline if the upstream already has these characteristics. That way > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another > idea is to provide a Gatherer with a way to inspect the upstream > characteristics. If the upstream is missing the required > characteristic(s), it could then throw an IllegalStateException. I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case. > For a rather long time Gatherer had characteristics, however, > what I noticed is that given composition of Gatherers what ended up happening > almost always was that the combination of characteristics added overhead and devolved into the empty set > real fast. > > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming. In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay. That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary. > >The returns clause of Gatherer.Integrator::integrate just states "true > if subsequent integration is desired, false if not". In particular, it > doesn't document the behavior I'm observing, that returning false also > causes downstream to reject any further output elements. > > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea) I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$ ), but this is indeed already fixed in JDK 23-ea. This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases? > Cheers, > > ? > > **Viktor Klang** > Software Architect, Java Platform Group > > Oracle Kind regards, Anthony > ???????????????????????????????????????????????????????????????? > > **From:** core-libs-dev on behalf of Anthony Vanelverdinghe > **Sent:** Saturday, 27 July 2024 08:57 > **To:** core-libs-dev at openjdk.org > **Subject:** Stream Gatherers (JEP 473) feedback > > > When writing factory methods for Gatherers, there's sometimes a > > degenerate case that requires returning a no-op Gatherer. So I'd like a > > way to mark a no-op Gatherer as such, allowing the Stream implementation > > to recognize and eliminate it from the pipeline. One idea is to add > > Gatherer.defaultIntegrator(), analogous to the other default? methods. > > Another is to add Gatherers.identity(), analogous to Function.identity(). > > Sometimes a factory method returns a Gatherer that only works correctly > > if the upstream has certain characteristics, for example > > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream > > implementation would be able to recognize and eliminate these from the > > pipeline if the upstream already has these characteristics. That way > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another > > idea is to provide a Gatherer with a way to inspect the upstream > > characteristics. If the upstream is missing the required > > characteristic(s), it could then throw an IllegalStateException. > > The returns clause of Gatherer.Integrator::integrate just states "true > > if subsequent integration is desired, false if not". In particular, it > > doesn't document the behavior I'm observing, that returning false also > > causes downstream to reject any further output elements. > > In the Implementation Requirements section of Gatherer, rephrasing > > "Outputs and state later in the input sequence will be discarded if > > processing an earlier partition short-circuits." to something like the > > following would be clearer to me: "As soon as any partition > > short-circuits, the whole Gatherer short-circuits. The state of other > > partitions is discarded, i.e. there are no further invocations of the > > combiner. The finisher is invoked with the short-circuiting partition's > > state." I wouldn't mention discarding of outputs, since that's implied > > by the act of short-circuiting. > > Anthony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jul 31 18:07:14 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 31 Jul 2024 18:07:14 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v48] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Revision changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/53b7adca..a8d8b296 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=47 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=46-47 Stats: 67 lines in 3 files changed: 13 ins; 2 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From duke at openjdk.org Wed Jul 31 18:52:12 2024 From: duke at openjdk.org (fabioromano1) Date: Wed, 31 Jul 2024 18:52:12 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v49] In-Reply-To: References: Message-ID: > I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Memory usage optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/a8d8b296..f85f2a55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=48 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=47-48 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710 From rgiulietti at openjdk.org Wed Jul 31 19:08:37 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 31 Jul 2024 19:08:37 GMT Subject: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v49] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 18:52:12 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Memory usage optimization On Apple M1 Pro/32 GiB before Benchmark Mode Cnt Score Error Units BigIntegerSquareRoot.testSqrtL avgt 15 199747.794 ? 6173.446 ns/op BigIntegerSquareRoot.testSqrtM avgt 15 14902.574 ? 1291.014 ns/op BigIntegerSquareRoot.testSqrtS avgt 15 2093.805 ? 76.538 ns/op BigIntegerSquareRoot.testSqrtXL avgt 15 1188345.044 ? 1049.728 ns/op BigIntegerSquareRoot.testSqrtXS avgt 15 19.693 ? 0.350 ns/op after Benchmark Mode Cnt Score Error Units BigIntegerSquareRoot.testSqrtL avgt 15 2760.508 ? 56.561 ns/op BigIntegerSquareRoot.testSqrtM avgt 15 724.419 ? 30.709 ns/op BigIntegerSquareRoot.testSqrtS avgt 15 193.664 ? 0.689 ns/op BigIntegerSquareRoot.testSqrtXL avgt 15 21068.074 ? 358.149 ns/op BigIntegerSquareRoot.testSqrtXS avgt 15 4.871 ? 0.096 ns/op Impressive! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2261214678 From duke at openjdk.org Wed Jul 31 21:19:57 2024 From: duke at openjdk.org (fitzsim) Date: Wed, 31 Jul 2024 21:19:57 GMT Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files [v2] In-Reply-To: References: Message-ID: > 8334048: -Xbootclasspath can not read some ZIP64 zip files fitzsim has updated the pull request incrementally with six additional commits since the last revision: - BootClassPathZipFileTest: Add test - BootClassPathZip64Test: Remove test - BootClassPathZip64Test: Delete class file in finally block - BootClassPathZip64Test: Generate ZIP file dynamically, if possible - BootClassPathZip64Test: Do not attempt to delete the ZIP file Leave deletion to the test harness instead, to avoid this on windows-x64: command: main -Xbootclasspath/a:./Zip64.zip BootClassPathZip64Test reason: User specified action: run main/othervm -Xbootclasspath/a:./Zip64.zip BootClassPathZip64Test started: Tue Jul 02 22:10:56 UTC 2024 Mode: othervm [/othervm specified] finished: Tue Jul 02 22:10:56 UTC 2024 elapsed time (seconds): 0.265 configuration: STDOUT: STDERR: java.nio.file.FileSystemException: Zip64.zip: The process cannot access the file because it is being used by another process at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108) at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:273) at java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:110) at java.base/java.nio.file.Files.deleteIfExists(Files.java:1192) at BootClassPathZip64Creator.tearDown(BootClassPathZip64Creator.java:342) at BootClassPathZip64Test.main(BootClassPathZip64Test.java:57) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575) - BootClassPathZip64Test: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19678/files - new: https://git.openjdk.org/jdk/pull/19678/files/37f981ce..4505172d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19678&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19678&range=00-01 Stats: 157 lines in 2 files changed: 157 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19678/head:pull/19678 PR: https://git.openjdk.org/jdk/pull/19678 From duke at openjdk.org Wed Jul 31 21:19:57 2024 From: duke at openjdk.org (fitzsim) Date: Wed, 31 Jul 2024 21:19:57 GMT Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 14:02:58 GMT, fitzsim wrote: > 8334048: -Xbootclasspath can not read some ZIP64 zip files It turns out ZIP64 is underrepresented in the test suite in general; for example, https://bugs.openjdk.org/browse/JDK-8185896 is still open. Using the Java class library alone, I have not been able to produce a ZIP file that demonstrates this issue. I have ideas about how the standard ZIP classes could be modified to produce small ZIP64 files suitable for testing various code paths. I was able to produce a small ZIP file using the Info-ZIP command line tool that does demonstrate the issue. To keep the test setup simple, I inlined the ZIP file as byte constants in `BootClassPathZip64Creator`, the driver for `BootClassPathZip64Test`. Next I am going to check the code coverage provided by this test case for the proposed `zip_util.c` fix. I saw and looked into this failure: `2024-07-03T09:37:42.6540920Z at ZipSourceCache.testKeySourceMapping(ZipSourceCache.java:102)` ... `Suppressed: java.nio.file.FileSystemException: 1719999454994-bug8317678.zip: The process cannot access the file because it is being used by another process` but I could not see how `zip_util.c` could cause that. I re-ran [windows-x64 / test (jdk/tier1 part 2)](https://github.com/fitzsim/jdk/actions/runs/9774287212/job/26997159267) and that issue resolved itself. I am not sure at this point if this could be caused by the `zip_util.c` changes, or if it is a transient `windows-x64` builder issue. I was able to get the same _"invalid CEN header (bad signature)"_ error for `-Xbootclasspath` with a ZIP file generated using the `ZipFileSystem` API, using `Map env = Map.of("create", "true", "forceZIP64End", "true");` like `readZip64EndZipFs` does in `test/jdk/java/util/zip/ZipFile/ReadZip.java` (https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/ReadZip.java#L230). Given it is the same failure mode, I am inclined not to add a Java part to the test case. I noticed that `readZip64EndInfoZIPStreaming` in that same test case uses the approach I found independently for creating a small ZIP64 file, and it also inlines the bytes of that small ZIP file. Therefore the inlining approach in `BootClassPathZip64Creator` does not regress [JDK-8321616](https://bugs.openjdk.org/browse/JDK-8321616). I still would like to exercise at least one branch of the heuristics conditional with another test case, so I will work on that next. At that point, I suspect one could argue that [JDK-8185896](https://bugs.openjdk.org/browse/JDK-8185896) is addressed, unless one would prefer to create another set of expensive tests using large-payload ZIP64 files. This patch set is ready for review. I was able to eliminate the Info-ZIP dependency and shrink the test logic significantly. I added two new test cases, one for non-ZIP64 ZIP files, and one for a ZIP64 file with magic values in CEN, both of which worked before and continue to work with the fix proposed in this pull request. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2204456736 PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2206421991 PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2229497634 PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2261474735 From duke at openjdk.org Wed Jul 31 21:54:15 2024 From: duke at openjdk.org (fitzsim) Date: Wed, 31 Jul 2024 21:54:15 GMT Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files [v3] In-Reply-To: References: Message-ID: > 8334048: -Xbootclasspath can not read some ZIP64 zip files fitzsim has updated the pull request incrementally with one additional commit since the last revision: BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19678/files - new: https://git.openjdk.org/jdk/pull/19678/files/4505172d..29090779 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19678&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19678&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/19678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19678/head:pull/19678 PR: https://git.openjdk.org/jdk/pull/19678 From duke at openjdk.org Wed Jul 31 22:01:39 2024 From: duke at openjdk.org (fitzsim) Date: Wed, 31 Jul 2024 22:01:39 GMT Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim wrote: >> 8334048: -Xbootclasspath can not read some ZIP64 zip files > > fitzsim has updated the pull request incrementally with one additional commit since the last revision: > > BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions I realized the constructors could instead just be static function calls, so I pushed a small change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2261530971 From duke at openjdk.org Wed Jul 31 22:27:53 2024 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 31 Jul 2024 22:27:53 GMT Subject: RFR: 8336856: Optimize String Concat [v22] In-Reply-To: References: Message-ID: > The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean. > > This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: use ClassFile ACC Flags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20273/files - new: https://git.openjdk.org/jdk/pull/20273/files/f897301c..d573c297 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=20-21 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273 PR: https://git.openjdk.org/jdk/pull/20273 From acobbs at openjdk.org Wed Jul 31 22:52:32 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 31 Jul 2024 22:52:32 GMT Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8] In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF. >> >> There are several issues with this: >> >> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified. >> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams). >> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation. >> >> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)). >> >> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed. > > Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java). > - Add GZIP input test for various gzip(1) command outputs. It seems like we're going around in circles a bit here... but maybe the circles are getting smaller? But I'm also running out of steam... > We don't want to change this long standing behavior as it has the potential of breaking existing applications and it is consistent with gzip and also winzip. Sounds great. In fact my original plan was to not change the existing behavior at all (by putting all of the new/improved behavior behind a new constructor)... > So through this PR, we should clarify the javadoc as to what current GZIPInputStream implementation does and add additional tests to expand the coverage Event just doing this has some subtlety to it... Note, none of the current behavior is actually specified (the entirety of the Javadoc says: "This class implements a stream filter for reading compressed data in the GZIP file format"), so any description we add creates a new actual specification for the future. Are you sure we want to do that for all of the current behavior? I would think maybe for some we do and for some we don't: * Swallowing `IOException`'s - this we should not specify, so that we may someday eliminate it to make this class reliable * Concatenated GZIP's - this would be good to document * Reading extra bytes - the only thing to document would be that "there is a chance extra bytes will be read" which is not very useful, so what's the point? What of that would you want to specify? My original idea was to only add specification for the new/improved functionality, and leave the existing functionality. If we go this route, then the only thing to decide would be what new/improved functionality we want to add. > A separate discussion can take place to discuss the merits of whether there is perceived value in throwing an IOException when trailing garbage is encountered as well as any benefit of not supporting concatenated gzip files. It will also allow time for further review of other tools/apis that support gzip to see what they may or may not do. Guess I thought we were sort-of having those discussions now... What do we agree on? * Supporting concatenation is a good thing * Supporting ignoring trailing garbage is a good thing What is there debate about? * Swallowing trailing garbage `IOException`'s - I think it is a bad thing, but it's required for backward compatibility * Precise stops when `markSupported() = true` - I think it is a good thing (and it is backward compatible) * Support for reading only one GZIP stream - I think it is a good thing, especially useful when combined with previous IMO doing nothing is a bad option, because as it stands today the class is fundamentally unreliable, and we should at minimum provide some new way to get reliable behavior (doing so doesn't require changing the existing behavior). ------------- PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2261597142