> It looks like we can skip copying of `byte[]` in
> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in
> `java.io`.
>
> See comment by @vlsi in
> https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
Serge
On Fri, 22 Dec 2023 09:55:15 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
>> https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1b
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
>> commits
On Fri, 22 Dec 2023 13:53:42 GMT, Vladimir Sitnikov
wrote:
>> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 68:
>>
>>> 66:
>>> 67: var bis = new BufferedInputStream(new
>>> ByteArrayInputStream(dup));
>>> 68: bis.mark(dup.length);
>>
>> If you take a closer
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
>> should
On Fri, 22 Dec 2023 14:37:26 GMT, Vladimir Sitnikov
wrote:
>> I think there is a misundertanding. This PR is not intendend to reduce the
>> *amount* of allocated heap, it is about sparing time by not creating
>> *temporary copies*. The latter should be rather easy to check: Invoke
>> `transf
On Fri, 22 Dec 2023 16:25:29 GMT, Vladimir Sitnikov
wrote:
>> IMHO the trigger for this PR was sparing *time*, not necessarily sparing
>> *bytes* (the default buffer size is just 8K); the latter certainly is a nice
>> and beneficial side effect. But I may be wrong here, then the original
>> c
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 dur
On Sat, 23 Dec 2023 15:02:28 GMT, Vladimir Sitnikov
wrote:
>> Why do you want to put *that* in a test case at all? So far I did not come
>> across performance-based *tests* (only *benchmarks*), i. e. nobody ever
>> requested that from me in any of my NIO optimizations. Typically it was
>> suf
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 the
10 matches
Mail list logo