On Sat, 30 Dec 2023 17:37:25 GMT, Markus KARG wrote:
>> Done. Can we somehow modify the test to make it white-box one? Maybe it's
>> possible to measure memory allocation before and after method invocation in
>> the way that we could use the difference as a proof of non-allocating
>>
On Sat, 23 Dec 2023 13:01:09 GMT, Markus KARG wrote:
>Typically it was sufficient to document the JMH results before and after a PR
>just once (not dynamically in the form of a test).
The problem with "results before and after a PR just once" is those benchmarks
will not automatically fail
On Fri, 22 Dec 2023 15:08:33 GMT, Markus KARG wrote:
> IMHO the trigger for this PR was sparing time
That is fair. Do you know how one could create a reliable test for performance
that would fail without the fix and succeed with the fix?
I think the allocation is a reasonable proxy for the
On Fri, 22 Dec 2023 14:27:16 GMT, Markus KARG wrote:
>> Can anybody give a hint how one can create assertions in OpenJDK test code
>> that would check the amount of allocated heap for the tested method?
>>
>> Since the change here is "removal of an allocation", the assert in the code
>>
On Fri, 22 Dec 2023 13:19:46 GMT, Markus KARG wrote:
>> Sergey Tsypanov 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 22 additional
>>
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote:
>> Fixes JDK-8322141
>>
>> As suggested by @vlsi and documented by @bplb this PR does not return, but
>> only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote:
>> Fixes JDK-8322141
>>
>> As suggested by @vlsi and documented by @bplb this PR does not return, but
>> only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the
On Sat, 16 Dec 2023 14:52:42 GMT, Markus KARG wrote:
>> I've created a draft change for `OutputStream#write(ByteBuffer)`, and I have
>> benchmarked several cases including
>> `ByteArrayInputStream.transferTo(BufferedOutputStream(ByteArrayOutputStream))`,
>>
On Fri, 15 Dec 2023 18:37:53 GMT, Markus KARG wrote:
>> Fixes JDK-8322141
>>
>> As suggested by @vlsi and documented by @bplb this PR does not return, but
>> only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the
On Mon, 4 Dec 2023 14:05:14 GMT, Vladimir Sitnikov
wrote:
>>> > it doesn't solve the second part of the concern which is read-only view
>>> > on the internal buffer.
>>>
>>> I think `ByteBuffer.asReadOnlyBuffer()` should resolve the issues
On Fri, 15 Dec 2023 08:23:58 GMT, Markus KARG wrote:
> Fixes JDK-8322141
>
> As suggested by @vlsi and documented by @bplb this PR does not return, but
> only sets the maximum result value.
Marked as reviewed by vsitnikov (no project role).
-
PR Review:
On Thu, 14 Dec 2023 19:22:18 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/SequenceInputStream.java line 249:
>>
>>> 247: transferred = Math.addExact(transferred,
>>> in.transferTo(out));
>>> 248: } catch (ArithmeticException
On Fri, 10 Feb 2023 17:38:51 GMT, Brian Burkhalter wrote:
>> `java.io.InputStream::transferTo` could conceivably return a negative value
>> if the count of bytes transferred overflows a `long`. Modify the method to
>> limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.
>
On Wed, 13 Dec 2023 08:15:21 GMT, Sergey Tsypanov wrote:
>> It looks like we can skip copying of `byte[]` in
>> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in
>> `java.io`.
>>
>> See comment by @vlsi in
>>
On Fri, 8 Dec 2023 17:23:59 GMT, Markus KARG wrote:
>> Sergey Tsypanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8320971: Use same approach as BAOS
>
> src/java.base/share/classes/java/io/OutputStream.java line 212:
>
>> 210:
On Mon, 4 Dec 2023 13:58:45 GMT, Alan Bateman wrote:
>The backing array is not frozen so a read-only view doesn't address the second
>part of the concern where the target keeps a reference.
The users outside of OpenJDK would not have a reference to `byte[]`.
Do you mean a reference to
On Mon, 4 Dec 2023 13:16:25 GMT, Alan Bateman wrote:
>it doesn't solve the second part of the concern which is read-only view on the
>internal buffer.
I think `ByteBuffer.asReadOnlyBuffer()` should resolve the issues regarding
naked byte access. At least `ByteBuffer#array()` returns `null`
On Fri, 1 Dec 2023 14:05:37 GMT, Bernd wrote:
>> Did you review if all Java.* streams are safe?
>>
>> There are a few stream adapters in sun.nio.ch, which would benefit this
>> optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I
>> guess that’s not safe, so the
On Thu, 30 Nov 2023 08:58:18 GMT, Alan Bateman wrote:
>> I don't think checking if the package is java.io is secure:
>>
>> ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
>> BufferedInputStream bis = new BufferedInputStream(bais);
>> UntrustedOutputStream uos = new
On Wed, 29 Nov 2023 19:55:09 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/BufferedInputStream.java line 653:
>>
>>> 651: byte[] buffer = Arrays.copyOfRange(getBufIfOpen(),
>>> pos, count);
>>> 652: out.write(buffer);
>>> 653:
On Wed, 29 Nov 2023 11:57:37 GMT, Sergey Tsypanov wrote:
> It looks like we can skip copying of `byte[]` in
> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in
> `java.io`.
>
> See comment by @vlsi in
>
On Wed, 29 Nov 2023 05:48:58 GMT, Vladimir Sitnikov
wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Alternative C + Arrays.copyOfRange()
>
> src/java.base/share/classes/java/io/Buf
On Mon, 31 Oct 2022 13:30:13 GMT, Markus KARG wrote:
>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Alternative C + Arrays.copyOfRange()
On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie wrote:
>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
>> attempt to remove all trailing whitespace from properties files, and enable
>> a jcheck verification that they did not come back, similar to other
On Mon, 16 Jan 2023 18:52:24 GMT, Magnus Ihse Bursie wrote:
>> The non-client parts look fine.
>
> @RogerRiggs Thanks!
@magicus , have you considered adding `.editorconfig` file (see
https://editorconfig.org/ ) so it configures developers' editors to trim the
whitespace?
Of course,
25 matches
Mail list logo
