On Thu, 4 Jan 2024 18:35:49 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/BufferedInputStream.java line 650:
>>
>>> 648: } else {
>>> 649: // Prevent poisoning and leaking of buf
>>> 650: byte[] buffer =
On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter wrote:
> The final position instead of the number of bytes to write was being passed
> to `ByteArrayOuputStream.write(byte[],int,int)`.
src/java.base/share/classes/java/io/BufferedInputStream.java line 650:
> 648: } else {
>
On Sun, 17 Dec 2023 09:06:58 GMT, Alan Bateman wrote:
>> Sergey Tsypanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8320971: Revert irrelevant changes
>
> For the method description, I think you can expand it to:
>
> - does not
On Sat, 30 Dec 2023 17:43:25 GMT, Vladimir Sitnikov
wrote:
>> I assume you mean "to make it a blackbox"? Actually I do not see how we
>> could do that *reliably*, as I already wrote recently.
>
> `com.sun.management.ThreadMXBean#getCurrentThreadAllocatedBytes` is reliable,
> isn't it?
On Sat, 30 Dec 2023 16:44:14 GMT, Sergey Tsypanov wrote:
>> src/java.base/share/classes/java/io/BufferedInputStream.java line 672:
>>
>>> 670: * does not modify the contents of the {@code byte[]}
>>> 671: * {@code OutputStream.write(byte[], int, int)} write does not
>>> read the
On Sat, 23 Dec 2023 19:11:35 GMT, Sergey Tsypanov wrote:
>> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 83:
>>
>>> 81: var internalBuffer =
>>> bis.getClass().getDeclaredField("buf");
>>> 82: internalBuffer.setAccessible(true);
>>> 83:
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
>>
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
>>
On Thu, 28 Dec 2023 15:06:47 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, 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
>>
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
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
>>
On Tue, 19 Dec 2023 10:18:11 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, 20 Dec 2023 18:49:39 GMT, Brian Burkhalter wrote:
> > this icon only says that Alan made change requests
>
> I think it's if the "changes requested" button is selected in the "Submit
> Review" popup under "Files Changed."
Typically yes. But not in the current case: Alan pressed
On Wed, 20 Dec 2023 22:15:04 GMT, Jim Laskey wrote:
>> The new repeat methods were not clearing the toStringCache.
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Clear sooner
LGTM.
-
Marked as reviewed by
On Wed, 20 Dec 2023 17:57:57 GMT, Brian Burkhalter wrote:
> > But where do you see a change request from Alan _before_ I posted
> > `/integrate`?
>
> Mouse-over the icon to the right of his name at the top right under
> "Reviewers."
I might be wrong, but IMHO this icon only says that Alan
On Wed, 20 Dec 2023 16:52:38 GMT, Brian Burkhalter wrote:
> > Alan actually did approve them on December 15.
>
> I know, with requested changes. I didn't see the request transition to
> "Ready" which is where it needs to be to `/integrate`.
Looking at the Github history I need to say that I
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.
This pull request has now been integrated.
Changeset: 2d609557
Author: Markus KAR
On Tue, 19 Dec 2023 18:31:19 GMT, Brian Burkhalter wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test was using Integer but must use Long
>
> I verified that the test now f
On Tue, 19 Dec 2023 18:20:05 GMT, Brian Burkhalter wrote:
> Approved.
>
> Please note in future that it is better not to `/integrate` until the request
> has actually been approved by a Reviewer.
Alan actually did approve them on December 15.
-
PR Comment:
On Sat, 16 Dec 2023 19:10:49 GMT, Vladimir Sitnikov
wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test was using Integer but must use Long
>
> test/jdk/java/io/SequenceInputS
On Sat, 16 Dec 2023 19:09:05 GMT, Vladimir Sitnikov
wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test was using Integer but must use Long
>
> test/jdk/java/io/SequenceInputS
On Sat, 16 Dec 2023 19:03:26 GMT, Vladimir Sitnikov
wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test was using Integer but must use Long
>
> test/jdk/java/io/SequenceInputS
On Sun, 17 Dec 2023 07:49:16 GMT, Alan Bateman wrote:
> > Let's follow Alan's proposal and simply inline this.
>
> I didn't suggest inlining this. I just asked not to add a new package
> com.sun.io with a single method class. Also as the concerns with BAIS and BIS
> are not the same (they do
On Wed, 13 Dec 2023 08:41:37 GMT, Vladimir Sitnikov
wrote:
>> Sergey Tsypanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8320971: Fix JavaDoc
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 52:
>
>> 50:
On Sat, 16 Dec 2023 17:13:17 GMT, Chen Liang wrote:
>>> If we drop the method for now I have to write it later again, I guess
>>
>> Maybe, but it's archived so it's easy enough.
>
> If this is only used after Module system is ready, we can use something like:
>
On Thu, 14 Dec 2023 08:47:03 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 Sat, 16 Dec 2023 15:55:48 GMT, Brian Goetz wrote:
>> @mkarg , thank you for the review, I replied in JIRA to avoid mixing
>> comments across different issues:
>>
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
On Sat, 16 Dec 2023 07:24:59 GMT, Vladimir Sitnikov
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
> 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 last revision:
Test was using Integer but m
On Fri, 15 Dec 2023 22:40:17 GMT, Brian Burkhalter wrote:
>>> > [...] maybe we need to come up with tests that quickly check the handling
>>> > at this limit.
>>
>>> @mkarg Do you intend to provide any such test as part of this request?
>>
>> @bplb I quickly drafted an absolute minimal test
On Sat, 16 Dec 2023 08:56:16 GMT, Markus KARG wrote:
>> test/jdk/java/io/SequenceInputStream/TransferTo.java line 160:
>>
>>> 158: pos++;
>>> 159: return b;
>>> 160: }
>>
>> To trigger
On Sat, 16 Dec 2023 07:02:57 GMT, Vladimir Sitnikov
wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> New test asserts subsequent input stream is read when preceding stream
>> alread
On Fri, 15 Dec 2023 22:40:17 GMT, Brian Burkhalter wrote:
> This test does not fail for me when run against my local build of the current
> mainline. Usually, unless randomness is involved, a test should fail before
> the proposed patch is applied but succeed thereafter.
This is weird. How
On Fri, 15 Dec 2023 18:21:14 GMT, Brian Burkhalter wrote:
> > [...] maybe we need to come up with tests that quickly check the handling
> > at this limit.
> @mkarg Do you intend to provide any such test as part of this request?
@bplb I quickly drafted an absolute minimal test for this in
> 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 last revision:
New test asserts subsequent
On Fri, 15 Dec 2023 09:41:38 GMT, Jaikiran Pai wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Keep transferring beyond MAX_VALUE bytes
>
> src/java.base/share/classes/java/io/Seq
> 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 last revision:
Keep transferring beyond MAX
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.
@bplb Kindly requesting your sponsoring. :-)
-
PR Comment: https://git.ope
Fixes JDK-8322141
As suggested by @vlsi and documented by @bplb this PR does not return, but only
sets the maximum result value.
-
Commit messages:
- Fixes JDK-8322141
Changes: https://git.openjdk.org/jdk/pull/17119/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17119=00
On Thu, 14 Dec 2023 20:21:10 GMT, Vladimir Sitnikov
wrote:
>>> What do you think?
>>
>> I think that you are looking at an obsolete repository:
>>
>> https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/InputStream.java#L802
>
> I
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.
@bplb Kindly requesting your review.
-
PR Comment: https://git.openjdk.org/jd
On Thu, 14 Dec 2023 20:21:10 GMT, Vladimir Sitnikov
wrote:
>>> What do you think?
>>
>> I think that you are looking at an obsolete repository:
>>
>> https://github.com/openjdk/jdk/blob/c328f9589ddc3a981a2c63801bd991f8e593e69f/src/java.base/share/classes/java/io/InputStream.java#L802
>
> I
On Wed, 13 Dec 2023 15:53:09 GMT, Alan Bateman wrote:
> It doesn't make sense here to add a new package com.sun.io for a single
> method class. This PR does not need to introduce any new classes at this
> point. I think this PR needs to focus solely on BIS.
So you actually prefer
On Wed, 13 Dec 2023 10:01:30 GMT, Alan Bateman wrote:
>> So what is the target package for this utility class?
>
>> So what is the target package for this utility class?
>
> If you really want a utility class then a non-public class in java.io is
> okay. However, I think the starting point for
On Wed, 13 Dec 2023 08:41:37 GMT, Vladimir Sitnikov
wrote:
>> Sergey Tsypanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8320971: Fix JavaDoc
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 52:
>
>> 50:
On Tue, 12 Dec 2023 20:18: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
>>
On Tue, 12 Dec 2023 20:18: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
>>
On Mon, 11 Dec 2023 20:09:09 GMT, Sergey Tsypanov wrote:
>> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 212:
>>
>>> 210: // 'tmpbuf' is null if and only if 'out' is trusted
>>> 211: byte[] tmpbuf;
>>> 212: if (IOStreams.isTrusted(out))
On Mon, 11 Dec 2023 13:56:50 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 20:16:43 GMT, Sergey Tsypanov wrote:
>> src/java.base/share/classes/java/io/OutputStream.java line 212:
>>
>>> 210: * @return true if the argument of {@link #write(byte[])}} and
>>> {@link #write(byte[], int, int)}} needn't be copied
>>> 211: */
>>> 212:
On Fri, 8 Dec 2023 15:46:31 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 Tue, 5 Dec 2023 08:27:09 GMT, Alan Bateman wrote:
> I suspect it's left over from a previous iteration. In any case, limiting it
> to a small number of output streams makes this easier to look at. BAOS and
> FOS seem okay, POP seems okay too but legacy and not interesting.
Agreed for a
On Mon, 4 Dec 2023 20:16:12 GMT, Brian Burkhalter wrote:
>> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of
>> `BAIS.transferTo` only if the target stream is in the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Wed, 29 Nov 2023 22:55:41 GMT, Brian Burkhalter wrote:
> > As Alan pointed out, it is a bug (actually even a security risk), so BAIS
> > should get fixed, too.
>
> I am going to file an issue on this.
Thank you, I just planned to fix this today when I saw your existing PR!
-
On Fri, 1 Dec 2023 04:01:42 GMT, jmehrens wrote:
>> I might have done this incorrectly, but with this version of the above
>> `wolf` I do not see any corruption:
>>
>> java.nio.channels.WritableByteChannel wolf =
>> new java.nio.channels.WritableByteChannel() {
>>
On Thu, 30 Nov 2023 23:30:20 GMT, Brian Burkhalter wrote:
>> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of
>> `BAIS.transferTo` only if the target stream is in the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Wed, 29 Nov 2023 05:55:03 GMT, Vladimir Sitnikov
wrote:
>> src/java.base/share/classes/java/io/BufferedInputStream.java line 612:
>>
>>> 610: if (avail > 0) {
>>> 611: // Prevent poisoning and leaking of buf
>>> 612: byte[] buffer =
On Wed, 29 Nov 2023 22:49:17 GMT, Markus KARG wrote:
>> Buffer copy was not there before, and defensive copy was never present in
>> `ByteArrayInputStream` as well:
>> https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.base/sha
On Wed, 29 Nov 2023 19:59:03 GMT, Alan Bateman 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 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 20:07:37 GMT, Vladimir Sitnikov
wrote:
>>> What do you think of passing the buffer as is?
>>
>> No, it should only do for trusted targets. BAIS has an issue in that area
>> that should be fixed.
>
> The buffer in question is protected, so any subclass can directly access
his and can fix it?
Thanks
-Markus
Von: Aleksei Ivanov [mailto:alexey.iva...@oracle.com]
Gesendet: Donnerstag, 5. Oktober 2023 14:16
An: Markus Karg; core-libs
Cc: client-libs-...@openjdk.org
Betreff: Re: RFC: 8309726: Reader::readString
Hi Markus,
You posted it to the wrong
On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG wrote:
> I/O had always been much slower than CPU and memory access, and thanks to
> physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory
> cache on or nearby a CPU core,
On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG wrote:
> I/O had always been much slower than CPU and memory access, and thanks to
> physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory
> cache on or nearby a CPU core,
On Mon, 2 Jan 2023 10:03:02 GMT, Peter Levart wrote:
> Here, the benefit of increasing buffer from 8k to 16k gets from about 10%
> (doing IO) up to 20% (reading from cache) increase in performance.
I think 10% to 20% is good enough as an argument to go with 16k instead of 8k.
-
On Tue, 27 Dec 2022 14:55:31 GMT, Peter Levart wrote:
> Hello Markus! Could you show the JMH code that produced the benchmark results?
The following lines make use of a custom method I have added to `InputStream`
in a custom build of JDK 21, so JMH can control the size of the buffer. The
test
I/O had always been much slower than CPU and memory access, and thanks to
physical constraints, always will be.
While CPUs can get shrinked more and more, and can hold more and more memory
cache on or nearby a CPU core, the distance between CPU core and I/O device
cannot get reduced much: It
On Sat, 19 Nov 2022 16:36:28 GMT, Markus KARG wrote:
> Since JDK 18 some implementations of InputStream.transferTo, namely
> FileInputStream and ChannelInputStream, offload work to lower layers using
> NIO channels. This provides shorter execution time and reduced resource
>
On Tue, 29 Nov 2022 23:40:58 GMT, Brian Burkhalter wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed bug number
>
>> > Please take note of the changes proposed in #11403.
On Tue, 29 Nov 2022 23:40:58 GMT, Brian Burkhalter wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed bug number
>
>> > Please take note of the changes proposed in #11403.
On Wed, 7 Dec 2022 12:41:19 GMT, Markus KARG wrote:
>> Since JDK 18 some implementations of InputStream.transferTo, namely
>> FileInputStream and ChannelInputStream, offload work to lower layers using
>> NIO channels. This provides shorter execution time and reduced resour
On Tue, 6 Dec 2022 16:20:44 GMT, Brian Burkhalter wrote:
>> test/jdk/java/io/SequenceInputStream/TransferTo.java line 206:
>>
>>> 204: }
>>> 205:
>>> 206: }
>>
>> As auto-detected, there is no newline at the end of this file. Otherwise it
>> appears all right.
>
> @mkarg Please take
On Tue, 6 Dec 2022 16:20:44 GMT, Brian Burkhalter wrote:
>> test/jdk/java/io/SequenceInputStream/TransferTo.java line 206:
>>
>>> 204: }
>>> 205:
>>> 206: }
>>
>> As auto-detected, there is no newline at the end of this file. Otherwise it
>> appears all right.
>
> @mkarg Please take
kes sense to
> address this impediment: SequenceInputStream.transferTo should be implemented
> in a way that iteratively calls transferTo on each enumerated InputStream of
> the SequenceInputStream in ordered sequence.
Markus KARG has updated the pull request incrementally with one additional
On Tue, 29 Nov 2022 19:39:49 GMT, Brian Burkhalter wrote:
> Please take note of the changes proposed in #11403.
It might make sense to merge *this* PR as-is *first*, but then add the needed
fix to #11403 afterwards? Otherwise it might be confusing for a reader, why
#11403 is not covering SIS
On Mon, 21 Nov 2022 18:22:26 GMT, Jens Lidestrom wrote:
>> I think the public visibility of my Twitter account is not wide enough to
>> get *really robust* answers, unfortunately. So far, 92% answered that they
>> not even used SIS in their whole life. So the users of two-args constructor
>>
On Sun, 20 Nov 2022 09:41:47 GMT, Markus KARG wrote:
>> Since JDK 18 some implementations of InputStream.transferTo, namely
>> FileInputStream and ChannelInputStream, offload work to lower layers using
>> NIO channels. This provides shorter execution time and reduced resour
On Sat, 19 Nov 2022 21:36:56 GMT, Markus KARG wrote:
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
>
On Mon, 21 Nov 2022 07:42:35 GMT, Alan Bateman wrote:
>> N.B.: Regarding usage numbers, I will do a quick poll on Twitter.
>
>> Indeed my intention solely is to get rid of `Vector`, so I am fine with
>> keeping a low profile and being full backwards compatible. I assume SIS is
>> seldomly
On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote:
>> Markus KARG has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request co
On Mon, 21 Nov 2022 07:48:01 GMT, Markus KARG wrote:
> While we are at it, would you be willing to change the member variables `e`
> to `private final` and the `in` to `private`? From what I can see, I don't
> see any other class accessing these package private fields.
Fixed i
place Vector unless
> synchronization is really needed.
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
private member variables
-
Changes:
- all: https://git.openjdk.org/jdk/pull/11249/files
- new: https://git.openj
On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote:
> While we are at it, would you be willing to change the member variables `e`
> to `private final` and the `in` to `private`? From what I can see, I don't
> see any other class accessing these package private fields.
Good catch, will do
place Vector unless
> synchronization is really needed.
Markus KARG has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contains one new commit
since th
On Sun, 20 Nov 2022 16:49:16 GMT, Markus KARG wrote:
>>> @AlanBateman WDYT?
>>
>> The long standing and undocumented behavior is unfortunate. I don't think
>> the 1-arg constructor is fixable while still allowing for lazy behavior. So
>> I think the
place Vector unless
> synchronization is really needed.
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
Jens' Proposal
-
Changes:
- all: https://git.openjdk.org/jdk/pull/11249/files
- new: https://git.openjdk.org/jdk/p
On Sun, 20 Nov 2022 12:06:55 GMT, Markus KARG wrote:
>> The updated code now changes the behaviour in the other direction:
>>
>> In the original code, if `s2` was null a NPE was thrown in `peekNextStream`
>> when `s1` was exhausted.
>>
>> In the cu
On Sun, 20 Nov 2022 09:47:35 GMT, Jens Lidestrom wrote:
>> src/java.base/share/classes/java/io/SequenceInputStream.java line 82:
>>
>>> 80: * @param s2 the second input stream to read.
>>> 81: */
>>> 82: public SequenceInputStream(InputStream s1, InputStream s2) {
>>
>> BTW,
On Sun, 20 Nov 2022 07:30:15 GMT, Alan Bateman wrote:
> I might be mistaken, but that vector is not temporary: the vector and the
> enumeration produced from it seems to be reachable for as long as the stream
> is. Both the enumeration and the vector are synchronized. That
> synchronization
kes sense to
> address this impediment: SequenceInputStream.transferTo should be implemented
> in a way that iteratively calls transferTo on each enumerated InputStream of
> the SequenceInputStream in ordered sequence.
Markus KARG has updated the pull request incrementally with one addition
On Sun, 20 Nov 2022 07:45:11 GMT, Alan Bateman wrote:
>> Since JDK 18 some implementations of InputStream.transferTo, namely
>> FileInputStream and ChannelInputStream, offload work to lower layers using
>> NIO channels. This provides shorter execution time and reduced resource
>> consumption.
On Sun, 20 Nov 2022 09:07:21 GMT, Markus KARG wrote:
>> There is no need to use a temporary Vector within the constructor of
>> SynchronizedInputStream, as more efficient (non-synchronized) alternative
>> code (like List.of) will do the same in possibly less time. While th
On Sun, 20 Nov 2022 02:16:02 GMT, Jaikiran Pai wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> allowing s2 to be null
>
> src/java.base/share/classes/java/io/SequenceInpu
On Sun, 20 Nov 2022 07:56:59 GMT, Alan Bateman wrote:
> Jai is correct, this constructor appears to have tolerated null in the second
> parameter since JDK 1.0 so we need to proceed with care.
I have fixe this in
place Vector unless
> synchronization is really needed.
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
allowing s2 to be null
-
Changes:
- all: https://git.openjdk.org/jdk/pull/11249/files
- new: https://git.openjdk.org
There is no need to use a temporary Vector within the constructor of
SynchronizedInputStream, as more efficient (non-synchronized) alternative code
(like List.of) will do the same in possibly less time. While the optimization
is not dramatic, it still makes sense to replace Vector unless
Since JDK 18 some implementations of InputStream.transferTo, namely
FileInputStream and ChannelInputStream, offload work to lower layers using NIO
channels. This provides shorter execution time and reduced resource
consumption. Unfortunately, this effect is prevented once the input stream
On Fri, 4 Nov 2022 22:12:14 GMT, Markus KARG wrote:
> This PR implements JDK-8296431
This pull request has now been integrated.
Changeset: 95b84050
Author: Markus Karg
Committer: Brian Burkhalter
URL:
https://git.openjdk.org/jdk/commit/95b84050fc009b5665d20168d0470c9f31598d9a
St
1 - 100 of 194 matches
Mail list logo
