?On 2023-08-16 13:37, Сергей Цыпанов wrote: Hello, I was measuring costs of hoisting volatile access out of the loop and found out, that there's a difference in numbers for arrays and "plain" references. Here's the benchmark for array: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit
decreases from 98 to 7 ns.
> If I read the data correctly, for the count=100 case in jdk 20 it takes
> 109 ns/op for the array and 74 ns/op for the field.
>
> To me this looks like a field access is _less_ expensive.
>
> Am I missing something?
>
> On 2023-08-16 13:37,
Hello,
I was measuring costs of hoisting volatile access out of the loop and found
out, that there's a difference in numbers for arrays and "plain" references.
Here's the benchmark for array:
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(time = 2, iterations =
Hello,
originally this question was asked here:
https://stackoverflow.com/q/76260269/12473843,
the code sample for reproduction will be put below or can be found via the link
The issue is about eager/lazy loading of a class depending on method return
type.
If one runs the code below with Java
On Mon, 17 Oct 2022 10:19:26 GMT, Сергей Цыпанов wrote:
>> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance
>> is constructed without comparator. This allows to squash two branches in
>> `TreeMap.get()` into one.
>>
>
On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu wrote:
> Issue: Duplication of methods between Basic*.java test classes, due to auto
> generation by genBasic.sh
>
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java.
> Toggled -nel flag for generation script
On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu wrote:
> Issue: Duplication of methods between Basic*.java test classes, due to auto
> generation by genBasic.sh
>
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java.
> Toggled -nel flag for generation script
nchmark.readLong 1 avgt 10 201,726 ±
> 8,885 us/op
> RandomAccessFileReadBenchmark.readLong 5 avgt 10 667,117 ±
> 6,779 us/op
> RandomAccessFileReadBenchmark.readShort1 avgt 10 560,259 ±
> 16,783 us/op
> RandomAccessFileRead
On Mon, 17 Oct 2022 19:42:14 GMT, liach wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8293630: Inline natural()
>
> src/java.base/share/classes/java/util/Tree
uld we also change it?
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8293630: Inline natural()
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9901/files
- new: https://git.openjdk.org/jdk/pull/9901/files/a55957e9.
On Sun, 16 Oct 2022 19:43:54 GMT, Tagir F. Valeev wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/java.base/share/classes/java/util/TreeMap.java
>>
>> Co-
On Sun, 21 Aug 2022 06:29:43 GMT, Сергей Цыпанов wrote:
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> fie
uld we also change it?
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/classes/java/util/TreeMap.java
Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
-
Changes:
- all:
On Thu, 13 Oct 2022 21:46:15 GMT, ExE Boss wrote:
>> Nope, there'd be a compilation error
>
> It'll work fine if an unchecked cast is used:
> Suggestion:
>
> @SuppressWarnings("unchecked")
> Comparator> entryComparator = treeComparator ==
> null ?
>
uld we also change it?
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/classes/java/util/TreeMap.java
Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
-
Changes:
- all:
On Wed, 17 Aug 2022 11:23:57 GMT, Сергей Цыпанов wrote:
> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is
> constructed without comparator. This allows to squash two branches in
> `TreeMap.get()` into one.
>
> P.S. I th
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing
On Sun, 2 Oct 2022 20:45:02 GMT, Сергей Цыпанов wrote:
> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is
> unused and should be removed in order to prevent allocations from
> `Method.getExceptionTypes()`
Is it going to be covered with new reflection
On Tue, 4 Oct 2022 11:55:02 GMT, Claes Redestad wrote:
>> @mlchung I can put here a stack trace of the application invoking the code
>> if you are interested
>
> @stsypanov would be helpful to understand when this code still gets executed.
> Also note that JEP 416 was integrated in JDK 18 so
On Mon, 3 Oct 2022 16:44:56 GMT, Mandy Chung wrote:
>> I agree that getting rid of the clone can help -- but since [JEP
>> 416](https://openjdk.org/jeps/416) the generators modified here is mostly a
>> fallback and the bulk of the use will use `MethodHandles` (unless you
>> disable JEP 416
On Sun, 2 Oct 2022 20:45:02 GMT, Сергей Цыпанов wrote:
> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is
> unused and should be removed in order to prevent allocations from
> `Method.getExceptionTypes()`
This pull request has now been integrated.
On Sun, 2 Oct 2022 22:16:46 GMT, Claes Redestad wrote:
>> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is
>> unused and should be removed in order to prevent allocations from
>> `Method.getExceptionTypes()`
>
> Seems reasonable, although these generators should only
`checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is
unused and should be removed in order to prevent allocations from
`Method.getExceptionTypes()`
-
Commit messages:
- 8294698: Remove unused 'checkedExceptions' param from
On Thu, 29 Sep 2022 22:29:43 GMT, Brent Christian wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Tweak indentation in PaternEntry
>
> src/java.base/share/classes/java/text/PatternEntry.java line 291:
>
>> 289:
On Thu, 29 Sep 2022 22:29:43 GMT, Brent Christian wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Tweak indentation in PaternEntry
>
> src/java.base/share/classes/java/text/PatternEntry.java line 291:
>
>> 289:
On Fri, 30 Sep 2022 11:46:39 GMT, Claes Redestad wrote:
>> Move a simple utility method from `URL` to the shared `sun.net.util.URLUtil`
>> class, rename it for clarity and enhance it so that it returns the string
>> literal if the protocol matches one of the tested variants. This helps
>>
On Fri, 26 Aug 2022 20:59:57 GMT, Сергей Цыпанов wrote:
>> Currently some operations of RandomAccessFile are implemented with multiple
>> read() invocations:
>>
>> public final int readInt() throws IOException {
>> int ch1 = this.read();
>> i
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing
On Tue, 13 Sep 2022 20:04:08 GMT, Bernd wrote:
> Does that mean there is no explicit test for DataInputStream endianess
@ecki I think this is not strictly necessary as order of bytes is explicitly
specified in JavaDoc of `DataInput` implemented by `DataInputStream`
-
PR:
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>>
>> public final int readInt() throws IOException {
>> readFully(readBuffer, 0, 4);
>> return (readBuffer[0] & 0xff) << 24
>> + (readBuffer[1]
On Mon, 12 Sep 2022 12:35:30 GMT, Andrey Turbanov wrote:
> Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often
> can be simplified by using their pair methods
> `parseInt`/`parseBoolean`/`parseLong`.
Marked as reviewed by stsypa...@github.com (no known OpenJDK
On Tue, 7 Jun 2022 13:45:06 GMT, Сергей Цыпанов wrote:
> Instead of `Executable.getParameterTypes()` we could use
> `Executable.getSharedParameterTypes()` in trusted code. Same is applicable
> for `Executable.getExceptionTypes()`.
This pull request has now been integrated.
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>>
>> public final int readInt() throws IOException {
>> readFully(readBuffer, 0, 4);
>> return (readBuffer[0] & 0xff) << 24
>> + (readBuffer[1]
On Sat, 20 Aug 2022 16:37:29 GMT, liach wrote:
>> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance
>> is constructed without comparator. This allows to squash two branches in
>> `TreeMap.get()` into one.
>>
>> P.S. I think the comment of
We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is
constructed without comparator. This allows to squash two branches in
`TreeMap.get()` into one.
P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated.
Should we also change it?
-
On Wed, 7 Sep 2022 19:33:41 GMT, Roger Riggs wrote:
>> You can probably appreciate how hard it is to keep track of what's a copy
>> (and needs to be copied) and what's not through several levels of APIs. From
>> a security perspective, its better to spend a little extra at runtime, than
>> to
On Tue, 14 Jun 2022 19:36:51 GMT, Сергей Цыпанов wrote:
>> Instead of `Executable.getParameterTypes()` we could use
>> `Executable.getSharedParameterTypes()` in trusted code. Same is applicable
>> for `Executable.getExceptionTypes()`.
>
> Сергей Цыпанов has
On Tue, 6 Sep 2022 17:20:22 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert "HexPrinter::transferTo"
>
> This reverts commit
On Tue, 6 Sep 2022 12:50:50 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains ten commits:
>
> - proposal by Alan Bateman
> - modified locking
> -
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
Will this be reopened somewhen? The proposed changes
On Mon, 29 Aug 2022 08:55:06 GMT, Aleksey Shipilev wrote:
> `jmod`/`jlink` are executed during build time to produce the `jmod` and the
> base modules image. On slow hardware (Raspberry Pi -class, for example)
> and/or slow VMs (debug, interpreter-only, for example) this takes a while.
>
avgt 20 21,804 ± 0,197 us/op
>
> patch:
>
> Benchmark Mode Cnt Score Error Units
> DataInputStreamTest.readChar avgt 20 11,018 ± 0,089 us/op
> DataInputStreamTest.readInt avgt 20 5,608 ± 0,087 us/op
Сергей Цыпанов has updated the pull request with a new targ
On Sat, 27 Aug 2022 06:52:19 GMT, Alan Bateman wrote:
>> Сергей Цыпанов has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8292937: Fix error C2057
>> - 8292937: Remove unused method
>
> src/java.base
nchmark.readLong 1 avgt 10 201,726 ±
> 8,885 us/op
> RandomAccessFileReadBenchmark.readLong 5 avgt 10 667,117 ±
> 6,779 us/op
> RandomAccessFileReadBenchmark.readShort1 avgt 10 560,259 ±
> 16,783 us/op
> RandomAccessFileReadB
nchmark.readLong 1 avgt 10 201,726 ±
> 8,885 us/op
> RandomAccessFileReadBenchmark.readLong 5 avgt 10 667,117 ±
> 6,779 us/op
> RandomAccessFileReadBenchmark.readShort1 avgt 10 560,259 ±
> 16,783 us/op
> RandomAccessFileRead
On Fri, 26 Aug 2022 16:39:01 GMT, Brian Burkhalter wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8292937: Move logic into VM side
>
> src/java.base/share/native/libja
nchmark.readLong 1 avgt 10 201,726 ±
> 8,885 us/op
> RandomAccessFileReadBenchmark.readLong 5 avgt 10 667,117 ±
> 6,779 us/op
> RandomAccessFileReadBenchmark.readShort1 avgt 10 560,259 ±
> 16,783 us/op
> RandomAccessFileReadB
On Fri, 26 Aug 2022 12:56:50 GMT, Alan Bateman wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8292937: Move logic into VM side
>
> src/java.base/share/native/libjava/io_util.c lin
On Fri, 26 Aug 2022 01:49:06 GMT, Quan Anh Mai wrote:
>>> Maybe you can modify the read0 method to receive a width parameter
>>> additionally.
>>
>> @merykitty sorry, I don't get it. We already have `readBytes0()` returning
>> array. Why do we need to add a new param to `read0`?
>
>
nchmark.readLong 1 avgt 10 201,726 ±
> 8,885 us/op
> RandomAccessFileReadBenchmark.readLong 5 avgt 10 667,117 ±
> 6,779 us/op
> RandomAccessFileReadBenchmark.readShort1 avgt 10 560,259 ±
> 16,783 us/op
> RandomAccessFileRead
On Thu, 25 Aug 2022 17:14:20 GMT, Сергей Цыпанов wrote:
> Currently some operations of RandomAccessFile are implemented with multiple
> read() invocations:
>
> public final int readInt() throws IOException {
> int ch1 = this.read();
> int ch2 = this.read();
>
On Thu, 25 Aug 2022 17:58:05 GMT, Quan Anh Mai wrote:
> Maybe you can modify the read0 method to receive a width parameter
> additionally.
@merykitty sorry, I don't get it. We already have `readBytes0()` returning
array. Why do we need to add a new param to `read0`?
-
PR:
On Thu, 25 Aug 2022 17:31:05 GMT, Brian Burkhalter wrote:
>> Currently some operations of RandomAccessFile are implemented with multiple
>> read() invocations:
>>
>> public final int readInt() throws IOException {
>> int ch1 = this.read();
>> int ch2 = this.read();
>> int ch3 =
Currently some operations of RandomAccessFile are implemented with multiple
read() invocations:
public final int readInt() throws IOException {
int ch1 = this.read();
int ch2 = this.read();
int ch3 = this.read();
int ch4 = this.read();
if ((ch1 | ch2 | ch3 | ch4) < 0)
On Sun, 21 Aug 2022 20:07:10 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing
On Tue, 23 Aug 2022 17:12:50 GMT, Alan Bateman wrote:
> The main thing is to think through the implications for async close where the
> close method replaces 'in'.
Suppose we have a scenario where `in` is replaced asynchronously in one of
implementations and the implementation is passed into
On Tue, 23 Aug 2022 13:57:35 GMT, Daniel Fuchs wrote:
> I agree that caution is warranted
But assuming I've reverted the changes that are dubious, how could there be
bugs caused by replacement of multiple reads with a single one? I was sure that
such replacement improves thread safety as soon
avgt 20 21,804 ± 0,197 us/op
>
> patch:
>
> Benchmark Mode Cnt Score Error Units
> DataInputStreamTest.readChar avgt 20 11,018 ± 0,089 us/op
> DataInputStreamTest.readInt avgt 20 5,608 ± 0,087 us/op
Сергей Цыпанов has updated the pull request incre
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Thanks!
---
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Thanks!
---
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Thanks!
---
On Fri, 15 Jul 2022 12:03:13 GMT, Сергей Цыпанов wrote:
> Simplify code with `String.join()`
This pull request has now been integrated.
Changeset: 9a65524e
Author:Sergey Tsypanov
Committer: Claes Redestad
URL:
https://git.openjdk.org/jdk/com
On Fri, 15 Jul 2022 12:03:13 GMT, Сергей Цыпанов wrote:
> Simplify code with `String.join()`
This pull request has now been integrated.
Changeset: 9a65524e
Author:Sergey Tsypanov
Committer: Claes Redestad
URL:
https://git.openjdk.org/jdk/com
On Fri, 15 Jul 2022 12:03:13 GMT, Сергей Цыпанов wrote:
> Simplify code with `String.join()`
This pull request has now been integrated.
Changeset: 9a65524e
Author:Sergey Tsypanov
Committer: Claes Redestad
URL:
https://git.openjdk.org/jdk/com
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Anyone to sponso
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Anyone to sponso
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Anyone to sponso
avgt 20 21,804 ± 0,197 us/op
>
> patch:
>
> Benchmark Mode Cnt Score Error Units
> DataInputStreamTest.readChar avgt 20 11,018 ± 0,089 us/op
> DataInputStreamTest.readInt avgt 20 5,608 ± 0,087 us/op
Сергей Цыпанов has updated the pull request increment
On Sun, 21 Aug 2022 06:29:43 GMT, Сергей Цыпанов wrote:
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> fie
I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream`
(as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can
be significantly improved by accessing volatile `in` field only once per
operation.
Current implementation does it for each call of
On Thu, 11 Aug 2022 06:53:16 GMT, Andrey Turbanov wrote:
> Field `keyListener` was added under
> [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its
> usages were removed in
> [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)
LGTM
-
Marked as
On Tue, 14 Jun 2022 19:36:51 GMT, Сергей Цыпанов wrote:
>> Instead of `Executable.getParameterTypes()` we could use
>> `Executable.getSharedParameterTypes()` in trusted code. Same is applicable
>> for `Executable.getExceptionTypes()`.
>
> Сергей Цыпанов has
On Fri, 5 Aug 2022 07:07:57 GMT, Andrey Turbanov wrote:
> There are couple places where new byte array is allocated and then thrown
> away.
Marked as reviewed by stsypa...@github.com (no known OpenJDK username).
-
PR: https://git.openjdk.org/jdk/pull/9767
On Fri, 5 Aug 2022 07:07:57 GMT, Andrey Turbanov wrote:
> There are couple places where new byte array is allocated and then thrown
> away.
Nice catch!
-
Marked as reviewed by stsypa...@github.com (no known OpenJDK username).
PR: https://git.openjdk.org/jdk/pull/9767
On Mon, 13 Jun 2022 18:42:24 GMT, Сергей Цыпанов wrote:
> If there are two threads calling `Executable.hasRealParameterData()` under
> race and the first one writes into volatile `Executable.parameters` field
> (doing _releasing store_) and the second thread reads non-null v
On Tue, 2 Aug 2022 17:48:07 GMT, Peter Levart wrote:
>> Let's wait a bit
>
> @stsypanov Do you need a sponsor or are you waiting for some other reviewer?
@plevart I don't think we need any more review for the change is simple
-
PR: https://git.openjdk.org/jdk/pull/9143
On Thu, 30 Jun 2022 12:08:19 GMT, Сергей Цыпанов wrote:
>> If there are two threads calling `Executable.hasRealParameterData()` under
>> race and the first one writes into volatile `Executable.parameters` field
>> (doing _releasing store_) and the second thread reads n
On Mon, 1 Aug 2022 17:35:05 GMT, David Schlosnagle wrote:
>> I would like to contribute an optimized version of
>> `StackTraceElement#toString()` that uses a single StringBuilder throughout
>> creation to avoid intermediate `String` allocations.
>> `StackTraceElement#toString()` is used in a
On Thu, 28 Jul 2022 13:45:53 GMT, David Schlosnagle wrote:
>> I think in this case it's better to specify `StringBuilder` instead of
>> `Appendable`, because the method is private and you'd hardly ever pass there
>> anything different from SB.
>
> If we go with the proposal above to make
On Thu, 28 Jul 2022 14:38:50 GMT, Carter Kozak wrote:
>> `Throwable.printStackTrace()` will use `StringBuilder` as well, won't it?
>
> I don't think so, it appends directly do something like System.err (default)
> or another PrintStream/PrintWriter without fully holding the string value on
>
On Thu, 28 Jul 2022 13:07:01 GMT, David Schlosnagle wrote:
>> src/java.base/share/classes/java/lang/StackTraceElement.java line 400:
>>
>>> 398: dest.append(fileName)
>>> 399: .append(':')
>>> 400:
On Wed, 27 Jul 2022 22:56:39 GMT, David Schlosnagle wrote:
> I would like to contribute an optimized version of
> `StackTraceElement#toString()` that uses a single StringBuilder throughout
> creation to avoid intermediate `String` allocations.
> `StackTraceElement#toString()` is used in a
On Mon, 1 Aug 2022 16:20:25 GMT, David Schlosnagle wrote:
>> If the objective of this patch is to optimise
>> `StackTraceElement::toString()`, then I would suggest the most efficient
>> method of calculating the length and encoding of the result, filling the
>> backing buffer then using the
Hi, I've noticed that in most of the code outside of JDK an InputStream taken from FileURLConnection is either read entirely e.g.in ASM's ClassLoader or passed into Properties where it's read with LineReader (which itself has an internal buffer). Apart from mark/reset activity we need buffering
On Thu, 21 Jul 2022 15:37:40 GMT, Сергей Цыпанов wrote:
> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/9596
On Mon, 25 Jul 2022 06:40:49 GMT, Сергей Цыпанов wrote:
>> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8278461: Reve
On Mon, 25 Jul 2022 06:40:49 GMT, Сергей Цыпанов wrote:
>> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8278461: Reve
> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8278461: Revert X509CertPath
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9
> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8278461: Revert X509CertPath
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9
On Thu, 23 Jun 2022 19:32:44 GMT, Andrey Turbanov wrote:
> Use `InputStream.readAllBytes` instead of manually written method.
>
> Skipped this method in
> [JDK-8080272](https://bugs.openjdk.org/browse/JDK-8080272)
Marked as reviewed by stsypa...@github.com (no known OpenJDK username).
On Sat, 23 Jul 2022 18:10:15 GMT, Andrey Turbanov wrote:
>> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
>
> Ow. I've created similar PR for `X509CertPath` recently #9263
@turbanoff I'll then remove the mentioned piece from this PR
-
PR:
On Sat, 23 Jul 2022 18:10:15 GMT, Andrey Turbanov wrote:
>> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
>
> Ow. I've created similar PR for `X509CertPath` recently #9263
@turbanoff I'll then remove the mentioned piece from this PR
-
PR:
On Fri, 1 Jul 2022 08:06:10 GMT, Сергей Цыпанов wrote:
> In case we read all bytes from an `InputStream` we don't need wrapping with
> `BufferedInputStream` as the bytes are not written into internal buffer. With
> removal of redundant buffer we save 8 kB of allocated memory.
On Thu, 21 Jul 2022 15:37:40 GMT, Сергей Цыпанов wrote:
> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
Could one advise how to execute smth like `jmod hash --module-path
~/openjdk-18.0.2/Contents/Home/jmods --hash-modules .*`? This command doesn't
work for
On Thu, 21 Jul 2022 15:37:40 GMT, Сергей Цыпанов wrote:
> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
Could one advise how to execute smth like `jmod hash --module-path
~/openjdk-18.0.2/Contents/Home/jmods --hash-modules .*`? This command doesn't
work for
On Thu, 21 Jul 2022 21:14:44 GMT, Mark Reinhold wrote:
> Please revise the summary to say “... instead of explicit loops”.
Done.
> Please measure this (using, e.g., [JMH](https://github.com/openjdk/jmh))
> before making such a change.
I'm aware of JMH, I was asking mostly about public API I
On Thu, 21 Jul 2022 21:14:44 GMT, Mark Reinhold wrote:
> Please revise the summary to say “... instead of explicit loops”.
Done.
> Please measure this (using, e.g., [JMH](https://github.com/openjdk/jmh))
> before making such a change.
I'm aware of JMH, I was asking mostly about public API I
On Thu, 21 Jul 2022 15:37:40 GMT, Сергей Цыпанов wrote:
> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
By "surrogate code" I mean hand-written snippets reading all the bytes from an
InputStream.
> It means the whole content from the inpu
On Thu, 21 Jul 2022 15:37:40 GMT, Сергей Цыпанов wrote:
> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
By "surrogate code" I mean hand-written snippets reading all the bytes from an
InputStream.
> It means the whole content from the inpu
We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
-
Commit messages:
- 8290824: Remove unused JavaDoc
- 8290824: Use InputStream.readAllBytes() instead of surrogate code
Changes: https://git.openjdk.org/jdk/pull/9596/files
Webrev:
1 - 100 of 947 matches
Mail list logo
