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
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 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
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 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
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 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
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
On Thu, 3 Mar 2022 19:33:21 GMT, Andrey Turbanov wrote:
> Pass cause exception as constructor parameter is shorter and easier to read.
LGTM
-
Marked as reviewed by stsypa...@github.com (no known OpenJDK username).
PR: https://git.openjdk.java.net/jdk/pull/7682
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 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 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 Sat, 2 Oct 2021 05:45:47 GMT, Clive Verghese wrote:
> Hi,
>
> We have identified that the `HandshakeContext` initialization takes up a
> close to 50% of the flame graph for startHandshake. I have moved the
> computation of the `activeProtocols` and `activeCipherSuites` from the
>
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 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
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 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)
.intValue()) : 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 excludes
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 =
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
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[]
>
On Thu, 1 Jul 2021 10:38:24 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated
ould be the case if the two halves were combined with an OR (AND) operation.
>
> See https://stackoverflow.com/a/4045083
>
> This is related to https://github.com/openjdk/jdk/pull/4309
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8268
ould be the case if the two halves were combined with an OR (AND) operation.
>
> See https://stackoverflow.com/a/4045083
>
> This is related to https://github.com/openjdk/jdk/pull/4309
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8268
On Wed, 30 Jun 2021 11:49:51 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated
ould be the case if the two halves were combined with an OR (AND) operation.
>
> See https://stackoverflow.com/a/4045083
>
> This is related to https://github.com/openjdk/jdk/pull/4309
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental we
On Mon, 14 Jun 2021 11:34:50 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.
> I checked only places where `Vector` was used as local variable.
Marked as reviewed by
On Wed, 16 Jun 2021 09:49:17 GMT, Andrey Turbanov
wrote:
>> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line
>> 154:
>>
>>> 152: while (tokenizer.hasMoreTokens())
>>> 153: v.add(tokenizer.nextToken());
>>> 154: ciphers = new
On Mon, 14 Jun 2021 11:34:50 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.
> I checked only places where `Vector` was used as local variable.
I've filed
In some JDK classes there's still the following hashCode() implementation:
long objNum;
public int hashCode() {
return (int) objNum;
}
This outdated expression should be replaced with Long.hashCode(long) as it
- uses all bits of the original value, does not discard any information
On Tue, 16 Feb 2021 14:30:58 GMT, Сергей Цыпанов
wrote:
> Non-static classes hold a link to their parent classes, which in many cases
> can be avoided.
This pull request has now been integrated.
Changeset: 9425d3de
Author:Sergey Tsypanov
Committer: Claes Redestad
URL:
On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8261880: Remove static from declarations of Holder nested classes
>
> Marked as
On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов
wrote:
>> Non-static classes hold a link to their parent classes, which in many cases
>> can be avoided.
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
&
On Thu, 18 Feb 2021 14:30:15 GMT, Сергей Цыпанов
wrote:
> Hello,
>
> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
> joined Strings.
>
> This applies for the cases when all joined Strings as well as delimiter,
> prefix and suffix conta
On Mon, 15 Mar 2021 20:54:54 GMT, Claes Redestad 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 contain
960.059
> ± 0.002 424.031 ± 0.001 B/op
> stringJoiner:·gc.alloc.rate.norm 564 mixed 1760.088
> ± 0.003 744.041 ± 0.001 B/op
> stringJoiner:·gc.alloc.rate.norm 10 8 mixed 664.052
> ±
On Mon, 15 Mar 2021 14:07:29 GMT, Claes Redestad wrote:
>> I was thinking about `StringBuilder` at the very beginning but then decided
>> to have no bounds checks and reallocations. Indeed from maintainability
>> point of view your solution is much more attractive. I have one minor
>> comment
960.059
> ± 0.002 424.031 ± 0.001 B/op
> stringJoiner:·gc.alloc.rate.norm 564 mixed 1760.088
> ± 0.003 744.041 ± 0.001 B/op
> stringJoiner:·gc.alloc.rate.norm 10 8 mixed 664.052
> ± 0.001 3
On Mon, 15 Mar 2021 12:36:24 GMT, Claes Redestad wrote:
>> Hi @cl4es,
>>> Some of these changes conflict with #2334, which suggest removing the
>>> `coder` and `isLatin1` methods from `String`.
>>
>> I've checked out Aleksey's branch and applied my changes onto it, the only
>> thing that I
On Wed, 24 Feb 2021 08:50:36 GMT, Alan Bateman wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8261880: Remove static from declarations of Holder nested classes
>
> src/java.b
On Thu, 18 Feb 2021 15:19:43 GMT, Claes Redestad wrote:
>> Hello,
>>
>> as of now `java.util.StringJoiner` still uses `char[]` as a storage for
>> joined Strings.
>>
>> This applies for the cases when all joined Strings as well as delimiter,
>> prefix and suffix contain only ASCII symbols.
Hello,
as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined
Strings.
This applies for the cases when all joined Strings as well as delimiter, prefix
and suffix contain only ASCII symbols.
As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings
> Non-static classes hold a link to their parent classes, which in many cases
> can be avoided.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8261880: Remove static from declarations of Holder nested c
On Wed, 17 Feb 2021 16:24:46 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8261880: Remove static from declarations of Holder nested classes
>
> src/java.base/
Non-static classes hold a link to their parent classes, which in many cases can
be avoided.
-
Commit messages:
- 8261880: Change nested classes in java.base to static nested classes where
possible
Changes: https://git.openjdk.java.net/jdk/pull/2589/files
Webrev:
On Thu, 24 Dec 2020 17:30:41 GMT, Xue-Lei Andrew Fan wrote:
> > What about using List.of() instead?
>
> For now, the Collections.singletonList() is more compact, which uses one
> class variable. While List.of(T) shares the internal implementation with
> List.of(T t1, T t2), which uses two
On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov
wrote:
>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
>>
>>> 2457: byte[] bytes = in.readAllBytes();
>>> 2458: return
>>> CertificateFactory.getInstance("X509").generateCRLs(
>>>
On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272: Refactor I/O stream
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced
On Wed, 28 Oct 2020 08:49:38 GMT, Sergey Bylokhov wrote:
>> Rebased onto master to have the fix introduced in
>> https://github.com/openjdk/jdk/pull/778
>
> FYI it is better to use merge, instead of rebase+force push. Rebase breaks
> history and all existed code comments.
@mrserb thanks for
On Sat, 24 Oct 2020 23:12:09 GMT, Phil Race 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 contains one add
citValue avgt 30 11.846 ± 0.273 ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in
> progress we could trivially replace explicit zeroing with default
> constructors gaining some performance benefit with no risk.
>
> I've tested the changes locally, both tier1 and tie
On Fri, 23 Oct 2020 09:12:15 GMT, Daniel Fuchs wrote:
>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
>> reason to explicitly instantiate any instance of `Atomic*` class with its
>> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>>
As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason
to explicitly instantiate any instance of `Atomic*` class with its default
value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()`
which is faster:
@State(Scope.Thread)
On Thu, 17 Sep 2020 08:09:31 GMT, Сергей Цыпанов
wrote:
> Hello,
>
> is it possible to have a code review for the changes proposed in JDK-8251548
> (originally contributed via
> https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)?
> Sean Mullan ha
as *.patch
files in mail attachments.
Anyway, OCA was approved again and the PR
(https://github.com/openjdk/jdk/pull/218) is ready for review :)
Cheers,
Sergey
17.09.2020, 14:11, "David Holmes" :
> On 17/09/2020 7:24 pm, Сергей Цыпанов wrote:
>> Hi David,
>>
>> th
Hello,
is it possible to have a code review for the changes proposed in JDK-8251548
(originally contributed via
https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)?
Sean Mullan has created an issue and web-review and can sponsor the patch as
soos as it gets properly
:22, "David Holmes" :
> Hi Sergey,
>
> Since OpenJDK has moved to git/github, this needs to reformulated as a
> Pull Request (PR).
>
> Cheers,
> David
>
> On 17/09/2020 5:19 pm, Сергей Цыпанов wrote:
>> Hello,
>>
>> is it possible to have a
Hello,
is it possible to have a code review for the changes proposed in JDK-8251548?
Sean Mullan has created an issue and web-review and can sponsor the patch
as soos as it gets properly reviewed.
As Doug Lea claims in
Cool, thanks!
Do you know anyone who could sponsor this and create a web-review against the
patch?
Regards,
Sergeyt Tsypanov
13.08.2020, 19:22, "Sean Mullan" :
> On 8/13/20 9:04 AM, Сергей Цыпанов wrote:
>> Hi,
>>
>> I don't have account in JBS, so I cannot f
I've mentioned in previous mail:
https://bugs.openjdk.java.net/browse/JDK-8145680
Regards,
Sergey Tsypanov
13.08.2020, 14:05, "Sean Mullan" :
> On 8/13/20 7:04 AM, Сергей Цыпанов wrote:
>> Hello,
>>
>> previously I've sent an email regarding removal of redun
Hello,
previously I've sent an email regarding removal of redundant assignments if
default values to volatile fields, see
https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html
There was a concern whether it's completely safe to remove those assignments
from JMM point of
Hello,
while investigating an issue I've found out that assignment of default value to
volatile fields slows down object instantiation.
Consider the benchmark:
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
@Fork(jvmArgsAppend = {"-Xms2g",
80 matches
Mail list logo
