On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote:
> As is suggested in
> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
On Wed, 30 Oct 2024 16:31:28 GMT, Jaikiran Pai wrote:
>> @eirbjo will know for sure but I think it's intentional since if there's an
>> encoding error we'd have thrown earlier when hashing over the full name.
>
> Hello Claes,
>
>> if there's an encoding error we'd have thrown earlier when hash
On Wed, 30 Oct 2024 16:14:48 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Map versions by entry name hashcode instead of by entry name. This avoids
>> String allocation and storage
>> -
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
On Mon, 28 Oct 2024 20:51:22 GMT, Andrey Turbanov wrote:
>> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
>> reasonable or necessary flags, but when deploying and running micros we
>> often want to add or replace flags to tune to the machine, test different
>> GCs, etc.
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
On Thu, 24 Oct 2024 22:33:18 GMT, Valerie Peng wrote:
> Note the bot warning on the branch name being master. Will you change this
> following the bot's instruction? Also the minor issue with the convention of
> starting the synopsis with Upper case, i.e. "potential" -> "Potential".
I had miss
On Mon, 21 Oct 2024 18:18:12 GMT, Vladimir Ivanov wrote:
> This patch remove access to the shared variable to fix scalability issue in
> the multithread environment. According to testing by the
> specjvm2008::crypto.rsa the one thread performance reduced for less than 1%
> while the score for
Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM reasonable
or necessary flags, but when deploying and running micros we often want to add
or replace flags to tune to the machine, test different GCs, etc. The
inconsistent use of the different `jvmArgs` options make it error p
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
On Fri, 18 Oct 2024 16:02:26 GMT, Eirik Bjørsnøs wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1796:
>>
>>> 1794: if (metaVersions == null)
>>> 1795: metaVersions = new HashMap<>();
>>> 1796:
On Mon, 21 Oct 2024 18:18:12 GMT, Vladimir Ivanov wrote:
> This patch remove access to the shared variable to fix scalability issue in
> the multithread environment. According to testing by the
> specjvm2008::crypto.rsa the one thread performance reduced for less than 1%
> while the score for
On Mon, 21 Oct 2024 18:18:12 GMT, Vladimir Ivanov wrote:
> This patch remove access to the shared variable to fix scalability issue in
> the multithread environment. According to testing by the
> specjvm2008::crypto.rsa the one thread performance reduced for less than 1%
> while the score for
On Thu, 17 Oct 2024 22:32:12 GMT, Claes Redestad wrote:
>>> I guess performance leans on there being only one or a small number of
>>> versions per entry.
>>
>> I checked Spring Petclinic:
>>
>> * 109 JAR dependencies
>> * 15 are multi-releas
On Fri, 18 Oct 2024 09:31:45 GMT, Eirik Bjørsnøs wrote:
>> With this change to `ZipFileOpen`:
>>
>> diff --git a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
>> b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
>> index 4f6ae6373ec..0e22cf7f0ab 100644
>> --- a/test/m
On Fri, 18 Oct 2024 12:08:08 GMT, Eirik Bjørsnøs wrote:
>> There are a few possible strategies for avoiding that additional parse,
>> since the effect we're getting at here is to have a quick filter to avoid
>> pointless lookups and not necessarily an exact mapping.
>>
>> One is to store the `
On Fri, 18 Oct 2024 13:54:30 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which speeds up `JarFile::getEntry` lookup
>> significantly for multi-release JAR files.
>>
>> The changes in this PR are motivated by the following insights:
>>
>> * `META-INF/versions/` is sparsely populated.
>>
On Fri, 18 Oct 2024 12:34:18 GMT, Claes Redestad wrote:
>>> One is to store the `checkedHash` rather than the full `String`. This gets
>>> `openCloseZipFile` down to ~91 ns/op. (`checkedHash` very hot in
>>> profiles). There's still a chance for redu
On Thu, 17 Oct 2024 08:40:05 GMT, Eirik Bjørsnøs wrote:
>> I guess performance leans on there being only one or a small number of
>> versions per entry. Which I think is a fair assumption. Still would be good
>> to have a stress test with many entries having many versions and make sure
>> we d
On Tue, 15 Oct 2024 08:05:44 GMT, Eirik Bjørsnøs wrote:
>> Yep, looks good. And I agree with Claes' evaluation that we should not
>> complicate this construction further, especially that the result is quickly
>> garbage collected when we compile into the string to int array map.
>
> We could al
On Mon, 14 Oct 2024 19:52:50 GMT, Eirik Bjørsnøs wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1831:
>>
>>> 1829: metaVersions = new HashMap<>();
>>> 1830: for (var entry : metaVersionsMap.entrySet()) {
>>> 1831: // Conv
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 simp
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/inli
503.573 ± 0.075 3.518 ±
> 0.057 ns/op 1.02x (p = 0.044 )
> StringConcat.concatEmptyRight503.713 ± 0.049 3.622 ±
> 0.053 ns/op 1.02x (p = 0.000*)
> StringConcat.concatMethodConstString 507.418 ± 0.030 7.478 ±
>
503.573 ± 0.075 3.518 ±
> 0.057 ns/op 1.02x (p = 0.044 )
> StringConcat.concatEmptyRight503.713 ± 0.049 3.622 ±
> 0.053 ns/op 1.02x (p = 0.000*)
> StringConcat.concatMethodConstString 507.418 ± 0.030 7.478 ±
>
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
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
On Wed, 29 May 2024 09:18:51 GMT, Pavel Rappo wrote:
>> The non-constant test was added because that very bailout caused a crash.
>> The other test is actually less interesting since it'll likely be covered
>> indirectly by regular use. But as we are hiding these away this gets ever
>> more ob
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made t
On Wed, 29 May 2024 03:16:02 GMT, Chen Liang wrote:
>> In fact, if I change it to `2`, the following tests will fail:
>>
>> - `jdk/jdk/classfile/Utf8EntryTest.java`
>> - `jdk/java/util/zip/ZipCoding.java`
>> - `jdk/java/text/Format/MessageFormat/MessageRegression.java`
>
> Indeed, the actu
On Tue, 28 May 2024 19:13:30 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
>
On Tue, 28 May 2024 19:19:51 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
>
>>
On Mon, 23 Oct 2023 16:23:55 GMT, Daniel Jeliński wrote:
> Remove the hardcoded maximum heap size.
>
> Verified that the benchmark now passes with 100 threads given sufficient heap:
>
> make test TEST=micro:CacheBench MICRO="OPTIONS=-t 100;JAVA_OPTIONS=-Xmx16g"
Marked as reviewed by redestad (
On Tue, 17 Oct 2023 10:42:59 GMT, Shaojin Wen wrote:
>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
>> use try...catch to handle CharacterCodingException and throw
>> IllegalArgumentException instead of CharacterCodingException to make the
>> calling code cleane
On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix from @liach 's review
>
> The thrown CCE was intended for `Files.readString` and `Files.writeString`,
> and is in rea
On Tue, 12 Sep 2023 17:23:00 GMT, 温绍锦 wrote:
>> improve date toString performance, includes:
>>
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> 温绍锦 has u
On Tue, 12 Sep 2023 13:10:42 GMT, 温绍锦 wrote:
>> Of course, the optimization of DateTimeFormatter is more general, and we can
>> spend time doing it later. The format of toString is fixed, we can not use
>> DateTimeFormatter.
>
>> Have you considered potentially more generalizable optimizations
On Mon, 11 Sep 2023 16:13:01 GMT, 温绍锦 wrote:
>> It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)`
>> from line 2188.
>
> The reason for not using off++ is that it can be executed out of order, which
> may result in better performance.
I don't think that would outweig
On Tue, 12 Sep 2023 13:27:29 GMT, 温绍锦 wrote:
>> java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are
>> duplicates, We need to move
>> java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the
>> jdk.internal.util package, and modify these classes to public class, so
On Tue, 12 Sep 2023 13:24:56 GMT, 温绍锦 wrote:
> I prefer to use little endian, most environments are little endian. Changes
> to HexDigit will have to wait until #PR 14745 is merged.
I don't have a very strong opinion except that we should be consistent across
these related implementations. If
On Tue, 12 Sep 2023 10:11:53 GMT, Claes Redestad wrote:
> If there's no significant performance difference I would prefer if we kept
> `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most
> - and adjust code depending on `DecimalDigits::digitPair` to
On Tue, 12 Sep 2023 01:00:39 GMT, 温绍锦 wrote:
>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>>
>> We can reduce duplication through JavaLangAccess, whic
On Mon, 11 Sep 2023 18:58:56 GMT, Roger Riggs wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> revert code format
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1:
>
>> 1: /*
>
> Can git be convi
On Mon, 11 Sep 2023 15:57:22 GMT, 温绍锦 wrote:
>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>>
>> We can reduce duplication through JavaLangAccess, whic
On Mon, 11 Sep 2023 14:38:28 GMT, 温绍锦 wrote:
>> src/java.base/share/classes/java/time/LocalDate.java line 2181:
>>
>>> 2179: if (yearAbs < 1000) {
>>> 2180: if (year < 0) {
>>> 2181: buf[off] = '-';
>>
>> `buf[off++] = '-';`
>
> this place doesn't need off++
On Mon, 11 Sep 2023 12:12:17 GMT, 温绍锦 wrote:
> improve date toString performance, includes:
>
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString
As @liach says this
On Mon, 11 Sep 2023 08:49:18 GMT, Andrey Turbanov wrote:
>> 温绍锦 has updated the pull request incrementally with two additional commits
>> since the last revision:
>>
>> - remove duplicate stringSize
>> - update related comments
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.j
On Sun, 10 Sep 2023 18:08:44 GMT, Roger Riggs wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> move java.util.DecimalDigits to jdk.internal.util.DecimalDigits
>
> src/java.base/share/classes/java/util/Digits.java line 36:
>
On Sun, 10 Sep 2023 16:15:01 GMT, 温绍锦 wrote:
> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>
> We can reduce duplication through JavaLangAccess, which is
On Fri, 28 Jul 2023 19:23:26 GMT, Mark Powers wrote:
>> `tmp` will not be null. `GetIntegerAction.privilegedGetProperty()` will
>> return the default value when jdk.jar.maxSignatureFileSize=null
>
> You're right. Didn't look close enough.
Might make sense to declare `tmp` as an `int` to avoid f
On Wed, 24 May 2023 16:17:14 GMT, Andrew Haley wrote:
>> This provides a solid speedup of about 3-4x over the Java implementation.
>>
>> I have a vectorized version of this which uses a bunch of tricks to speed it
>> up, but it's complex and can still be improved. We're getting close to ramp
>
On Wed, 24 May 2023 11:08:31 GMT, Andrew Haley wrote:
>> No, it doesn't break the invariants.
>>
>> R is the randomly-chosen 128-bit key. It is generated from an initial
>> 128-bit-log string of random bits, then
>> `r &= 0x0ffc0ffc0ffc0fff`
>>
>> This 128-bit-long string is sp
On Wed, 24 May 2023 09:25:06 GMT, Andrew Haley wrote:
>> This provides a solid speedup of about 3-4x over the Java implementation.
>>
>> I have a vectorized version of this which uses a bunch of tricks to speed it
>> up, but it's complex and can still be improved. We're getting close to ramp
>
t;>
>> 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, 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 met
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
>> String
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
>> String
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
>> String
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
>> String
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
>> String
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
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, cli
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
>> String
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
>> String
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
>> String
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
>> String
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 l
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 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
> AP
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 by
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 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
> tra
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
> tra
/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 to
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
> > `checkedH
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.
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 limit
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
> tra
`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:
Ben
On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad wrote:
> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously
> rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a
> (capturing) lambda. Since this is called during early bootstrap this shows u
On Tue, 20 Sep 2022 11:19:07 GMT, Claes Redestad wrote:
> [JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously
> rewrote an anonymous class in `SecureClassLoader.getProtectionDomain` to a
> (capturing) lambda. Since this is called during early bootstrap this shows u
[JDK-8285263](https://bugs.openjdk.org/browse/JDK-8285263) innocuously rewrote
an anonymous class in `SecureClassLoader.getProtectionDomain` to a (capturing)
lambda. Since this is called during early bootstrap this shows up as a
regression across the board on all our startup and footprint tests.
On Thu, 16 Jun 2022 15:35:04 GMT, Claes Redestad wrote:
> - Reduce forks, iteration, runtime to reduce runtime while maintaining high
> data quality on typical benchmarking hosts.
>
> Reduces runtime from estimated 10+ hours to 54 minutes.
This pull request has now been integrated
On Tue, 19 Jul 2022 20:55:54 GMT, David Schlosnagle wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Copyrights, apply consistent settings to PermissionsImplies
>
> test/micro/o
> - Reduce forks, iteration, runtime to reduce runtime while maintaining high
> data quality on typical benchmarking hosts.
>
> Reduces runtime from estimated 10+ hours to 54 minutes.
Claes Redestad has updated the pull request incrementally with one additional
commit since the l
On Fri, 17 Jun 2022 12:24:50 GMT, Claes Redestad wrote:
>> - Reduce forks, iteration, runtime to reduce runtime while maintaining high
>> data quality on typical benchmarking hosts.
>>
>> Reduces runtime from estimated 10+ hours to 54 minutes.
>
> Claes Redesta
> - Reduce forks, iteration, runtime to reduce runtime while maintaining high
> data quality on typical benchmarking hosts.
>
> Reduces runtime from estimated 10+ hours to 54 minutes.
Claes Redestad has updated the pull request incrementally with one additional
commit since the l
On Thu, 16 Jun 2022 21:56:40 GMT, Hai-May Chao wrote:
> Looks good. Would you also consider to apply the same value or iteration to
> PermissionsImplies.java and javax/crypto/Crypto.java? The copyright year for
> some of the Oracle files in this PR can be changed to 2022. Thanks!
Fixed copyrig
- Reduce forks, iteration, runtime to reduce runtime while maintaining high
data quality on typical benchmarking hosts.
Reduces runtime from estimated 10+ hours to 54 minutes.
-
Commit messages:
- Reduce runtime of java.security microbenchmarks
Changes: https://git.openjdk.org/jdk
94 matches
Mail list logo
