On Wed, 8 Jun 2022 10:20:37 GMT, Claes Redestad wrote:
> To take optimal advantage of the pre-existing optimization for repeated
> filters we could split the application of different types of stringifiers.
>
> The resulting difference in order of evaluation is not observable by
> conventional
> Instead of `Executable.getParameterTypes()` we could use
> `Executable.getSharedParameterTypes()` in trusted code. Same is applicable
> for `Executable.getExceptionTypes()`.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The increment
Instead of `Executable.getParameterTypes()` we could use
`Executable.getSharedParameterTypes()` in trusted code. Same is applicable for
`Executable.getExceptionTypes()`.
-
Commit messages:
- 8287908: Use non-cloning reflection methods where acceptable
Changes:
On Mon, 6 Jun 2022 12:58:39 GMT, Сергей Цыпанов wrote:
> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be
> volatile, even in case of race in the worst case it is recalculated at most
> once per thread
> - `defaultLocale` field is read multiple times in
On Mon, 6 Jun 2022 17:31:15 GMT, Naoto Sato wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8287860: Mark hash fields with @Stable
>
> src/java.base/share/classes/java/util/Loc
multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8287860: Rename local vars
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/
On Mon, 6 Jun 2022 13:34:27 GMT, liach wrote:
>> These fields can only be written once besides the default values, but they
>> don't have to be written in the static initializer or constructor. So when a
>> non-zero hash code is written, it's cached as if it's a final field. For a
>> zero
multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8287860: Mark hash fields with @Stable
-
Changes:
- all: https://git.openjdk.java.net/j
On Mon, 6 Jun 2022 13:20:31 GMT, liach wrote:
>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be
>> volatile, even in case of race in the worst case it is recalculated at most
>> once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> -
- cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be
volatile, even in case of race in the worst case it is recalculated at most
once per thread
- `defaultLocale` field is read multiple times in `initDefault()`
- `isoLanguages` is accessed multiple times in `getISOLanguages()`
On Thu, 2 Jun 2022 14:25:55 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5462:
>>
>>> 5460: Objects.requireNonNull(target);
>>> 5461: Objects.requireNonNull(newTypes);
>>> 5462: return dropArgumentsToMatch(target, skip,
On Fri, 27 May 2022 19:52:30 GMT, Claes Redestad wrote:
>> In preparation of #8855 this PR refactors the conversions from `List` to
>> array and array to `List`, reducing the number of conversions when calling
>> `MethodHandles.dropArguments` in particular. This remove about ~5% of
>>
On Mon, 7 Mar 2022 15:11:50 GMT, Сергей Цыпанов wrote:
> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with
> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when
> called with vararg of size 0, 1, 2.
>
> In general replacement of
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the
On Tue, 31 May 2022 19:33:15 GMT, Roger Riggs wrote:
>> Сергей Цыпанов 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 conta
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. Th
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. Th
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. Th
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. Th
On Mon, 16 May 2022 15:29:38 GMT, Сергей Цыпанов wrote:
>> Even in the no exceptions case, the `exceptionTypes` array still has to be
>> allocated/copied by `Method.getExceptionTypes()`[^1] when the `ProxyMethod`
>> constructor[^2] is invoked.
>>
>> So if a
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a
On Fri, 13 May 2022 13:36:52 GMT, ExE Boss wrote:
> So if anything, the List.of(…) call should be moved into the ProxyMethod
> constructor. And maybe the call to Method.getExceptionTypes() should be
> changed to Method.getSharedExceptionTypes()
Makes sense. Do you want me to do this within
On Fri, 13 May 2022 11:14:29 GMT, ExE Boss wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8282662: Revert dubious changes in MethodType
>
> src/java.base/share/classes/java/lang/re
On Fri, 13 May 2022 12:19:08 GMT, Сергей Цыпанов wrote:
>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727:
>>
>>> 725: MethodVisitor mv = cw.visitMethod(accessFlags,
>>> 726: method.
On Thu, 12 May 2022 14:14:38 GMT, Weijun Wang wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8282662: Revert dubious changes in MethodType
>
> src/java.base/share/
On Sat, 5 Mar 2022 13:07:56 GMT, Сергей Цыпанов wrote:
> `Class.getInterfaces(false)` does not clone underlying array and can be used
> in cases when the returned array is only read from.
This pull request has now been integrated.
Changeset: 9073a98d
Author:Sergey Tsypanov
Com
On Wed, 4 May 2022 09:46:00 GMT, Сергей Цыпанов wrote:
>> `Class.getInterfaces(false)` does not clone underlying array and can be used
>> in cases when the returned array is only read from.
>
> Сергей Цыпанов has updated the pull request incrementally with one addition
> `Class.getInterfaces(false)` does not clone underlying array and can be used
> in cases when the returned array is only read from.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8282701: Revert some irrelevant c
On Sat, 5 Mar 2022 13:07:56 GMT, Сергей Цыпанов wrote:
> `Class.getInterfaces(false)` does not clone underlying array and can be used
> in cases when the returned array is only read from.
Let's wait a bit
-
PR: https://git.openjdk.java.net/jdk/pull/7714
On Thu, 10 Mar 2022 08:52:17 GMT, Сергей Цыпанов wrote:
>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with
>> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when
>> called with vararg of size 0, 1, 2.
>>
>> In general
On Sat, 26 Mar 2022 16:35:14 GMT, liach wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8282662: Revert dubious changes in MethodType
>
> Just curious, this issue asks to replace
On Thu, 10 Mar 2022 08:52:17 GMT, Сергей Цыпанов wrote:
>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with
>> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when
>> called with vararg of size 0, 1, 2.
>>
>> In general
On Wed, 9 Mar 2022 16:09:01 GMT, liach wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8282662: Revert dubious changes
>
> src/java.base/share/classes/java/lang/invoke/Metho
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the la
On Tue, 8 Mar 2022 14:27:23 GMT, liach wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8282662: Revert dubious changes
>
> src/java.base/share/classes/java/nio/file/FileTreeI
On Tue, 8 Mar 2022 14:28:00 GMT, liach wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8282662: Revert dubious changes
>
> src/java.base/share/classes/sun/reflect/annotation/Ann
parameter types are never null
> - interfaces used for proxy construction and returned from
> `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the la
On Mon, 7 Mar 2022 16:06:44 GMT, Claes Redestad wrote:
> Notice list.of will have the downside of copying the input array when the
> size is not small while arrays aslist does not. Is the tradeoff worth it?
Good point, I see risky changes in this PR:
- `ProxyGenerator`
- `Proxy`
- `MethodType`
`List.of()` along with `Set.of()` create unmodifiable `List/Set` but with
smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called
with vararg of size 0, 1, 2.
In general replacement of `Arrays.asList()` with `List.of()` is dubious as the
latter is null-hostile, however
`Class.getInterfaces(false)` does not clone underlying array and can be used in
cases when the returned array is only read from.
-
Commit messages:
- 8282701: Use Class.getInterfaces(false) where possible to reduce allocation
pressure
Changes:
On Tue, 11 Jan 2022 13:53:58 GMT, Claes Redestad wrote:
>> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps
>> the performance of the method by helping C2 optimize each individual loop
>> better.
>>
>> Results on the updated micros:
>> 19-b04:
>>
>> Benchmark
On Mon, 13 Dec 2021 09:39:55 GMT, Сергей Цыпанов wrote:
> Originally this was spotted by by Amir Hadadi in
> https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>
> It looks like in the following code in `String(byte[], int,
On Mon, 13 Dec 2021 09:39:55 GMT, Сергей Цыпанов wrote:
> Originally this was spotted by by Amir Hadadi in
> https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>
> It looks like in the following code in `String(byte[], int,
On Thu, 9 Dec 2021 11:50:50 GMT, Сергей Цыпанов wrote:
> `Executable.getParameterTypes()` creates a copy of underlying array which is
> redundant in trusted code when we are sure the action is read-only.
This pull request has now been integrated.
Changeset: ece98d85
Author:Sergey Ts
> `Executable.getParameterTypes()` creates a copy of underlying array which is
> redundant in trusted code when we are sure the action is read-only.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains two c
> `Executable.getParameterTypes()` creates a copy of underlying array which is
> redundant in trusted code when we are sure the action is read-only.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8278461: Revert Exec
On Mon, 10 Jan 2022 09:38:15 GMT, Сергей Цыпанов wrote:
>> src/java.base/share/classes/java/lang/reflect/Executable.java line 313:
>>
>>> 311: // getParameterTypes().
>>> 312: if (!genericInfo) {
>>> 313: return getSharedPara
On Thu, 6 Jan 2022 16:45:09 GMT, Claes Redestad wrote:
>> `Executable.getParameterTypes()` creates a copy of underlying array which is
>> redundant in trusted code when we are sure the action is read-only.
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 317:
>
>> 315:
On Thu, 6 Jan 2022 16:38:05 GMT, Claes Redestad wrote:
>> `Executable.getParameterTypes()` creates a copy of underlying array which is
>> redundant in trusted code when we are sure the action is read-only.
>
> src/java.base/share/classes/java/lang/reflect/Executable.java line 313:
>
>> 311:
On Thu, 9 Dec 2021 11:50:50 GMT, Сергей Цыпанов wrote:
> `Executable.getParameterTypes()` creates a copy of underlying array which is
> redundant in trusted code when we are sure the action is read-only.
Let's wait
-
PR: https://git.openjdk.java.net/jdk/pull/6782
On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed missing BufferedInputStream
Maybe we need to include into this patch the benchmark
On Sat, 27 Nov 2021 17:41:58 GMT, Andrey Turbanov wrote:
>> Usages of primitive types should be preferred and makes code easier to read.
>> Similar cleanups:
>> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168)
>> java.desktop
>> 2.
On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote:
> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168)
> java.desktop
> 2.
On Fri, 26 Nov 2021 12:46:59 GMT, Сергей Цыпанов wrote:
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
This pull request has n
On Tue, 14 Dec 2021 13:20:46 GMT, Alan Bateman wrote:
>>> Originally this was spotted by by Amir Hadadi in
>>> https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>>
>> Before anyone looks at this, can you confirm that the patch does not
On Tue, 14 Dec 2021 19:12:29 GMT, Mai Đặng Quân Anh
wrote:
> The problem, at first glance, seems to be that our compiled code is trying to
> compute this mysterious number
@merykitty how do you view it? 樂
-
PR: https://git.openjdk.java.net/jdk/pull/6812
On Mon, 13 Dec 2021 09:55:36 GMT, Alan Bateman wrote:
>> Originally this was spotted by by Amir Hadadi in
>> https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>>
>> It looks like in the following code in `String(byte[], int, int, Charset)`
Originally this was spotted by by Amir Hadadi in
https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
It looks like in the following code in `String(byte[], int, int, Charset)`
while (offset < sl) {
int b1 = bytes[offset];
if (b1 >= 0) {
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
Сергей Цыпанов has updated the pull request incrementally with two additional
c
On Tue, 7 Dec 2021 12:01:27 GMT, Alexey Ivanov wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Inline local var
>
> src/java.base/share/classes/java/util/Calendar.java line
On Mon, 6 Dec 2021 17:48:37 GMT, Phil Race wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
Сергей Цыпанов has updated the pull request incrementally with one additional
On Mon, 6 Dec 2021 17:46:22 GMT, Phil Race wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/java
On Mon, 8 Nov 2021 14:25:10 GMT, Сергей Цыпанов wrote:
> This is a follow-up for https://github.com/openjdk/jdk/pull/4507, looks like
> there are some cases that were not covered.
>
> Also this is related to https://github.com/openjdk/jdk/pull/3615
This pull request has now bee
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
Сергей Цыпанов has updated the pull request incrementally with one additional
On Sat, 27 Nov 2021 22:50:55 GMT, Michael Bien wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/
Instead of something like
long x;
long y;
return (x < y) ? -1 : ((x == y) ? 0 : 1);
we can use `return Long.compare(x, y);`
All replacements are done with IDE.
-
Commit messages:
- 8277868: Use Comparable.compare() instead of surrogate code
Changes:
On Wed, 17 Nov 2021 22:00:30 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
>> lombok is much
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into `File.pathSeparator` I've found out that currently we initialize
> it as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
>
On Wed, 10 Nov 2021 10:36:37 GMT, Michael Bien wrote:
> it should compile into invokedynamic makeConcatWithConstants on later JDKs
As far as I understand `StringConcatFactory` is not available on bootstrap
stage and `StringBuilder` is used instead. See
Looking into File.pathSeparator I've found out that currently we initialize
them as
public static final String separator = "" + separatorChar;
Which after compilation turns into
NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder. ()V
LDC ""
INVOKEVIRTUAL
On Mon, 8 Nov 2021 14:52:59 GMT, Daniel Fuchs wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8276806: Use Objects.checkFromIndexSize where possible in java.base
>
> src/j
> This is a follow-up for https://github.com/openjdk/jdk/pull/4507, looks like
> there are some cases that were not covered.
>
> Also this is related to https://github.com/openjdk/jdk/pull/3615
Сергей Цыпанов has updated the pull request incrementally with one additional
commit si
This is a follow-up for https://github.com/openjdk/jdk/pull/4507, looks like
there are some cases that were not covered.
Also this is related to https://github.com/openjdk/jdk/pull/3615
-
Commit messages:
- 8276806: Use Objects.checkFromIndexSize where possible in java.base
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote:
> It looks like we cannot use `Long.hashCode(long)` for
> `java.rmi.server.ObjID.hashCode()` due to specification:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().
This pull re
On Fri, 15 Oct 2021 11:43:53 GMT, Pavel Rappo wrote:
>> It looks like we cannot use `Long.hashCode(long)` for
>> `java.rmi.server.ObjID.hashCode()` due to specification:
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().
>
> It's important to
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote:
> It looks like we cannot use `Long.hashCode(long)` for
> `java.rmi.server.ObjID.hashCode()` due to JavaDoc:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().
@stuart-
It looks like we cannot use `Long.hashCode(long)` for
`java.rmi.server.ObjID.hashCode()` due to JavaDoc:
https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().
-
Commit messages:
- 8275293: A change done with JDK-8268764 mismatches the
On Tue, 15 Jun 2021 12:15:11 GMT, Сергей Цыпанов wrote:
> In some JDK classes there's still the following hashCode() implementation:
>
> long objNum;
>
> public int hashCode() {
> return (int) objNum;
> }
>
> This outdated expression should be repla
On Wed, 6 Oct 2021 09:26:06 GMT, Peter Levart wrote:
>> This is trivial fix of
>> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
>> which replaces manually-computed `int`-based `long` hash-code.
>>
>> Because `Long#hashCode(long)` uses other hashing function
On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov
wrote:
> Usages of primitive types should be preferred and makes code easier to read.
> Similar cleanups:
> 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168)
> java.desktop
> 2.
On Thu, 11 Feb 2021 13:28:49 GMT, Сергей Цыпанов
wrote:
> Originally was proposed by Zheka Kozlov here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>
> Just a tiny optimization: we can use for-i loop instead of
> `Iterable.forEach()` w
On Tue, 5 Oct 2021 09:18:57 GMT, Сергей Цыпанов
wrote:
>> Originally was proposed by Zheka Kozlov here:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
>>
>> Just a tiny optimization: we can use for-i loop instead of
>> `Iterab
avgt 50 ≈ 10⁻⁴
> B/op
> NCopiesBenchmarks.forEach:·gc.count50 avgt 50 ≈ 0
> counts
> NCopiesBenchmarks.forEach 100 avgt 50 376.675 ±
> 2.476 ns/op
> NCopiesBenchmarks.forEach:·gc.alloc.rate 100
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Mon, 4 Oct 2021 16:51:27 GMT, Martin Buchholz wrote:
>> Сергей Цыпанов 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 contai
avgt 50 ≈ 10⁻⁴
> B/op
> NCopiesBenchmarks.forEach:·gc.count50 avgt 50 ≈ 0
> counts
> NCopiesBenchmarks.forEach 100 avgt 50 376.675 ±
> 2.476 ns/op
> NCopiesBenchmarks.forEach:·gc.alloc.rate 100
Originally was proposed by Zheka Kozlov here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057192.html
Just a tiny optimization: we can use for-i loop instead of `Iterable.forEach()`
which is relying on iterator.
Simple benchmark demonstrates slight improvement:
Hello,
in the code of HashSet(Collection) we have an optimization opportunity:
public HashSet(Collection c) {
map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16));
addAll(c);
}
instead of using addAll() inherited from j.u.Collection we can use
c.forEach(this::add):
public
On Fri, 24 Sep 2021 10:35:54 GMT, Сергей Цыпанов
wrote:
> Currently on each invocation of `URLClassPath.FileLoader.getResource()`
> `normalizedBase` URL is recalculated using same final `baseURL` from parent
> class. This can be avoided giving significant improvement in memory
>
On Fri, 24 Sep 2021 11:14:00 GMT, Daniel Fuchs wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274276: Make URLClassPath.Loader.getBaseURL() final
>
> This is calling an overidab
norm avgt 100
> 1634,314 ± 79,821B/op
> URLClassPathBenchmark.getResource:·gc.churn.G1_Survivor_Space avgt 100
> 0,101 ± 0,097 MB/sec
> URLClassPathBenchmark.getResource:·gc.churn.G1_Survivor_Space.norm avgt 100
> 0,345 ± 0,329B/op
> URLClassPathBenchmark.getResourc
Currently on each invocation of `URLClassPath.FileLoader.getResource()`
`normalizedBase` URL is recalculated using same final `baseURL` from parent
class. This can be avoided giving significant improvement in memory
consumption. Consider the benchmark:
@State(Scope.Benchmark)
On Wed, 22 Sep 2021 00:21:01 GMT, Claes Redestad 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 allocated here. Instead
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 outdated
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
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
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
1 - 100 of 396 matches
Mail list logo
