Re: RFR: 8312436: CompletableFuture never completes when 'Throwable.toString()' method throws Exception

2024-06-27 Thread kerr
On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang wrote: > Primarily offering this PR for discussion, as Throwables throwing exceptions > on toString(), getLocalizedMessage(), or getMessage() seems like a rather > unreasonable thing to do. > > Nevertheless, there is some things we can do, as witn

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v14]

2024-06-27 Thread lingjun-cg
> ### 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 St

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v18]

2024-06-27 Thread fabioromano1
> 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 New

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v17]

2024-06-27 Thread Joe Darcy
On Thu, 27 Jun 2024 20:08:42 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

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v17]

2024-06-27 Thread fabioromano1
> 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 New

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v13]

2024-06-27 Thread Naoto Sato
On Thu, 27 Jun 2024 18:31:30 GMT, Justin Lu wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > test/micro/org/openjdk/bench/java/text/DefFormatterBench.java li

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v13]

2024-06-27 Thread Chen Liang
On Thu, 27 Jun 2024 11:09:27 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.

Re: RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should be final

2024-06-27 Thread Chen Liang
On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev wrote: > I was auditing the current uses of `@Stable` before relaxing its barriers > ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an > easy spot. > > `resolvedEnum` is not `final`. So technically publishing the ob

RFR: 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should be final

2024-06-27 Thread Aleksey Shipilev
I was auditing the current uses of `@Stable` before relaxing its barriers ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an easy spot. `resolvedEnum` is not `final`. So technically publishing the object via data race can show `resolvedEnum` as `null`, which would bre

Re: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v3]

2024-06-27 Thread Jan Lahoda
On Thu, 27 Jun 2024 19:07:07 GMT, ExE Boss wrote: > Since `labels` is no longer eagerly cloned, it’s important to store the > converted labels into a local array to avoid leaking them to user code. True. But it is easier and cleaner, IMO, to simply put back cloning of the labels.

Re: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v4]

2024-06-27 Thread Jan Lahoda
> 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

Re: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v3]

2024-06-27 Thread ExE Boss
On Thu, 27 Jun 2024 15:32:38 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 r

Re: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container [v7]

2024-06-27 Thread Larry Cable
On Tue, 25 Jun 2024 13:54:46 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/c

Re: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v2]

2024-06-27 Thread ExE Boss
On Thu, 27 Jun 2024 15:25:36 GMT, Chen Liang wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reflecting review feedback. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 286: > >> 284:

Re: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container [v7]

2024-06-27 Thread Larry Cable
On Tue, 25 Jun 2024 13:54:46 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/c

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v12]

2024-06-27 Thread Justin Lu
On Thu, 27 Jun 2024 11:19:44 GMT, lingjun-cg wrote: >> src/java.base/share/classes/java/text/StringBufFactory.java line 45: >> >>> 43: } >>> 44: >>> 45: private static class StringBufferImpl implements Format.StringBuf { >> >> The implementations may be more concise as a `record class`

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v13]

2024-06-27 Thread Justin Lu
On Thu, 27 Jun 2024 11:09:27 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.

Re: RFR: 8335182: Consolidate and streamline String concat code shapes

2024-06-27 Thread Chen Liang
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

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v16]

2024-06-27 Thread fabioromano1
> 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 New

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v9]

2024-06-27 Thread fabioromano1
On Mon, 24 Jun 2024 17:09:30 GMT, Daniel Jeliński wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Code optimization > > Thanks. That's a very nice performance improvement, on my Windows machine the > `testHuge...`

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v15]

2024-06-27 Thread fabioromano1
> 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 New

Re: RFR: 8335182: Consolidate and streamline String concat code shapes

2024-06-27 Thread Claes Redestad
On Thu, 27 Jun 2024 16:05:09 GMT, Chen Liang 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

Re: RFR: 8335182: Consolidate and streamline String concat code shapes

2024-06-27 Thread Chen Liang
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

Re: RFR: 8335252: ForceInline j.u.Formatter.Conversion#isValid [v2]

