https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved
Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks
when copying the entire array, but it's resulted in a few lurking footprint
benchmark issues that come down to incurring slightly more JIT activity.
On Mon, 20 Feb 2023 17:03:33 GMT, Peter Levart wrote:
>> We don't fear calling the factory twice for benign races, as the distinct
>> constructor factory instances are behaviorally the same.
>>
>> The true issue lies in the double getfield operations: Java memory model
>> doesn't require the
On Wed, 17 May 2023 09:19:10 GMT, Raffaello Giulietti
wrote:
>> When appropriate and useful, copies only the relevant portion of the
>> `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request with a new target base due
> to a merge or a rebase. The incremental
On Tue, 9 May 2023 19:13:42 GMT, Eric Caspole wrote:
>> These micros were developed while investigating JDK-8305670 by myself and
>> Sergey Kuksenko. The order of thread creation was important in that bug, so
>> there are 2 JMH for creating sleepers before and after the worker threads.
>
>
On Tue, 16 May 2023 15:17:13 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java
>> line 83:
>>
>>> 81: vtis = new
>>> VerificationTypeInfo[methodType.parameterCount()];
>>> 82: }
>>> 83: for(var arg :
On Tue, 16 May 2023 08:17:02 GMT, Adam Sotona wrote:
>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is
On Thu, 11 May 2023 09:22:44 GMT, Raffaello Giulietti
wrote:
>> When appropriate and useful, copies only the relevant portion of the
>> `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
On Mon, 15 May 2023 14:34:13 GMT, Adam Sotona wrote:
>> I have to side with @liach here: `LinkedList` iteration is significantly
>> slower than `ArrayList` even though the computational complexity is
>> identical. Often by an integer factor. This is due to the sparseness of the
>> linked list
On Fri, 12 May 2023 13:19:44 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed jmh benchmark parameters
>
> test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 57:
>
>> 55:
On Wed, 10 May 2023 09:55:13 GMT, Adam Sotona wrote:
>> That seems misplaced. Please file an RFE to have this cleaned up.
>>
>> Each microbenchmark that has to add opens needs to take responsibility for
>> that themselves and not change the environment for everything else. And all
>> micros
On Tue, 9 May 2023 16:08:57 GMT, Chen Liang wrote:
>> To make this runnable without manually adding a bunch of `--add-opens` flags
>
> They are added in the `make/RunTests.gmk`:
>
On Tue, 9 May 2023 16:09:14 GMT, Adam Sotona wrote:
>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching
On Tue, 9 May 2023 15:50:30 GMT, Claes Redestad wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed StackMapGenerator
>
> test/micro/org/openjdk/bench/jdk/classfile/RebuildMetho
On Fri, 21 Apr 2023 17:45:50 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 Thu, 20 Apr 2023 15:05:18 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 Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie wrote:
> > Why isn't `Enum::hashCode` simply doing `return ordinal;`?
>
> See https://bugs.openjdk.org/browse/JDK-8050217
Thanks! If there are apps where `Enum::hashCode` is performance sensitive then
run-to-run stability may be a stronger
On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie wrote:
>> Improve the speed of Enum.hashCode by caching the identity hashcode on first
>> use. I've seen an application where Enum.hashCode is a hot path, and this is
>> fairly simple speedup. The memory overhead is low; in enums with no extra
On Mon, 17 Apr 2023 13:23:35 GMT, olivergillespie wrote:
>> Improve the speed of Enum.hashCode by caching the identity hashcode on first
>> use. I've seen an application where Enum.hashCode is a hot path, and this is
>> fairly simple speedup. The memory overhead is low; in enums with no extra
On Mon, 27 Mar 2023 18:37:12 GMT, Jim Laskey wrote:
>> Add the ability to repeatedly append char and CharSequence data to
>> StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use Arrays.fill
Looks
On Mon, 27 Mar 2023 18:37:12 GMT, Jim Laskey wrote:
>> Add the ability to repeatedly append char and CharSequence data to
>> StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use Arrays.fill
On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan wrote:
>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk
>> operations when the argument is also a `EnumSet`, but there is no such
>> optimization for wrapper sets (returned by `Collections.unmodifiableSet`,
>>
On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan wrote:
>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk
>> operations when the argument is also a `EnumSet`, but there is no such
>> optimization for wrapper sets (returned by `Collections.unmodifiableSet`,
>>
On Wed, 15 Mar 2023 12:07:12 GMT, Sergey Tsypanov wrote:
>> src/java.base/share/classes/java/lang/CharacterData.java line 72:
>>
>>> 70:
>>> 71: static final CharacterData of(int ch) {
>>> 72: if (ch >= 0 && ch <= 0xFF) { // fast-path
>>
>> Maybereducing to a single branch
On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos wrote:
> By avoiding a bit shift operation for the latin1 fast-path test, we can speed
> up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>
> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace
On Fri, 3 Mar 2023 19:04:22 GMT, Jim Laskey wrote:
>> Add the ability to repeatedly append char and CharSequence data to
>> StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Expand test for
s
>>
>> I assume “iff” should “if”?
>
> Here and elsewhere in this file "iff" might mean [if and only
> if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense.
> (FWIW, there are a few hundred occurrences of the word "iff" in src.)
>
>
On Thu, 23 Feb 2023 08:32:29 GMT, Claes Redestad wrote:
>> `Charset` class is initialized *before* system properties are set up, in
>> order to check the JNU encoding (used for file path name) is a supported
>> charset or not. In some OS environments, GB18030 is the native
On Wed, 22 Feb 2023 17:52:01 GMT, Naoto Sato wrote:
>>> curious - what scenario triggers this call at initLevel < 1 ?
>>
>> It's not supported, but it is possible that someone might run with
>> -Dfile.encoding=GB18030, in which case the default charset is used before
>> the system properties
On Wed, 22 Feb 2023 07:11:16 GMT, Eirik Bjorsnos wrote:
>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
>> 'the oldest ASCII trick in the book'.
>>
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
>> latin1 bytes for equality ignoring
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
&g
On Mon, 20 Feb 2023 21:40:41 GMT, Brett Okken wrote:
>> When encoding Strings to US-ASCII we can speed up the happy path
>> significantly by using `StringCoding.countPositives` as a speculative check
>> for whether there are any chars that needs to be replaced by `'?'`. Once a
>> non-ASCII
On Tue, 21 Feb 2023 11:14:13 GMT, Eirik Bjorsnos wrote:
>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
>> 'the oldest ASCII trick in the book'.
>>
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
>> latin1 bytes for equality ignoring
On Tue, 21 Feb 2023 06:59:47 GMT, Eirik Bjorsnos wrote:
>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase
>> for latin1 code points by applying the 'oldest ASCII trick in the book'.
>>
>> This takes advantage of the fact that latin1 uppercase code points are
>>
On Mon, 20 Feb 2023 16:16:45 GMT, Eirik Bjorsnos wrote:
>> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line
>> 170:
>>
>>> 168: * @return true if the two bytes are considered equals ignoring
>>> case in latin1
>>> 169: */
>>> 170: static boolean
On Mon, 20 Feb 2023 14:45:09 GMT, Eirik Bjorsnos wrote:
>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
>> 'the oldest ASCII trick in the book'.
>>
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
>> latin1 bytes for equality ignoring
RFE filed: https://bugs.openjdk.org/browse/JDK-8302877
/Claes
17 feb. 2023 kl. 18:38 skrev Eirik Bjørsnøs
mailto:eir...@gmail.com>>:
Hi,
The following PR suggests we can speed up Character.toUpperCase and
Character.toLowerCase for latin1 code points by applying 'the oldest ASCII
trick in
RFE filed: https://bugs.openjdk.org/browse/JDK-8302871
/Claes
18 feb. 2023 kl. 10:28 skrev Eirik Bjørsnøs
mailto:eir...@gmail.com>>:
Hi,
The following PR suggests we can speed up StringLatin1.regionMatchesCI by
applying 'the oldest ASCII trick in the book':
RFE filed: https://bugs.openjdk.org/browse/JDK-8302872
/Claes
18 feb. 2023 kl. 19:58 skrev Eirik Bjørsnøs
mailto:eir...@gmail.com>>:
Hi,
This PR continues the effort to speed up case-insensitive string comparisons,
this time tackling comparison of latin1-coded strings with utf16-coded
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
&g
On Sun, 19 Feb 2023 07:24:30 GMT, David Schlosnagle wrote:
>> When encoding Strings to US-ASCII we can speed up the happy path
>> significantly by using `StringCoding.countPositives` as a speculative check
>> for whether there are any chars that needs to be replaced by `'?'`. Once a
>>
When encoding Strings to US-ASCII we can speed up the happy path significantly
by using `StringCoding.countPositives` as a speculative check for whether there
are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is
encountered we fall back to the slow loop and replace as
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
501 - 600 of 742 matches
Mail list logo
