Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]

2024-05-25 Thread Daniel Jeliński
On Fri, 24 May 2024 18:37:13 GMT, Vladimir Kozlov wrote: >> Changed to `lea` with `InternalAddress()`. Generates the exact same code, >> but makes more sense. I looked at `movdqu` and see no code that generates >> RIP-relative loads. It merely checks `reachable()` and adds an intermediate >

Re: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist

2024-05-25 Thread Alan Bateman
On Sun, 26 May 2024 06:06:50 GMT, Daniel Jeliński wrote: > SkippedException works with jtreg tests only. For jUnit you need to use > [Assumptions.abort](https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html#abort(java.lang.String)) Yes, the Assumpt

Re: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist

2024-05-25 Thread Daniel Jeliński
On Sun, 26 May 2024 02:58:02 GMT, SendaoYan wrote: > Hi all, > When there is no `/usr/bin/expect` in system, `throw new SkippedException` > will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause > this testcase run failed. So I make change from `throw new SkippedExceptio

Re: RFR: 8327858: Improve spliterator and forEach for single-element immutable collections [v3]

2024-05-25 Thread Chen Liang
On Fri, 26 Apr 2024 22:27:21 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 collect

RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist

2024-05-25 Thread SendaoYan
Hi all, When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `System.exit` to avoid this issue. When use `System.ex

Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]

2024-05-25 Thread Scott Gibbons
> Re-write the IndexOf code without the use of the pcmpestri instruction, only > using AVX2 instructions. This change accelerates String.IndexOf on average > 1.3x for AVX2. The benchmark numbers: > > > BenchmarkScore > Latest

Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v42]

2024-05-25 Thread Scott Gibbons
> Re-write the IndexOf code without the use of the pcmpestri instruction, only > using AVX2 instructions. This change accelerates String.IndexOf on average > 1.3x for AVX2. The benchmark numbers: > > > BenchmarkScore > Latest

Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]

2024-05-25 Thread Scott Gibbons
On Fri, 24 May 2024 23:04:55 GMT, Sandhya Viswanathan wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp > > src/hotspot/cpu/x86/c2_stubGenerator_

Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v41]

2024-05-25 Thread Scott Gibbons
On Sat, 25 May 2024 00:15:03 GMT, Sandhya Viswanathan wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix test; review comments > > src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 316: > >> 314: //

Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

2024-05-25 Thread Chen Liang
Did you reorder the field in picocli.CommandLine$Command? In class 13 the usageHelpWidth was preceded by versionProvider, in class 9 it's preceded by requiredOptionMarker. It would also be helpful if you can provide the bytecode for Command class, as it might be due to method ordering in reflection

Re: RFR: 8322732: ForkJoinPool may underutilize cores in async mode [v5]

2024-05-25 Thread Doug Lea
> This set of changes address causes of poor utilization with small numbers of > cores due to overly aggressive contention avoidance. A number of further > adjustments were needed to still avoid most contention effects in deployments > with large numbers of cores Doug Lea has updated the pull r