On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов
wrote:
> Currently the method is implemented like
>
> public List> parameterList() {
> return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
> }
>
> This seems to be excessive, as three objects are al
Hi,
During the discussion of the PR https://github.com/erlang/otp/pull/4856
"Map comprehensions" we have been asked to submit a new EEP.
So, finally, here is the new EEP pull-request:
https://github.com/erlang/eep/pull/32
Regards
Sergey
___
eeps maili
Hi guys!
I'm using dovecot submission server for clients to send emails and relay
them to postfix. Everything works fine unless a client tries to send large
(40Mbs) messages. No big deal one can say just set "message_size_limit =
314572800" in postfix and it should just work, but no, it does not,
On Mon, 23 Aug 2021 21:08:05 GMT, Andrey Turbanov
wrote:
> Collections.sort is just a wrapper, so it is better to use an instance method
> directly.
Marked as reviewed by stsypa...@github.com (no known OpenJDK username).
-
PR: https://git.openjdk.java.net/jdk/pull/5230
On Mon, 23 Aug 2021 21:08:05 GMT, Andrey Turbanov
wrote:
> Collections.sort is just a wrapper, so it is better to use an instance method
> directly.
Marked as reviewed by stsypa...@github.com (no known OpenJDK username).
-
PR: https://git.openjdk.java.net/jdk/pull/5230
Currently the method is implemented like
public List> parameterList() {
return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
}
This seems to be excessive, as three objects are allocated here. Instead we can
use `List.of(ptypes)` which doesn't allocate anything for empty array an
On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov
wrote:
> Using `ByteArrayOutputStream.toString` to convert it's content to a String is
> cleaner than `new String(out.toByteArray())`. Also it's a bit faster because
> of one less array copy.
Marked as reviewed by stsypa...@github.com (no known
On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov
wrote:
> Using `ByteArrayOutputStream.toString` to convert it's content to a String is
> cleaner than `new String(out.toByteArray())`. Also it's a bit faster because
> of one less array copy.
Marked as reviewed by stsypa...@github.com (no known
On Fri, 3 Sep 2021 13:22:54 GMT, Сергей Цыпанов
wrote:
> Current implementation looks like this:
>
> public byte[] getBytes(String charsetName)
> throws UnsupportedEncodingException {
> if (charsetName == null) throw new NullPointerException();
> return en
On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov
wrote:
> After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510)
> (eed3a536c0) this condition is always `false`. Empty package name is handled
> separately.
> Found by IntelliJ inspection.
Marked as reviewed by stsypa...@github.
On Sat, 4 Sep 2021 01:43:57 GMT, Naoto Sato wrote:
>> Current implementation looks like this:
>>
>> public byte[] getBytes(String charsetName)
>> throws UnsupportedEncodingException {
>> if (charsetName == null) throw new NullPointerException();
>> return encode(lookupCharset(cha
On Fri, 3 Sep 2021 14:04:27 GMT, Roger Riggs wrote:
> Redundant null checks get collapsed by HotSpot, so not a performance
> improvement.
Hi Roger, indeed, no improvement observed. How did you know it beforehand? I
was pretty sure we are going to win a couple of ns on this wide-used method.
P
On Fri, 3 Sep 2021 17:37:08 GMT, Sergey Bylokhov wrote:
>> Current implementation looks like this:
>>
>> public byte[] getBytes(String charsetName)
>> throws UnsupportedEncodingException {
>> if (charsetName == null) throw new NullPointerException();
>> return encode(lookupCharse
Current implementation looks like this:
public byte[] getBytes(String charsetName)
throws UnsupportedEncodingException {
if (charsetName == null) throw new NullPointerException();
return encode(lookupCharset(charsetName), coder(), value);
}
Null check seems to be redundant here be
On Mon, 30 Aug 2021 14:26:56 GMT, Сергей Цыпанов
wrote:
> Just a very tiny clean-up.
>
> There are some places in JDK code base where we call
> `Enum.class.getEnumConstants()` to get all the values of the referenced
> `enum`. This is excessive, less-readable and slower th
On Mon, 30 Aug 2021 14:26:56 GMT, Сергей Цыпанов
wrote:
> Just a very tiny clean-up.
>
> There are some places in JDK code base where we call
> `Enum.class.getEnumConstants()` to get all the values of the referenced
> `enum`. This is excessive, less-readable and slower th
On Mon, 30 Aug 2021 19:28:11 GMT, Kevin Rushforth wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8273140: Fix copyright year
>
> src/java.desktop/share/classes/sun/font/EAttribute
; EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15
> 0,017 ± 0,003 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space.normavgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.values:·gc.count avgt 15
> 262,000
; EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15
> 0,017 ± 0,003 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space.normavgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.values:·gc.count avgt 15
> 262,000
On Mon, 30 Aug 2021 19:28:11 GMT, Kevin Rushforth wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8273140: Fix copyright year
>
> src/java.desktop/share/classes/sun/font/EAttribute
Hello.
I'm trying to find a solution which doesn't use a lot of memory. In my case
I convert a page of a PDF document to JPG and current realization works
with BufferedImage. Is it possible to render a pdf page as an image to a
file without loading its content in RAM?
Best regards, Sergey
; EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15
> 0,017 ± 0,003 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space.normavgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.values:·gc.count avgt 15
> 262,000
; EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15
> 0,017 ± 0,003 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space.normavgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.values:·gc.count avgt 15
> 262,000
On Mon, 30 Aug 2021 17:54:45 GMT, Joe Darcy wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8273140: Fix copyright year
>
> src/java.desktop/share/classes/sun/font/AttributeValues
; EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15
> 0,017 ± 0,003 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space.normavgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.values:·gc.count avgt 15
> 262,000
On Mon, 30 Aug 2021 17:54:45 GMT, Joe Darcy wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8273140: Fix copyright year
>
> src/java.desktop/share/classes/sun/font/AttributeValues
; EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15
> 0,017 ± 0,003 MB/sec
> EnumBenchmark.values:·gc.churn.G1_Survivor_Space.normavgt 15
> ≈ 10⁻⁴ B/op
> EnumBenchmark.values:·gc.count avgt 15
> 262,000
On Mon, 30 Aug 2021 14:52:12 GMT, Claes Redestad wrote:
>> What about lines 582, 1003 and 1175? E.g. 582
>>
>> public AbstractStringBuilder append(String str) {
>> if (str == null) {
>> return appendNull();
>> }
>> int len = str.length();
>> ensureCapacityInternal(count +
On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote:
>> Refactor to improve inlining, which helps some microbenchmarks exer
>> StringBuilder.append(String)
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Simplify and
Just a very tiny clean-up.
There are some places in JDK code base where we call
`Enum.class.getEnumConstants()` to get all the values of the referenced `enum`.
This is excessive, less-readable and slower than just calling `Enum.values()`
as in `getEnumConstants()` we have volatile access:
publ
Just a very tiny clean-up.
There are some places in JDK code base where we call
`Enum.class.getEnumConstants()` to get all the values of the referenced `enum`.
This is excessive, less-readable and slower than just calling `Enum.values()`
as in `getEnumConstants()` we have volatile access:
publ
On Mon, 30 Aug 2021 13:54:13 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1730:
>>
>>> 1728: }
>>> 1729:
>>> 1730: private void putStringAt(int index, String str) {
>>
>> Can we replace all the calls to this method with calls to pr
On Mon, 30 Aug 2021 14:04:27 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1714:
>>
>>> 1712:
>>> 1713: private void inflateIfNeededFor(String input) {
>>> 1714: if (COMPACT_STRINGS && (coder != input.coder())) {
>>
>> I'm not c
On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote:
>> Refactor to improve inlining, which helps some microbenchmarks exer
>> StringBuilder.append(String)
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Simplify and
On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote:
>> Refactor to improve inlining, which helps some microbenchmarks exer
>> StringBuilder.append(String)
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Simplify and
On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote:
>> Refactor to improve inlining, which helps some microbenchmarks exer
>> StringBuilder.append(String)
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Simplify and
On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov wrote:
>> This is a continuation of
>>
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK
On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov wrote:
>> This is a continuation of
>>
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK
On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov wrote:
>> This is a continuation of
>>
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK
On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov wrote:
>> This is a continuation of
>>
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK
On Fri, 20 Aug 2021 21:26:41 GMT, Sergey Bylokhov wrote:
>> This is a continuation of
>>
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK
Hello!
Looks like https://bugs.openvz.org/browse/OVZ-7274
On Sun, 22 Aug 2021 at 15:36, Hugo Cloez wrote:
> Here my vcmmd.log
>
> 2021-08-22 14:34:09 ERROR vcmmd.ldmgr: Failed to load policy
> 'performance': No module named performance
> 2021-08-22 14:34:09 INFO vcmmd.ldmgr: Loaded policy 'Dens
This is a continuation of
- https://bugs.openjdk.java.net/browse/JDK-6736490
- https://bugs.openjdk.java.net/browse/JDK-8035284
- https://bugs.openjdk.java.net/browse/JDK-8145680
- https://bugs.openjdk.java.net/browse/JDK-8251548
As mentioned in JDK-6736490:
_An explicit initialization of a vola
This is a continuation of
- https://bugs.openjdk.java.net/browse/JDK-6736490
- https://bugs.openjdk.java.net/browse/JDK-8035284
- https://bugs.openjdk.java.net/browse/JDK-8145680
- https://bugs.openjdk.java.net/browse/JDK-8251548
As mentioned in JDK-6736490:
_An explicit initialization of a vola
This is a continuation of
- https://bugs.openjdk.java.net/browse/JDK-6736490
- https://bugs.openjdk.java.net/browse/JDK-8035284
- https://bugs.openjdk.java.net/browse/JDK-8145680
- https://bugs.openjdk.java.net/browse/JDK-8251548
As mentioned in JDK-6736490:
_An explicit initialization of a vola
This is a continuation of
- https://bugs.openjdk.java.net/browse/JDK-6736490
- https://bugs.openjdk.java.net/browse/JDK-8035284
- https://bugs.openjdk.java.net/browse/JDK-8145680
- https://bugs.openjdk.java.net/browse/JDK-8251548
As mentioned in JDK-6736490:
_An explicit initialization of a vola
This is a continuation of
- https://bugs.openjdk.java.net/browse/JDK-6736490
- https://bugs.openjdk.java.net/browse/JDK-8035284
- https://bugs.openjdk.java.net/browse/JDK-8145680
- https://bugs.openjdk.java.net/browse/JDK-8251548
As mentioned in JDK-6736490:
_An explicit initialization of a vola
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdate
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdate
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdate
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdate
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdate
On Thu, 8 Jul 2021 11:51:18 GMT, Yi Yang wrote:
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
>
> As Mandy suggested, I create this PR for changes involvin
On Tue, 10 Aug 2021 13:16:42 GMT, Сергей Цыпанов
wrote:
> The code in `Integer.decode()` and `Long.decode()` might allocate two
> instances of Integer/Long for the negative values less than -127:
>
> Integer result;
>
> result = Integer.valueOf(nm.substring(index)
On Tue, 10 Aug 2021 13:16:42 GMT, Сергей Цыпанов
wrote:
> The code in `Integer.decode()` and `Long.decode()` might allocate two
> instances of Integer/Long for the negative values less than -127:
>
> Integer result;
>
> result = Integer.valueOf(nm.substring(index)
()) : result;
>
> To avoid this we can declare 'result' as `int` and use `Integer.parseInt()`
> method. Same applicable for `Long` and some other classes.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev exclu
()) : result;
>
> To avoid this we can declare 'result' as `int` and use `Integer.parseInt()`
> method. Same applicable for `Long` and some other classes.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev exclu
On Tue, 10 Aug 2021 17:39:01 GMT, Сергей Цыпанов
wrote:
>> src/java.base/share/classes/java/lang/Integer.java line 1450:
>>
>>> 1448:
>>> 1449: try {
>>> 1450: result = parseInt(nm.substring(index), radix);
>>
>> Possibl
On Tue, 10 Aug 2021 17:39:01 GMT, Сергей Цыпанов
wrote:
>> src/java.base/share/classes/java/lang/Integer.java line 1450:
>>
>>> 1448:
>>> 1449: try {
>>> 1450: result = parseInt(nm.substring(index), radix);
>>
>> Possibl
On Tue, 10 Aug 2021 14:56:11 GMT, Claes Redestad wrote:
>> The code in `Integer.decode()` and `Long.decode()` might allocate two
>> instances of Integer/Long for the negative values less than -127:
>>
>> Integer result;
>>
>> result = Integer.valueOf(nm.substring(index), radix);
>> result = ne
On Tue, 10 Aug 2021 14:56:11 GMT, Claes Redestad wrote:
>> The code in `Integer.decode()` and `Long.decode()` might allocate two
>> instances of Integer/Long for the negative values less than -127:
>>
>> Integer result;
>>
>> result = Integer.valueOf(nm.substring(index), radix);
>> result = ne
The code in `Integer.decode()` and `Long.decode()` might allocate two instances
of Integer/Long for the negative values less than -127:
Integer result;
result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;
To avoid this we can de
The code in `Integer.decode()` and `Long.decode()` might allocate two instances
of Integer/Long for the negative values less than -127:
Integer result;
result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;
To avoid this we can de
On Mon, 5 Jul 2021 19:03:49 GMT, Andrey Turbanov
wrote:
>> src/java.desktop/share/classes/java/awt/Menu.java line 489:
>>
>>> 487: }
>>> 488:
>>> 489: synchronized Enumeration shortcuts() {
>>
>> I'm not sure whether it's ok to change return type here, probably it'd be
>> better to k
On Mon, 5 Jul 2021 19:03:49 GMT, Andrey Turbanov
wrote:
>> src/java.desktop/share/classes/java/awt/Menu.java line 489:
>>
>>> 487: }
>>> 488:
>>> 489: synchronized Enumeration shortcuts() {
>>
>> I'm not sure whether it's ok to change return type here, probably it'd be
>> better to k
On Mon, 5 Jul 2021 19:03:49 GMT, Andrey Turbanov
wrote:
>> src/java.desktop/share/classes/java/awt/Menu.java line 489:
>>
>>> 487: }
>>> 488:
>>> 489: synchronized Enumeration shortcuts() {
>>
>> I'm not sure whether it's ok to change return type here, probably it'd be
>> better to k
On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed. In
> post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checke
On Mon, 5 Jul 2021 19:03:49 GMT, Andrey Turbanov
wrote:
>> src/java.desktop/share/classes/java/awt/Menu.java line 489:
>>
>>> 487: }
>>> 488:
>>> 489: synchronized Enumeration shortcuts() {
>>
>> I'm not sure whether it's ok to change return type here, probably it'd be
>> better to k
On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed. In
> post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checke
On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed. In
> post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checke
On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed. In
> post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checke
On Fri, 18 Jun 2021 07:31:14 GMT, Сергей Цыпанов
wrote:
> There is an optimization opportunity for the widespread use-case when a
> resource is read from classpath using
> `getClass().getClassLoader().getResource()` or
> `getClass().getClassLoader().getResourceAsStream()`.
>
On Wed, 23 Jun 2021 10:03:48 GMT, Сергей Цыпанов
wrote:
>> Hi Sergey,
>>
>> That exception means you're using an obsolete version of jtreg: you need
>> jtreg-6+1 now.
>>
>> best regards,
>> -- daniel
>
> @dfuch I've fixed the issue an
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be don
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be don
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be don
On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote:
> This is a request to clean up a desktop module as was done in JDK-8233884 for
> "java.base" module.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be don
On Wed, 2 Jun 2021 12:10:46 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.
This pull request has now been integrated.
Changeset: 249d6418
A
On Wed, 2 Jun 2021 12:10:46 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.
This pull request has now been integrated.
Changeset: 249d6418
A
On Wed, 2 Jun 2021 12:10:46 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.
This pull request has now been integrated.
Changeset: 249d6418
A
On Wed, 2 Jun 2021 14:10:38 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().
This pull request has now been integrated.
Changeset: 6a3f8343
Author:
On Wed, 2 Jun 2021 14:10:38 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().
This pull request has now been integrated.
Changeset: 6a3f8343
Author:
On Wed, 2 Jun 2021 14:10:38 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().
This pull request has now been integrated.
Changeset: 6a3f8343
Author:
On Fri, 9 Jul 2021 11:50:38 GMT, Сергей Цыпанов
wrote:
> `AbstractStringBuilder.charAt(int)` does bounds check before calling
> `charAt()` (for non-latin Strings):
>
> @Override
> public char charAt(int index) {
> checkIndex(index, count);
> if (isLatin1()) {
&
On Thu, 22 Apr 2021 14:07:20 GMT, Сергей Цыпанов
wrote:
> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found
> out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like
> `baseName.replace('.', '/') +
On Wed, 30 Jun 2021 08:40:21 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, `
On Wed, 30 Jun 2021 08:40:21 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, `
> 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
merge or a rebase. The pull request now con
> 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
merge or a rebase. The pull request now con
> 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
merge or a rebase. The pull request now con
On Mon, 2 Aug 2021 11:09:30 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8269665: Update copy-right year
>> - 8269665: Reuse String.valueOf(boolean)
>
&
On Mon, 2 Aug 2021 11:09:30 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8269665: Update copy-right year
>> - 8269665: Reuse String.valueOf(boolean)
>
&
tring:·gc.churn.G1_Survivor_Space avgt
> 30 0,004 ± 0,002 MB/sec
> ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm avgt
> 30≈ 10⁻⁴ B/op
> ByteToStringBenchmark.byteToString:·gc.count avgt
> 30 224,00
tring:·gc.churn.G1_Survivor_Space avgt
> 30 0,004 ± 0,002 MB/sec
> ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm avgt
> 30≈ 10⁻⁴ B/op
> ByteToStringBenchmark.byteToString:·gc.count avgt
> 30 224,00
On Mon, 2 Aug 2021 10:52:26 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - Merge branch 'master' into 8270160
>&g
004 ns/op
> StringBuilderCharAtBenchmark.utfavgt 50 2,631 ± 0,004 ns/op
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8270160 Revert irrelevant changes
-
Changes:
- all: https://git.openjdk.java.net/j
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.
>>
>>
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.
>>
>>
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
601 - 700 of 5230 matches
Mail list logo
