RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v17]
Vladimir Sitnikov
vsitnikov at openjdk.org
Fri Dec 22 13:57:02 UTC 2023
On Fri, 22 Dec 2023 13:19:46 GMT, Markus KARG <duke at openjdk.org> 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 since the last revision:
>>
>> - Merge branch 'master' into 8320971
>> - 8320971: Inline tests
>> - 8322292: Remove TransferToTrusted.checkedOutputStream()
>> - 8320971: Adjust JavaDoc
>> - Merge branch 'master' into 8320971
>> - 8320971: Revert irrelevant changes
>> - 8320971: Add more tests
>> - 8320971: Fix JavaDoc
>> - 8320971: Whitespaces
>> - 8320971: Fix build
>> - ... and 12 more: https://git.openjdk.org/jdk/compare/d38d95d8...ee035998
>
> 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 look into `BIS::transferTo()` then you will notice that in case you call `bis.mark()` then your optimization will effectively *not getting called at all*, due to this line: https://github.com/openjdk/jdk/pull/16879/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1L643. So Brian's comment still applies and you should fix your test before this PR can be accepted for a merge (hence: you MUST get rid of `mark()`).
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 probably allow only a very small allocation in `.transferTo`.
Does `com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes()` sound right for the test?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1435074076
More information about the core-libs-dev
mailing list