doing the
copying and checking together rather than as separate loops seems to speed
things up considerably, even for happy-path of no failures.
Brett
On Sat, Feb 18, 2023 at 5:49 PM Claes Redestad
mailto:claes.redes...@oracle.com>> wrote:
Hi,
general comment: String might be one of
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
I think of this pattern of reading a to-be-lazily-initialized value into a
local as simple hygiene, `volatile` or not. The code might seem solid without
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote:
> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
> thread safe
Marked as reviewed by redestad (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/12643
Hi,
general comment: String might be one of the trickier places to add a VarHandle
dependency, since String is used very early in the bootstrap and depended upon
by everything else, so I’d expect such a solution would have to navigate
potential circularity issues carefully. It’d be good to
On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad wrote:
> During work on #12453 @schlosna reported that `array.clone()` might
> underperform `System.arraycopy` in microbenchmarks and I opted to go with
> `arraycopy` throughout while investigating.
>
> Testing on x86 (Sandy
On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad wrote:
> During work on #12453 @schlosna reported that `array.clone()` might
> underperform `System.arraycopy` in microbenchmarks and I opted to go with
> `arraycopy` throughout while investigating.
>
> Testing on x86 (Sandy
On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad wrote:
> During work on #12453 @schlosna reported that `array.clone()` might
> underperform `System.arraycopy` in microbenchmarks and I opted to go with
> `arraycopy` throughout while investigating.
>
> Testing on x86 (Sandy
During work on #12453 @schlosna reported that `array.clone()` might
underperform `System.arraycopy` in microbenchmarks and I opted to go with
`arraycopy` throughout while investigating.
Testing on x86 (SandyBridge, AVX2) I observe no difference at all between the
setups. On aarch the only
On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad wrote:
> We can improve various String methods such as `startsWith`, `endsWith` and
> `regionMatches` by leveraging the intrinsified mismatch methods in
> `ArraysSupport`.
This pull request has now been integrated.
Changeset: 861e30
On Mon, 13 Feb 2023 16:10:14 GMT, Claes Redestad wrote:
>> We can improve various String methods such as `startsWith`, `endsWith` and
>> `regionMatches` by leveraging the intrinsified mismatch methods in
>> `ArraysSupport`.
>
> Claes Redestad has updated the pull reques
On Tue, 14 Feb 2023 18:22:32 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
On Tue, 14 Feb 2023 18:22:32 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
On Tue, 14 Feb 2023 15:03:50 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2699:
>>
>>> 2697: __ addptr(dest, 0x18);
>>> 2698: __ subl(length, 0x20);
>>> 2699: __ jcc(Assembler::lessEqual, L_tailProc);
>>
>> This could be Assembler::less instead of
On Fri, 10 Feb 2023 23:18:47 GMT, Claes Redestad wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add URL to microbenchmark
>
> Marked as reviewed by redestad (Reviewer).
&g
On Mon, 13 Feb 2023 16:43:12 GMT, Eirik Bjorsnos wrote:
> Case-insensitive regionMatches could be improved by using
> ArraysSupport.mismatch to skip over long common substrings:
I considered this but saw regressions similar to what you're getting for size =
6 and backed off. I think this
On Mon, 13 Feb 2023 09:59:52 GMT, Claes Redestad wrote:
>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to
>> copy arrays more efficiently when exactly the whole input array is to be
>> copied. This helps eliminate range checks and has bee
On Tue, 7 Feb 2023 13:30:35 GMT, Claes Redestad wrote:
> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to
> copy arrays more efficiently when exactly the whole input array is to be
> copied. This helps eliminate range checks and has been verified to help
On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad wrote:
> We can improve various String methods such as `startsWith`, `endsWith` and
> `regionMatches` by leveraging the intrinsified mismatch methods in
> `ArraysSupport`.
Microbenchmarking shows decent improvements on small data, s
We can improve various String methods such as `startsWith`, `endsWith` and
`regionMatches` by leveraging the intrinsified mismatch methods in
`ArraysSupport`.
-
Commit messages:
- Remove overlapping micros, extend testing to endsWith, regionCI and some
minor improvements to
ray 7 avgt 15
> 14.666 ± 0.336 ns/op
> StringConstructor.newStringFromArrayWithCharset 7 avgt 15
> 14.582 ± 0.288 ns/op
> StringConstructor.newStringFromArrayWithCharsetName 7 avgt 15
> 20.339 ± 0.328 ns/op
Claes Redestad has upd
On Thu, 9 Feb 2023 18:08:15 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
On Thu, 9 Feb 2023 11:46:42 GMT, Eirik Bjorsnos wrote:
> > In addition to - or instead of - an `equals` shortcut then if coders are
> > the same we could use `ArraysSupport.mismatch` which should get similar
> > speed and help more generally.
>
> ..and if String had (an optimized) mismatch
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Wed, 8 Feb 2023 11:57:16 GMT, Claes Redestad wrote:
> > > Seems there's a possible real test failure lurking here, might be
> > > intermittent since it only showed on one platform:
> >
> >
> > Did you get this from GHA somehow? Do you happen to know the
On Wed, 8 Feb 2023 11:32:02 GMT, Eirik Bjorsnos wrote:
> > Seems there's a possible real test failure lurking here, might be
> > intermittent since it only showed on one platform:
>
> Did you get this from GHA somehow? Do you happen to know the platform,
> timezone and encoding used?
Yes,
On Wed, 8 Feb 2023 08:16:05 GMT, Francesco Nigro wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minimize, force inline, generalize
>
> test/micro/org/openjdk/bench/java/lang/
On Wed, 8 Feb 2023 03:38:24 GMT, David Schlosnagle wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minimize, force inline, generalize
>
> src/java.base/share/classes/java/util/Arr
ray 7 avgt 15
> 14.666 ± 0.336 ns/op
> StringConstructor.newStringFromArrayWithCharset 7 avgt 15
> 14.582 ± 0.288 ns/op
> StringConstructor.newStringFromArrayWithCharsetName 7 avgt 15
> 20.339 ± 0.328 ns/op
Claes Redestad has updated the
On Wed, 8 Feb 2023 01:10:59 GMT, David Schlosnagle wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minimize, force inline, generalize
>
> src/java.base/share/classes/java/util/Arr
ray 7 avgt 15
> 14.666 ± 0.336 ns/op
> StringConstructor.newStringFromArrayWithCharset 7 avgt 15
> 14.582 ± 0.288 ns/op
> StringConstructor.newStringFromArrayWithCharsetName 7 avgt 15
> 20.339 ± 0.328 ns/op
Claes Redestad has updated the
ray 7 avgt 15
> 14.666 ± 0.336 ns/op
> StringConstructor.newStringFromArrayWithCharset 7 avgt 15
> 14.582 ± 0.288 ns/op
> StringConstructor.newStringFromArrayWithCharsetName 7 avgt 15
> 20.339 ± 0.328 ns/op
Claes Redestad has updated the
On Tue, 7 Feb 2023 13:23:26 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Tue, 7 Feb 2023 19:10:08 GMT, Francesco Nigro wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyrights
>
> Thanks @cl4es to look into this!
@franz1981 idea seems to app
s not
> in agreement (theoretically possible if you clear/remove and call
> `trimToSize()` concurrently). Adding an explicit check here seem to be the
> right thing to do regardless of this RFE.
Claes Redestad has updated the pull request incrementally with two additional
commits si
On Tue, 7 Feb 2023 19:08:59 GMT, Francesco Nigro wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyrights
>
> src/java.base/share/classes/java/lang/String.java line 698:
&g
On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad wrote:
>> This adds a local, specialized `copyBytes` method to `String` that avoids
>> certain redundant range checks and clamping that JIT has issues removing
>> fully.
>>
>> This has a small but statistically
On Tue, 7 Feb 2023 19:24:11 GMT, Stuart Marks wrote:
> > It might be that the redundant checks in Arrays.copyOfRange would be
> > eliminated properly with more inlining, and that the issue here is that the
> > affected String constructor is particularly gnarly. This gnarliness is due
> > 1)
On Tue, 7 Feb 2023 18:35:32 GMT, John R Rose wrote:
> Our source code is a reference implementation, and people will look at this
> change as evidence that `Arrays::copyOfRange` should be hand-inlined by savvy
> coders. Surely we could also fix this small performance pothole by improving
>
s not
> in agreement (theoretically possible if you clear/remove and call
> `trimToSize()` concurrently). Adding an explicit check here seem to be the
> right thing to do regardless of this RFE.
Claes Redestad has updated the pull request incrementally with one additional
commit sin
On Tue, 7 Feb 2023 14:57:52 GMT, Alan Bateman wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update StringLatin1.trim for consistency
>
> src/java.base/share/classes/java/lang/Str
s not
> in agreement (theoretically possible if you clear/remove and call
> `trimToSize()` concurrently). Adding an explicit check here seem to be the
> right thing to do regardless of this RFE.
Claes Redestad has updated the pull request incrementally with one additional
commit
s not
> in agreement (theoretically possible if you clear/remove and call
> `trimToSize()` concurrently). Adding an explicit check here seem to be the
> right thing to do regardless of this RFE.
Claes Redestad has updated the pull request incrementally with one additional
commit since
s not
> in agreement (theoretically possible if you clear/remove and call
> `trimToSize()` concurrently). Adding an explicit check here seem to be the
> right thing to do regardless of this RFE.
Claes Redestad has updated the pull request incrementally with one additional
c
This adds a local, specialized `copyBytes` method to `String` that avoids
certain redundant range checks and clamping that JIT has issues removing fully.
This has a small but statistically significant effect on `String`
microbenchmarks, eg.:
Baseline
Benchmark
On Mon, 6 Feb 2023 16:14:14 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos wrote:
>> After finding a hash match, getEntryPos needs to compare the lookup name up
>> to the encoded entry name in the CEN. This comparison is done by decoding
>> the entry name into a String. The names can then be compared using the
>>
On Mon, 6 Feb 2023 15:14:37 GMT, Eirik Bjorsnos wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java
On Mon, 6 Feb 2023 12:01:19 GMT, Eirik Bjorsnos wrote:
>> Nice, I have updated the PR such that the new shared secret is replaced with
>> using getBytesNoRepl instead. If there is a performance difference, it seems
>> to hide in the noise.
>>
>> I had expected such a regression to be caught
On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos wrote:
> After finding a hash match, getEntryPos needs to compare the lookup name up
> to the encoded entry name in the CEN. This comparison is done by decoding the
> entry name into a String. The names can then be compared using the String
>
On Mon, 6 Feb 2023 14:27:36 GMT, Claes Redestad wrote:
>> Interesting. Would be nice to solve this in the JIT!
>>
>> This disabled code got deleted in my last commit, but it seems like you have
>> a good analysis so we can let it go now.
>
> Right. I might have
On Mon, 6 Feb 2023 11:56:22 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/System.java line 2671:
>>
>>> 2669: if (false) {
>>> 2670: // Arrays.mismatch without the range checks (~5%
>>> faster micro getEntryHit)
>>> 2671:
On Thu, 2 Feb 2023 15:33:29 GMT, Scott Gibbons wrote:
>> Names are important, but always hard to get right. At the very least they
>> need to be correct. Maybe call it something like
>> `..parameterized_decode_tables..` and the other `..shared_decode_tables..`?
>
> I prefer leaving them the
On Wed, 1 Feb 2023 20:59:24 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2202:
>>
>>> 2200: }
>>> 2201:
>>> 2202: address StubGenerator::base64_AVX2_decode_URL_tables_addr() {
>>
>> Shouldn't this be `decode_lut_tables`? As it's used for URL and non-URL
>>
On Wed, 1 Feb 2023 18:28:25 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
On Fri, 27 Jan 2023 21:36:29 GMT, Claes Redestad wrote:
>> Scott Gibbons 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 cont
On Fri, 27 Jan 2023 18:31:50 GMT, Scott Gibbons wrote:
>> Added code for Base64 acceleration (encode and decode) which will accelerate
>> ~4x for AVX2 platforms.
>>
>> Encode performance:
>> **Old:**
>>
>> Benchmark (maxNumBytes) Mode Cnt Score Error
>> Units
On Mon, 23 Jan 2023 18:14:16 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2661:
>>
>>> 2659: __ vpbroadcastq(xmm4, Address(r13, 0), Assembler::AVX_256bit);
>>> 2660: __ vmovdqu(xmm11, Address(r13, 0x28));
>>> 2661: __ vpbroadcastb(xmm10,
On Sat, 21 Jan 2023 00:15:10 GMT, Scott Gibbons wrote:
> Added code for Base64 acceleration (encode and decode) which will accelerate
> ~4x for AVX2 platforms.
>
> Encode performance:
> **Old:**
>
> Benchmark (maxNumBytes) Mode Cnt Score Error
> Units
>
On Sun, 22 Jan 2023 13:28:06 GMT, Sergey Tsypanov wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 2611:
>>
>>> 2609: "Cannot print as output of " + len + " characters
>>> exceeds pad width of " + padWidth);
>>> 2610:
On Sun, 22 Jan 2023 09:50:21 GMT, Sergey Tsypanov wrote:
>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This
>> can be reduced to O(1) improving the code like:
>>
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>> .appendLiteral("Date:")
>>
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on
> a `byte[]` subrange. It can profitably use the recently introduced
> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
>
On Fri, 20 Jan 2023 16:42:47 GMT, Lance Andersen wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Vary dir and entry name lengths across a wider spread, keeping most
>> entries shor
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on
> a `byte[]` subrange. It can profitably use the recently introduced
> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
>
/op
>
> After:
>
> Benchmark (size) Mode Cnt Score Error Units
> ZipFileOpen.openCloseZipFile 512 avgt 15 79512.902 ± 814.449 ns/op
> ZipFileOpen.openCloseZipFile 1024 avgt 15 147892.522 ± 2744.017 ns/op
Claes Redestad has updated the pull request
On Fri, 20 Jan 2023 11:25:22 GMT, Lance Andersen wrote:
>> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates
>> on a `byte[]` subrange. It can profitably use the recently introduced
>> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
>> translates
On Fri, 20 Jan 2023 11:10:13 GMT, Alan Bateman wrote:
> > FWIW the micro is derived from the sibling `ZipFileGetEntry` micro in the
> > same directory. It's not exactly necessary for this use case to add such a
> > benchmark, but I think there's value in verifying that optimizing
> >
On Thu, 19 Jan 2023 11:45:12 GMT, Claes Redestad wrote:
> Went through the jdk and found a few more places where
> `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc
> methods could be replaced with a plain call to `java.util.Arrays`
> equivalents. This pat
On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad wrote:
>> Went through the jdk and found a few more places where
>> `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc
>> methods could be replaced with a plain call to `java.util.Arrays`
>> equivalen
2077 I think we're reaching the limit of sensible
> direct use of `AS::vectorizedHashCode`. I've found a few places outside of
> java.base where `vectorizedHashCode` might be applicable, but none that seem
> important enough to warrant an export of this method outside of java.base.
Claes Re
Went through the jdk and found a few more places where
`ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc methods
could be replaced with a plain call to `java.util.Arrays` equivalents. This
patch addresses that.
After this, #12068, and #12077 I think we're reaching the
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on
> a `byte[]` subrange. It can profitably use the recently introduced
> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
>
On Wed, 18 Jan 2023 11:04:57 GMT, Claes Redestad wrote:
> This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify
> the performance win also for range-based hash calculations. Also modernized
> and cleaned up the surrounding code somewhat.
>
&g
On Wed, 18 Jan 2023 11:04:57 GMT, Claes Redestad wrote:
> This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify
> the performance win also for range-based hash calculations. Also modernized
> and cleaned up the surrounding code somewhat.
>
&g
`ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a
`byte[]` subrange. It can profitably use the recently introduced
`ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates
to a small but significant speed-up on `ZipFile` creation.
Before:
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>>
On Wed, 11 Jan 2023 13:23:44 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/util/BitSet.java line 421:
>>
>>> 419: final long bitMask = 1L << bitIndex;
>>> 420: words[wordIndex] ^= bitMask;
>>> 421: cardinality += (words[wordIndex] & bitMask) != 0 ? 1 : -1;
This patch makes use of `ArraysSupport.vectorizedHashCode` and helps verify the
performance win also for range-based hash calculations. Also modernized and
cleaned up the surrounding code somewhat.
Benchmark Mode CntScore Error Units
On Wed, 18 Jan 2023 07:32:58 GMT, Sergey Tsypanov wrote:
>> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()`
>> when we don't need a copy
>> - comparison of two lists can be done without `Stream.reduce()`
>
> Sergey Tsypanov has updated the pull request incrementally
On Tue, 17 Jan 2023 21:06:01 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make
On Tue, 17 Jan 2023 21:24:34 GMT, Sergey Tsypanov wrote:
>> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()`
>> when we don't need a copy
>> - comparison of two lists can be done without `Stream.reduce()`
>
> Sergey Tsypanov has updated the pull request incrementally
On Tue, 17 Jan 2023 20:55:08 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make
On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad wrote:
> Continuing the work initiated by @luhenry to unroll and then intrinsify
> polynomial hash loops.
>
> I've rewired the library changes to route via a single `@IntrinsicCandidate`
> method. To make this work I've
000 avgt5 9420.171 ± 44.474 ns/op
>
>
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster
> on large inputs for `char` and `int` (the ones currently vectorized). I aim
> to fix `byte` and `short` cases before integrating, though it might be
On Tue, 17 Jan 2023 18:46:00 GMT, Vladimir Ivanov wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> trailing ws
>
> src/hotspot/share/opto/machnode.cpp
000 avgt5 9420.171 ± 44.474 ns/op
>
>
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster
> on large inputs for `char` and `int` (the ones currently vectorized). I aim
> to fix `byte` and `short` cases before integrating, though it might be
&g
On Tue, 17 Jan 2023 10:11:49 GMT, Rémi Forax wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6754:
>>
>>> 6752: filter(t -> t.parameterCount() > skipSize).
>>> 6753: map(MethodType::ptypes).
>>> 6754:
On Tue, 17 Jan 2023 08:22:28 GMT, Sergey Tsypanov wrote:
> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()`
> when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`
Remove `EMPTY` (using my earlier suggestion or by simply inlining
On Tue, 17 Jan 2023 08:22:28 GMT, Sergey Tsypanov wrote:
> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()`
> when we don't need a copy
> - comparison of two lists can be done without `Stream.reduce()`
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
On Mon, 14 Nov 2022 18:28:53 GMT, Vladimir Ivanov wrote:
>>> Also, I'd like to note that C2 auto-vectorization support is not too far
>>> away from being able to optimize hash code computations. At some point, I
>>> was able to achieve some promising results with modest tweaking of
>>>
000 avgt5 9420.171 ± 44.474 ns/op
>
>
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster
> on large inputs for `char` and `int` (the ones currently vectorized). I aim
> to fix `byte` and `short` cases before integrating, though it might b
000 avgt5 9420.171 ± 44.474 ns/op
>
>
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster
> on large inputs for `char` and `int` (the ones currently vectorized). I aim
> to fix `byte` and `short` cases before integrating, though it might be
&g
On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make
On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad wrote:
> This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.
This pull request has now been integrated.
Changeset: 48c8fb39
Author: Claes Redestad
URL:
https://git.openjdk.org/jdk/com
On Wed, 11 Jan 2023 15:13:14 GMT, Claes Redestad wrote:
> This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.
Thanks for reviewing!
-
PR: https://git.openjdk.org/jdk/pull/11949
On Mon, 9 Jan 2023 16:49:25 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make
This removes `MethodHandleNatives.getMembers`, which has fallen into disuse.
-
Commit messages:
- 8299978: Remove MethodHandleNatives.getMembers
Changes: https://git.openjdk.org/jdk/pull/11949/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=11949=00
Issue:
501 - 600 of 701 matches
Mail list logo
