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 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 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 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 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 12:16:23 GMT, Claes Redestad wrote:
>> src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java
>> line 75:
>>
>>> 73:
>>> 74: protected AbstractCharsetProvider(String pkgPrefixName) {
>>> 75: packagePrefix = pkgPrefixName.concat(".");
>>
>> Hm
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 DoubleByte-based
>
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: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 DoubleByte-based
>
Please review this simple test case fix. By sampling locales to test, it
reduces the possibility of the time out.
-
Commit messages:
- 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out
Changes: https://git.openjdk.java.net/jdk/pull/2465/files
Webrev: https://webrev
On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote:
> Please review this simple test case fix. By sampling locales to test, it
> reduces the possibility of the time out.
Marked as reviewed by bpb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2465
On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote:
> Please review this simple test case fix. By sampling locales to test, it
> reduces the possibility of the time out.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2465
On Mon, 8 Feb 2021 21:52:45 GMT, Lance Andersen wrote:
>> Please review this simple test case fix. By sampling locales to test, it
>> reduces the possibility of the time out.
>
> Marked as reviewed by lancea (Reviewer).
The fix looks ok to me. Just an interesting note that this test took such a
On Mon, 8 Feb 2021 23:42:04 GMT, Joe Wang wrote:
>> Marked as reviewed by lancea (Reviewer).
>
> The fix looks ok to me. Just an interesting note that this test took such a
> long time to run. Given the amount of locales, limit(30) would reduce the
> time to approximately 1/5 of the time, that
On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote:
> Please review this simple test case fix. By sampling locales to test, it
> reduces the possibility of the time out.
Marked as reviewed by joehw (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2465
On Tue, 9 Feb 2021 00:04:44 GMT, Naoto Sato wrote:
>> The fix looks ok to me. Just an interesting note that this test took such a
>> long time to run. Given the amount of locales, limit(30) would reduce the
>> time to approximately 1/5 of the time, that would still be about 100,000ms
>> accord
17 matches
Mail list logo
