On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov wrote:
> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use
> single call `HashMap.getOrDefault`.
> It's faster and clearer.
Marked as reviewed by redestad (Reviewer).
-
PR: https://git.openjdk.java.net/jd
On Wed, 30 Mar 2022 16:08:15 GMT, Brian Burkhalter wrote:
> Looks all right assuming tests pass.
Thanks! Tier1+2 testing passed.
-
PR: https://git.openjdk.java.net/jdk/pull/8039
A few integer divisions and multiplications can be replaced with test +
addition, leading to a decent speed-up on java.time microbenchmarks such as
`GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up
on aarch64 and other x86 setups.
Baseline:
Benchmark
On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote:
> This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset`
> (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.
This pull request has now been integrated.
Changeset: 0e788e0e
Author: Claes Re
On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote:
> This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset`
> (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.
Thanks for reviews!
-
PR: https://git.openjdk.java.net/jdk/pull/7990
This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset`
(and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.
-
Commit messages:
- Merge branch 'master' into lastRulesCache
- Avoid allocating unused lastRulesCaches
Changes: https://git.openjdk.jav
On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad wrote:
> A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
> aligning the implementation with changes explored by the TemplatedStrings JEP
> and ever so slightly improving performance:
>
> - turn `Flag
On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad wrote:
> A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
> aligning the implementation with changes explored by the TemplatedStrings JEP
> and ever so slightly improving performance:
>
> - turn `Flag
On Wed, 15 Dec 2021 20:09:22 GMT, Roger Riggs wrote:
>> A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
>> aligning the implementation with changes explored by the TemplatedStrings
>> JEP and ever so slightly improving performance:
>>
>> - turn `Flags` into an `int` (f
A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
aligning the implementation with changes explored by the TemplatedStrings JEP
and ever so slightly improving performance:
- turn `Flags` into an `int` (fewer allocations in the complex case)
- remove some superfluous vararg
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote:
> This changes the specification of `DateTimeFormatterBuilder.appendFraction`
> to more clearly specify that the formatter will throw an exception if you
> attempt to print a value outside of the value range of the given field.
On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad wrote:
> This changes the specification of `DateTimeFormatterBuilder.appendFraction`
> to more clearly specify that the formatter will throw an exception if you
> attempt to print a value outside of the value range of the given field.
This changes the specification of `DateTimeFormatterBuilder.appendFraction` to
more clearly specify that the formatter will throw an exception if you attempt
to print a value outside of the value range of the given field. Changes
suggested by @jodastephen in #6188.
-
Commit message
On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap,
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, witho
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Remove accidentally committed experimental @Stable (no effect on micros)
-
Cha
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Copyrights
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6188/files
-
On Wed, 3 Nov 2021 18:17:38 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor cleanup
>
> test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.jav
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Add MICRO_OF_SECOND tests to retain proper coverage of FractionPrinterParser
-
Cha
On Wed, 3 Nov 2021 17:33:36 GMT, Naoto Sato wrote:
> Looks good. I'd create a new test case class out of
> `TestFractionPrinterParser`, as you introduced the new `NanosPrinterParser`.
It was only indirectly a test of `FractionPrinterParser`; it's really a test of
`PrinterParsers` built using `
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Minor cleanup
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6188/
On Wed, 3 Nov 2021 14:24:28 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add test verifying OOB values throw exception
>
> Thanks for adding the new te
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Add test verifying OOB values throw exception
-
Changes:
- all:
On Wed, 3 Nov 2021 12:44:39 GMT, Claes Redestad wrote:
>> I'll see to it.
>
> When adding a test for this I discovered that
> `FractionPrinterParser::format` will end up calling
> `field.range().checkValidValue(value, field)`
> [here](https://g
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
FractionPrinterParser checks values to be in range; NanosPrinterParser should
do the same
On Wed, 3 Nov 2021 12:21:00 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3266:
>>
>>> 3264: if (!field.range().isValidIntValue(value)) {
>>> 3265:
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Single-check idiom
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6188/
On Wed, 3 Nov 2021 11:53:52 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add fallback for values outside the allowable range
>
> src/java.base/
On Wed, 3 Nov 2021 12:04:10 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add fallback for values outside the allowable range
>
> src/java.base/
On Tue, 2 Nov 2021 07:31:09 GMT, Stephen Colebourne
wrote:
>> I see what you're saying that an arbitrary `Temporal` could define its own
>> fields with its own ranges, but I would consider it a design bug if such an
>> implementation at a whim redefines the value ranges of well-defined
>> con
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Add fallback for values outside the allowable range
-
Changes:
- all:
On Mon, 1 Nov 2021 22:27:08 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3269:
>>
>>> 3267: return false;
>>> 3268: }
>>> 3269: int val = va
in performance by specializing some common
> patterns.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Remove stray method
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6188/
On Mon, 1 Nov 2021 22:18:52 GMT, Stephen Colebourne
wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> hav
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why
> DataTimeFormatters are much less efficient for some common patterns than
> custom formatters in apache-commons and log4j. This patch address some of
> that
Prompted by a request from Volkan Yazıcı I took a look at why
DataTimeFormatters are much less efficient for some common patterns than custom
formatters in apache-commons and log4j. This patch address some of that gap,
without having looked at the third party implementations.
When printing tim
On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo wrote:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
LGTM, but please use `static final`
src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
> 246:
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote:
> Enhance ASCII-compatible `DoubleByte` encodings to make use of the
> `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
> `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
> en
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote:
> Enhance ASCII-compatible `DoubleByte` encodings to make use of the
> `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
> `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
> en
Enhance ASCII-compatible `DoubleByte` encodings to make use of the
`StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
`CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
encoders - and also more in line with how well these charsets behave when
calling
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
> C-style array declarations generate noisy warnings in IDEs, et.c. This patch
> cleans up all java.* packages.
>
> (Copyrights intentionally not updated due the triviality of most changes)
Thanks for reviewing, Dan
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
> C-style array declarations generate noisy warnings in IDEs, et.c. This patch
> cleans up all java.* packages.
>
> (Copyrights intentionally not updated due the triviality of most changes)
This pull request has now bee
C-style array declarations generate noisy warnings in IDEs, et.c. This patch
cleans up all java.* packages.
(Copyrights intentionally not updated due the triviality of most changes)
-
Commit messages:
- Avoid C-style array declarations in java packages
Changes: https://git.openjdk
On Mon, 2 Aug 2021 12:29:00 GMT, Сергей Цыпанов
wrote:
>> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double`
>> and `Float` in their implementations of `Object.toString()` delegate to own
>> utility `toString(primitive)` methods.
>>
>> Unlike those, `Boolean`, `Byte`, `
On Mon, 26 Jul 2021 08:27:20 GMT, Сергей Цыпанов
wrote:
>> After I've renamed remove branch GitHub for some reason has closed original
>> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
>
> Сергей Цыпанов has updated the pull request with a new target base due to a
>
On Mon, 26 Jul 2021 08:27:14 GMT, Сергей Цыпанов
wrote:
>> There is a few JDK classes duplicating the contents of Long.hashCode() for
>> hash code calculation. They should explicitly delegate to Long.hashCode().
>
> Сергей Цыпанов has updated the pull request with a new target base due to a
>
On Sun, 4 Jul 2021 21:35:31 GMT, Сергей Цыпанов
wrote:
>> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double`
>> and `Float` in their implementations of `Object.toString()` delegate to own
>> utility `toString(primitive)` methods.
>>
>> Unlike those, `Boolean`, `Byte`, `
On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad wrote:
> I'm not exactly sure what I intended to say in this partial comment. Removing
> it.
This pull request has now been integrated.
Changeset: 9df6cc7c
Author:Claes Redestad
URL:
https://git.openjdk.java.net
I'm not exactly sure what I intended to say in this partial comment. Removing
it.
-
Commit messages:
- Incomplete comment in build.tools.generatecharacter.GenerateCharacter
Changes: https://git.openjdk.java.net/jdk/pull/3766/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk
On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt
wrote:
> Additional changes found in `java.base` of `final private` -> `private
> final`. Filed with existing bug because it's the same module; can change to a
> different bug number if required.
Marked as reviewed by redestad (Reviewer).
--
On Fri, 19 Mar 2021 18:31:02 GMT, Naoto Sato wrote:
>> Additional changes found in `java.base` of `final private` -> `private
>> final`. Filed with existing bug because it's the same module; can change to
>> a different bug number if required.
>
> Marked as reviewed by naoto (Reviewer).
Can't
On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato wrote:
> Fixed several broken links to Unicode.org.
Marked as reviewed by redestad (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3093
On Thu, 18 Mar 2021 17:02:57 GMT, Alex Blewitt
wrote:
>> Sonar displays a warning message that modifiers should be declared in the
>> order listed in the JLS; specifically, that isntead of using `final static`
>> the `static final` should be preferred.
>>
>> This fixes the issues in the `java
On Thu, 18 Mar 2021 17:06:04 GMT, Alex Blewitt
wrote:
>>> If I have other fixes for different modules, should I file PRs with the
>>> same bug number e.g. "8263658: Use the blessed modifier order in
>>> java.logging/java.desktop" or should we have separate bug numbers for them?
>>
>> Separate
On Thu, 18 Mar 2021 16:51:35 GMT, Alex Blewitt
wrote:
> If I have other fixes for different modules, should I file PRs with the same
> bug number e.g. "8263658: Use the blessed modifier order in
> java.logging/java.desktop" or should we have separate bug numbers for them?
Separate bug numbers
On Thu, 18 Mar 2021 16:42:39 GMT, Alex Blewitt
wrote:
>> Yeah, I agree.
>
> Is that there to indicate a placeholder value that was once used and is kept
> for documentation purposes? Should the corresponding JavaDoc be removed as
> well? Should I do this in the same commit/PR as this one, or s
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt
wrote:
> Sonar displays a warning message that modifiers should be declared in the
> order listed in the JLS; specifically, that isntead of using `final static`
> the `static final` should be preferred.
>
> This fixes the issues in the `java.base
On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad wrote:
> This patch changes the otherLowercase / otherUppercase bits to be set if
> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the
> Unicode Other_Lowercase / Other_Uppercase property is set. This simplifi
to a single table lookup,
> which appears to be healthy for performance.
>
> I also took the opportunity to clean up the somewhat dated GenerateCharacter
> utility class.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
This patch changes the otherLowercase / otherUppercase bits to be set if either
the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode
Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup
in Character.isLowerCase/isUpperCase to a single table look
On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad wrote:
> This patch changes the otherLowercase / otherUppercase bits to be set if
> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the
> Unicode Other_Lowercase / Other_Uppercase property is set. This simplifi
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.io`,
> `java.math`, and `java.text` packages to make use of the `instanceof` pattern
> variable?
>
> Kind regards,
> Patrick
Marked as reviewed by redes
On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad wrote:
> This patch refactors Locale.getDefault(Category) so that the volatile field
> holding the Locale is typically only read once. This has a small performance
> advantage, and might be more robust if initialization is racy.
On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad wrote:
> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase
> methods. It also exploits the fact that isOtherUppercase is always false for
> all codepoints in the CharacterDataLatin1 range for a small speed-up.
&g
: core-libs-dev on behalf of Sergey
Bylokhov
Sent: Saturday, March 6, 2021 9:39:07 PM
To: core-libs-...@openjdk.java.net ;
i18n-dev@openjdk.java.net
Subject: Re: RFR: 8263090: Avoid reading volatile fields twice in
Locale.getDefault(Category) [v2]
On Sat, 6 Mar 2021 13:34:14 GMT, Claes Re
On Sat, 6 Mar 2021 05:51:17 GMT, Sergey Bylokhov wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix omitted synchronized
>
> src/java.base/share/classes/java/util/L
On Sat, 6 Mar 2021 12:36:02 GMT, David Holmes wrote:
> If I read the order right your benchmark findings were done before you added
> the missing synchronized - correct?
>
> AFAICS the only unnecessary volatile read is on the return statement and you
> could fix that without doing the other re
On Fri, 5 Mar 2021 17:29:16 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix omitted synchronized
>
> src/java.base/share/classes/java/util/Locale.java lin
> This patch refactors Locale.getDefault(Category) so that the volatile field
> holding the Locale is typically only read once. This has a small performance
> advantage, and might be more robust if initialization is racy.
Claes Redestad has updated the pull request incrementally
On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad wrote:
> This patch refactors Locale.getDefault(Category) so that the volatile field
> holding the Locale is typically only read once. This has a small performance
> advantage, and might be more robust if initialization is racy.
Resul
This patch refactors Locale.getDefault(Category) so that the volatile field
holding the Locale is typically only read once. This has a small performance
advantage, and might be more robust if initialization is racy.
-
Commit messages:
- Add microbenchmark
- Reduce volatile reads i
This patch removes the CharacterData.isOtherUppercase and isOtherLowercase
methods. It also exploits the fact that isOtherUppercase is always false for
all codepoints in the CharacterDataLatin1 range for a small speed-up.
I have no means to test if this is correct on PPC, which has intrinsics fo
On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad wrote:
> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase
> methods. It also exploits the fact that isOtherUppercase is always false for
> all codepoints in the CharacterDataLatin1 range for a small speed-up.
&g
On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad wrote:
> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB,
> ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than
> per-instance auxiliary decoders. Doing so reduce overheads o
On Wed, 10 Feb 2021 23:38:51 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add comment about removing the generic ISO2022.Decoder
>
> Thanks. The newly added
022_KR`, so folding it into
> that implementation and simplifying the code brings a rather significant
> speed-up, both to decoder creation and on actual decoding.
>
> Testing: tier1-3, manual runs of sun.nio.cs tests
Claes Redestad has updated the pull request incrementally with one add
022_KR`, so folding it into
> that implementation and simplifying the code brings a rather significant
> speed-up, both to decoder creation and on actual decoding.
>
> Testing: tier1-3, manual runs of sun.nio.cs tests
Claes Redestad has updated the pull request incrementally with one add
On Tue, 9 Feb 2021 19:18:04 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review fixes
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.
On Tue, 9 Feb 2021 19:19:18 GMT, Naoto Sato wrote:
>> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB,
>> ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than
>> per-instance auxiliary decoders. Doing so reduce overheads of calling
>> `charset.newDecoder
On Tue, 9 Feb 2021 19:14:09 GMT, Naoto Sato wrote:
>> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB,
>> ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than
>> per-instance auxiliary decoders. Doing so reduce overheads of calling
>> `charset.newDecoder
This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB,
ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than
per-instance auxiliary decoders. Doing so reduce overheads of calling
`charset.newDecoder()`. This reduce or eliminate regressions on `new
String(byte[],
On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad wrote:
> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB,
> ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than
> per-instance auxiliary decoders. Doing so reduce overheads o
On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote:
> This patch refactor JDK internal charsets to initialize charset mapping data
> lazily when needed via holder classes. This means both a startup improvement
> in some cases, and possible throughput improvements for all DoubleB
On Mon, 8 Feb 2021 17:40:00 GMT, Naoto Sato wrote:
>> This patch refactor JDK internal charsets to initialize charset mapping data
>> lazily when needed via holder classes. This means both a startup improvement
>> in some cases, and possible throughput improvements for all DoubleByte-based
>>
On Sun, 7 Feb 2021 19:44:41 GMT, Johannes Kuhn wrote:
>> This patch refactor JDK internal charsets to initialize charset mapping data
>> lazily when needed via holder classes. This means both a startup improvement
>> in some cases, and possible throughput improvements for all DoubleByte-based
On Mon, 8 Feb 2021 11:42:23 GMT, Сергей Цыпанов
wrote:
>> This patch refactor JDK internal charsets to initialize charset mapping data
>> lazily when needed via holder classes. This means both a startup improvement
>> in some cases, and possible throughput improvements for all DoubleByte-based
On Mon, 8 Feb 2021 08:36:21 GMT, Alan Bateman wrote:
>> This patch refactor JDK internal charsets to initialize charset mapping data
>> lazily when needed via holder classes. This means both a startup improvement
>> in some cases, and possible throughput improvements for all DoubleByte-based
>
On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote:
> This patch refactor JDK internal charsets to initialize charset mapping data
> lazily when needed via holder classes. This means both a startup improvement
> in some cases, and possible throughput improvements for all DoubleB
This patch refactor JDK internal charsets to initialize charset mapping data
lazily when needed via holder classes. This means both a startup improvement in
some cases, and possible throughput improvements for all DoubleByte-based
Charsets.
Testing: tier1-3
-
Commit messages:
- M
Hi Naoto,
thanks for reviewing!
/Claes
On 2019-06-01 02:23, naoto.s...@oracle.com wrote:
Hi Claes,
Looks good to me. Thanks for catching this on so quickly!
Naoto
On 5/31/19 5:13 PM, Claes Redestad wrote:
Hi,
recent Unicode 12.1 updates caused a noticeable regression to Mac OS X
build
Hi,
recent Unicode 12.1 updates caused a noticeable regression to Mac OS X
build times.
Quoting Naoto:
"The regression was caused by the call to Grapheme.nextBoundary() in
NFCCharProperty.match() method, which got slower with the fix to
JDK-8221431 / JDK-8222978 (Unicode 12.1 / Grapheme 12.0 sup
Hi Rachna,
On 2018-05-04 10:59, Rachna Goel wrote:
Hi,
Kindly review this small patch for JDK-8202582.
https://bugs.openjdk.java.net/browse/JDK-8202582
http://cr.openjdk.java.net/~rgoel/JDK-8202582/webrev/
Fix is to call text.subSequence() before calling toString() on input
string, for more
On 2018-02-13 17:51, Naoto Sato wrote:
Hi Claes,
Looks good to me.
Thanks, Naoto!
Please add noreg-perf tag to the issue.
Done.
/Claes
Hi,
please review this improvement to the retrieveInteger method in
CLDRCalendarDataProviderImpl.
Bug: https://bugs.openjdk.java.net/browse/JDK-8197829
Webrev: http://cr.openjdk.java.net/~redestad/8197829/jdk.00/
This deals with a tiny startup regression that appeared in 10+36 on some
applic
94 matches
Mail list logo
