Re: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2]

2021-08-10 Thread Claes Redestad
On Tue, 10 Aug 2021 21:06:00 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), radix); >> result =

Re: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2]

2021-08-10 Thread Сергей Цыпанов
> 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

Re: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable

2021-08-10 Thread Сергей Цыпанов
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); >> >> Possibly a follow-up, but I think using `parseInt/-Long(nm,

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-10 Thread Claes Redestad
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: >

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-10 Thread Sergey Bylokhov
On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman wrote: > It would be useful to get up to date performance data on using Charset vs. > charset name. At least historically, the charset name versions were faster > (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)). The code in

Re: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable

2021-08-10 Thread Сергей Цыпанов
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 =

Integrated: 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic

2021-08-10 Thread Raffaello Giulietti
On Mon, 2 Aug 2021 19:59:57 GMT, Raffaello Giulietti wrote: > Hello, > > please review this tiny change in the implementation of > j.l.Math.floorMod(int, int). > > While the results are unaffected, all of > floorDiv(int, int) > floorDiv(long, long) > floorMod(long, long) > use x

Re: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable

2021-08-10 Thread Claes Redestad
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), radix); > result =

Integrated: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

2021-08-10 Thread Andrey Turbanov
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[] >

RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable

2021-08-10 Thread Сергей Цыпанов
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

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-10 Thread Alan Bateman
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: >

Re: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used [v2]

2021-08-10 Thread Per Liden
On Mon, 9 Aug 2021 19:59:21 GMT, Vladimir Ivanov wrote: >> Per Liden has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Private implies final > > src/java.base/share/classes/java/lang/ref/Reference.java line 379: > >> 377: >> 378:

Re: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used [v2]

2021-08-10 Thread Per Liden
> While fixing JDK-8270626 it was discovered that the C2 intrinsic for > `Reference.refersTo()` is not used as often as one would think. Instead C2 > often prefers using the native implementation, which is much slower which > defeats the purpose of having an intrinsic in the first place. > >

Integrated: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups

2021-08-10 Thread Matthias Baesken
On Thu, 17 Jun 2021 12:27:25 GMT, Matthias Baesken wrote: > Hello, please review this PR; it extend the OSContainer API in order to also > support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", > "memory" on some older Linux

Re: Issue with BuiltinClassLoader.ucp field not being visible

2021-08-10 Thread Luke Hutchison
On Tue, Aug 10, 2021 at 1:34 AM Luke Hutchison wrote: > Maybe that should be part of the Instrumentation class, so that it is only > accessible to Java agent code that is able to get a reference to an > Instrumentation object. > Actually I take that last part back, that would not be very

Re: Issue with BuiltinClassLoader.ucp field not being visible

2021-08-10 Thread Alan Bateman
On 10/08/2021 07:58, Luke Hutchison wrote: On Tue, Aug 10, 2021 at 12:51 AM Luke Hutchison wrote: Could a getURLClassPath() method please be added to BuiltInClassLoader? For security reasons, the getURLClassPath() method should return a copy of ucp, not the reference to ucp, to prevent the

Re: Issue with BuiltinClassLoader.ucp field not being visible

2021-08-10 Thread Luke Hutchison
On Tue, Aug 10, 2021 at 12:51 AM Luke Hutchison wrote: > Could a getURLClassPath() method please be added to BuiltInClassLoader? > For security reasons, the getURLClassPath() method should return a copy of ucp, not the reference to ucp, to prevent the caller from modifying the system classpath.

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v9]

2021-08-10 Thread Matthias Baesken
> Hello, please review this PR; it extend the OSContainer API in order to also > support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", > "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids > controller might not be