2024-06-27 Thread Paul Sandoz
On Thu, 27 Jun 2024 14:12:36 GMT, Shaojin Wen wrote: >> Currently, the java.util.Formatter$Conversion::isValid method is implemented >> based on switch, which cannot be inlined because codeSize > 325. This >> problem can be avoided by implementing it with ImmutableBitSetPredicate. >> >> use `-

Re: RFR: 8335182: Consolidate and streamline String concat code shapes

2024-06-27 Thread Jorn Vernee
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

Re: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v3]

2024-06-27 Thread Jan Lahoda
> 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

Re: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v2]

2024-06-27 Thread Chen Liang
On Thu, 27 Jun 2024 14:06:42 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 r

Re: RFR: 8335252: Use ImmutableBitSetPredicate optimize j.u.Formatter.Conversion#isValid [v2]

2024-06-27 Thread Shaojin Wen
On Thu, 27 Jun 2024 14:12:36 GMT, Shaojin Wen wrote: >> Currently, the java.util.Formatter$Conversion::isValid method is implemented >> based on switch, which cannot be inlined because codeSize > 325. This >> problem can be avoided by implementing it with ImmutableBitSetPredicate. >> >> use `-

Re: RFR: 8335252: Use ImmutableBitSetPredicate optimize j.u.Formatter.Conversion#isValid [v2]

2024-06-27 Thread Shaojin Wen
> Currently, the java.util.Formatter$Conversion::isValid method is implemented > based on switch, which cannot be inlined because codeSize > 325. This problem > can be avoided by implementing it with ImmutableBitSetPredicate. > > use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the

Re: RFR: 8332522: SwitchBootstraps::mappedEnumLookup constructs unused array [v2]

2024-06-27 Thread Jan Lahoda
> 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

Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]

2024-06-27 Thread Jan Lahoda
On Mon, 24 Jun 2024 12:57:39 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

Integrated: 8333308: javap --system handling doesn't work on internal class names

2024-06-27 Thread Sonia Zaldana Calles
On Tue, 25 Jun 2024 13:59:35 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [JDK-808](https://bugs.openjdk.org/browse/JDK-808) > enabling `javap -system` to handle internal class names. > > Thanks, > Sonia This pull request has now been integrated. Changeset: d5

RFR: 8335182: Consolidate and streamline String concat code shapes

2024-06-27 Thread Claes Redestad
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 expres

Re: RFR: 8335252: Use ImmutableBitSetPredicate optimize j.u.Formatter.Conversion#isValid

2024-06-27 Thread Claes Redestad
On Thu, 27 Jun 2024 11:48:56 GMT, Shaojin Wen wrote: > * byte codes of `Conversion.isValid` It's surprising that javac generates synthetic cases identical to the default case for every char in the 37 to 120 range (the bounds seem to be the lowest and highest of the constants). Is there a ben

Re: RFR: 8335252: Use ImmutableBitSetPredicate optimize j.u.Formatter.Conversion#isValid

2024-06-27 Thread Shaojin Wen
On Thu, 27 Jun 2024 11:14:30 GMT, Shaojin Wen wrote: > Currently, the java.util.Formatter$Conversion::isValid method is implemented > based on switch, which cannot be inlined because codeSize > 325. This problem > can be avoided by implementing it with ImmutableBitSetPredicate. > > use `-XX:+U

RFR: 8335252: Use ImmutableBitSetPredicate optimize j.u.Formatter.Conversion#isValid

2024-06-27 Thread Shaojin Wen
Currently, the java.util.Formatter$Conversion::isValid method is implemented based on switch, which cannot be inlined because codeSize > 325. This problem can be avoided by implementing it with ImmutableBitSetPredicate. use `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` to see the master b

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v12]

2024-06-27 Thread lingjun-cg
On Thu, 27 Jun 2024 05:08:06 GMT, Justin Lu wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > src/java.base/share/classes/java/text/StringBufFactory.java line

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v13]

2024-06-27 Thread lingjun-cg
> ### 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 St

Re: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v2]

2024-06-27 Thread Aleksei Efimov
On Wed, 26 Jun 2024 20:41:56 GMT, Jonathan Gibbons wrote: >> src/java.naming/share/classes/javax/naming/ldap/package-info.java line 200: >> >>> 198: * if (respCtls != null) { >>> 199: * // Find the one we want >>> 200: * for (int i = 0; i < respCtls.length; i++) { >> >> This is the o

Re: RFR: 8332072: Convert package.html files in `java.naming` to package-info.java [v2]

2024-06-27 Thread Aleksei Efimov
On Wed, 26 Jun 2024 18:11:45 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 HT