On Mon, 30 May 2022 05:29:01 GMT, Alan Bateman wrote:
>> More practically.
>> This PR has a noticeable negative effect - it increases the size of
>> InputStream objects. Moreover, it increases the size of InputStream
>> subclasses which has own skip() implementation and don't need this
>> supe
On Mon, 30 May 2022 05:29:01 GMT, Alan Bateman wrote:
> However, I think your suggestion to change the no-arg read/write be
> non-abstract is interesting as it's always a pain to have to implement that.
@AlanBateman this need a csr IMO?
-
PR: https://git.openjdk.java.net/jdk/pull
On Sun, 29 May 2022 18:15:52 GMT, Sergey Kuksenko wrote:
> 5. skip() is not implemented, when not-so-trivial implementation is possible
> (9 classes):
For the low-level streams (e.g. connected to socket) then it would be common to
see them wrapped by buffered streams. So it might not be worth
On Sun, 29 May 2022 18:23:03 GMT, Sergey Kuksenko wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> invert if; refine javadoc.
>
> Another InputStreams cleaning direction.
>
> Many InputStream subclasses have read(byte
On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Thu, 26 May 2022 15:43:57 GMT, XenoAmess wrote:
> > Is there any practical scenario where the current code (skip buffer
> > allocation on each invocation) creates issues?
>
> @kuksenko Not found any yet :)
In that case, what is the value of this PR? Do we need a code change for the
sake of
On Wed, 25 May 2022 23:23:13 GMT, Sergey Kuksenko wrote:
> Is there any practical scenario where the current code (skip buffer
> allocation on each invocation) creates issues?
@kuksenko Not found any yet :)
-
PR: https://git.openjdk.java.net/jdk/pull/5872
On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Fri, 20 May 2022 21:15:23 GMT, Roger Riggs wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add documents
>
> src/java.base/share/classes/java/io/InputStream.java line 78:
>
>> 76: SoftReference ref = this.
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
invert if; refine javadoc.
-
Changes:
- all: https://git.openjdk.java
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine javadoc, remove The "notice..." statement
-
Changes:
- all: ht
On Fri, 20 May 2022 21:08:51 GMT, Roger Riggs wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add documents
>
> src/java.base/share/classes/java/io/InputStream.java line 72:
>
>> 70: *
>> 71: * @param size
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
rename function skipBufferReference to skipBuffer
-
Changes:
- all: h
On Fri, 20 May 2022 21:05:07 GMT, Roger Riggs wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add documents
>
> src/java.base/share/classes/java/io/InputStream.java line 75:
>
>> 73: * @return the byte array.
>>
On Wed, 20 Apr 2022 16:52:31 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add documents
src/ja
On Wed, 20 Apr 2022 16:36:16 GMT, XenoAmess wrote:
>>> no, we use other way, but yes for we take care of thread safety.
>>
>> Fair enough.
>>
>>> Don't think it necessary... I think making it cannot touched by other
>>> object (with security manager on) is enough.
>>
>> I was thinking more fo
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
add documents
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull
On Wed, 20 Apr 2022 16:35:25 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove uselsee MIN_SKIP_BUFFER_SIZE
>
> src/java.base/share/classes/java/io/InputStream.java line 62:
>
>> 60:
>> 61: priva
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
skipBufferReference(long) -> skipBufferReference(int)
-
Changes:
- al
On Wed, 20 Apr 2022 16:30:19 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove uselsee MIN_SK
On Tue, 19 Apr 2022 22:37:21 GMT, jmehrens wrote:
>>> > @jmehrens what about this then? I think it safe now(actually this
>>> > mechanism is learned from Reader)
>>>
>>> Reader uses a lock object and it appears that InputStream locks on this
>>> (per make/reset) I would assume now that you hav
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
comment added.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pul
On Wed, 20 Apr 2022 16:16:05 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove useless skipBuffer
>
> src/java.base/share/classes/java/io/InputStream.java line 57:
>
>> 55: private static final in
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
remove uselsee MIN_SKIP_BUFFER_SIZE
-
Changes:
- all: https://git.ope
On Wed, 20 Apr 2022 16:07:17 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove useless skipBu
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
remove useless skipBuffer
-
Changes:
- all: https://git.openjdk.java.
On Tue, 19 Apr 2022 22:47:42 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> change to liach operation.
>
> src/java.base/share/classes/java/io/InputStream.java line 62:
>
>> 60:
>> 61: /** Skip buffe
On Fri, 15 Apr 2022 18:56:37 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change to liach opera
On Tue, 19 Apr 2022 18:04:03 GMT, XenoAmess wrote:
> no, we use other way, but yes for we take care of thread safety.
Fair enough.
> Don't think it necessary... I think making it cannot touched by other object
> (with security manager on) is enough.
I was thinking more for heapdumps due to ex
On Tue, 19 Apr 2022 18:04:03 GMT, XenoAmess wrote:
> Reader uses a lock object and it appears that InputStream locks on this (per
> make/reset) I would assume now that you have some object member fields you
> need to hold some lock while accessing those. Even though single thread
> access woul
On Mon, 18 Apr 2022 20:08:23 GMT, jmehrens wrote:
> > @jmehrens what about this then? I think it safe now(actually this mechanism
> > is learned from Reader)
>
> Reader uses a lock object and it appears that InputStream locks on this (per
> make/reset) I would assume now that you have some obj
On Fri, 15 Apr 2022 18:56:37 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change to liach opera
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
change to liach operation.
-
Changes:
- all: https://git.openjdk.java
On Thu, 14 Apr 2022 18:52:25 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> refine jmh
Now this
On Thu, 14 Apr 2022 17:41:38 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> refine jmh
Jmh Resu
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine jmh
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/58
On Wed, 13 Apr 2022 22:59:13 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add jmh
>
> test/micro/org/openjdk/bench/java/io/InputStreamSkipBenchmark.java line 54:
>
>> 52: @Benchmark
>> 53: publi
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine jmh
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/58
On Wed, 13 Apr 2022 15:09:27 GMT, Roger Riggs wrote:
>>> I recommend moving `nr` declaration from the beginning of the method to
>>> where it's actually used (here)
>>
>> @liach done.
>
> Sorry, I misunderstood your earlier comment: "Sounds reasonable and applied"
> as concurring with not re-al
On Wed, 13 Apr 2022 22:53:11 GMT, liach wrote:
> I suggest we actually write into the byte array to better simulate overheads
> (maybe by generating a number with `ThreadLocalRandom`).
This sounds reasonable, as each InputStream implementation always need to copy
it.
> To simulate overhead on
On Tue, 12 Apr 2022 23:35:06 GMT, liach wrote:
> Shouldn't be too problematic, as most skip usages in JDK as I see are
> skipping small number of bytes like 2 or 4, or like skipping over attributes
> of Java class files. A minimum skip buffer size isn't that helpful, as I
> don't think we ofte
On Thu, 14 Apr 2022 15:33:40 GMT, Roger Riggs wrote:
> > Why as it already be a unacceptable option for security reason?
>
> A shared (static) buffer would be visible to application controlled
> subclasses when the `read(buffer, 0, len)` method is called. The subclass
> could examine the buffe
On Thu, 14 Apr 2022 15:36:20 GMT, Roger Riggs wrote:
> Can you summarize the performance results and implications. Including the
> whole jmh run isn't necessary.
@RogerRiggs
In short, making such a cache can help performance, and the larger int skip
length people call `skip()`, the larger dif
On Wed, 13 Apr 2022 21:58:06 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add jmh
Can you summ
On Thu, 14 Apr 2022 04:09:48 GMT, XenoAmess wrote:
> Why as it already be a unacceptable option for security reason?
A shared (static) buffer would be visible to application controlled subclasses
when the `read(buffer, 0, len)` method is called.
The subclass could examine the buffer and see dat
On Thu, 14 Apr 2022 02:21:23 GMT, Bernd Eckenfels
wrote:
> If you consider doing benchmarks in detail maybe consider a static buffer,
> too? (Especially if it can be used in multiple implementations?)
Why as it already be a unacceptable option for security reason?
-
PR: https://g
, 2022 11:58:06 PM
An: core-libs-dev@openjdk.java.net
Betreff: Re: RFR: 8284638: store skip buffers in InputStream Object [v2]
On Wed, 13 Apr 2022 16:02:10 GMT, Alan Bateman wrote:
>>> @AlanBateman You are correct about this. But I wonder if this be a problem,
>>> why Reader class
On Wed, 13 Apr 2022 21:58:06 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add jmh
test/micro/o
On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> moving nr declaration
On Wed, 13 Apr 2022 16:02:10 GMT, Alan Bateman wrote:
>>> @AlanBateman You are correct about this. But I wonder if this be a problem,
>>> why Reader class can afford store a skip buffer for each Reader.
>>>
>>> Is there anything different in the situations about skipBuffer in Reader
>>> and In
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
add jmh
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5872/
On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> moving nr declaration
On Wed, 13 Apr 2022 15:03:22 GMT, Alan Bateman wrote:
>> This change may be problematic for servers with a large number connections
>> and an input stream for each connection. It could add up to 2k to the
>> footprint of each connection when skip is used.
>
>> @AlanBateman You are correct abou
On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> moving nr declaration
On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> moving nr declaration
On Wed, 13 Apr 2022 15:23:16 GMT, XenoAmess wrote:
> > On a side note for unifying the skip buffer implementation of reader vs
> > input stream: For the input stream subclasses in the JDK that have their
> > own skip with buffering logic (as described in
> > https://github.com/openjdk/jdk/pull
On Wed, 13 Apr 2022 15:20:06 GMT, liach wrote:
> On a side note for unifying the skip buffer implementation of reader vs input
> stream: For the input stream subclasses in the JDK that have their own skip
> with buffering logic (as described in
> https://github.com/openjdk/jdk/pull/5872#discus
On Wed, 13 Apr 2022 14:56:12 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> moving nr declaration
On Wed, 13 Apr 2022 15:03:22 GMT, Alan Bateman wrote:
>> This change may be problematic for servers with a large number connections
>> and an input stream for each connection. It could add up to 2k to the
>> footprint of each connection when skip is used.
>
>> @AlanBateman You are correct abou
On Wed, 13 Apr 2022 15:03:22 GMT, Alan Bateman wrote:
> > @AlanBateman You are correct about this. But I wonder if this be a problem,
> > why Reader class can afford store a skip buffer for each Reader.
> > Is there anything different in the situations about skipBuffer in Reader
> > and InputSt
On Wed, 13 Apr 2022 14:52:20 GMT, XenoAmess wrote:
>> It indeed is reallocated when the existing one is not large enough.
>
>> I recommend moving `nr` declaration from the beginning of the method to
>> where it's actually used (here)
>
> @liach done.
Sorry, I misunderstood your earlier comment
On Wed, 13 Apr 2022 14:36:17 GMT, Alan Bateman wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add MIN_SKIP_BUFFER_SIZE
>
> This change may be problematic for servers with a large number connections
> and an input s
On Wed, 13 Apr 2022 14:51:34 GMT, liach wrote:
>> The check for `skipBuffer.length < size` makes it appear that the buffer can
>> be re-allocated.
>> If it is allocated once then only the `skipBuffer == null` is needed.
>>
>> The code may be simpler if the 'size' variable is removed.
>>
>>
On Wed, 13 Apr 2022 14:45:31 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/java/io/InputStream.java line 557:
>>
>>> 555:
>>> 556: while (remaining > 0) {
>>> 557: nr = read(skipBuffer, 0, (int)Math.min(size, remaining));
>>
>> I recommend moving `nr` declaration f
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
moving nr declaration from the beginning of the method to where it's actually
used
On Tue, 12 Apr 2022 23:13:26 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add MIN_SKIP_BUFFER_SIZE
>
> src/java.base/share/classes/java/io/InputStream.java line 557:
>
>> 555:
>> 556: while (re
On Wed, 13 Apr 2022 14:36:17 GMT, Alan Bateman wrote:
> This change may be problematic for servers with a large number connections
> and an input stream for each connection. It could add up to 2k to the
> footprint of each connection when skip is used.
@AlanBateman
You are correct about this.
On Tue, 12 Apr 2022 22:19:18 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add MIN_SKIP_BUFFER_S
On Tue, 12 Apr 2022 22:15:22 GMT, XenoAmess wrote:
> What subclasses of InputStream in the JDK do not override skip(n)?
>From a peek, the majority of subclasses do not override `skip(long)`. Most
>overrides are delegations or optimizations for random access structures; but
>there are some that
On Tue, 12 Apr 2022 22:19:18 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add MIN_SKIP_BUFFER_S
On Tue, 12 Apr 2022 20:39:52 GMT, Roger Riggs wrote:
> Without specific information about use cases, there isn't enough information
> to craft a good algorithm/solution and simplicity is preferred. The
> MAX_SKIP_BUFFER_SIZE is 2048 (not 8192).
>
> What subclasses of InputStream in the JDK do
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
add MIN_SKIP_BUFFER_SIZE
-
Changes:
- all: https://git.openjdk.java.n
On Tue, 12 Apr 2022 18:00:18 GMT, XenoAmess wrote:
>> Is this change proposed as the result of some experience with particular
>> apps and streams or just observation of the implementation?
>>
>> Is there any information about what kind of underlying streams do not
>> support skip directly
>>
On Mon, 11 Apr 2022 22:58:19 GMT, Roger Riggs wrote:
> Is this change proposed as the result of some experience with particular apps
> and streams or just observation of the implementation?
just observation of the implementation of InputStream class and Reader class,
and somehow wonder why the
On Mon, 11 Apr 2022 22:40:31 GMT, liach wrote:
>> Isn't it the case that the length of the global `skipBuffer` is
>> non-decreasing? Thus skipping 6 bytes after skipping 10 will not result in a
>> new buffer allocation.
>>
>> Even so, it does appear that prior buffer allocations could be "lost
On Mon, 11 Apr 2022 22:31:01 GMT, Brian Burkhalter wrote:
> Even so, it does appear that prior buffer allocations could be "lost" due to
> concurrent use of skip resulting in a "minor" memory leak in the heap.
The minor leak, though maybe somewhat wasteful, is the necessary cost for
thread saf
On Sat, 9 Oct 2021 19:02:17 GMT, XenoAmess wrote:
>>> in extream situation, when doing this.skipBuffer = skipBuffer in Thread B,
>>> it might make this.skipBuffer to a byte[6] in thread A, and thus cause a
>>> IndexOutofBoundException in Thread A.
>>
>> No, it won't. The later `skipBuffer` ref
On Sat, 9 Oct 2021 18:10:34 GMT, liach wrote:
> > in extream situation, when doing this.skipBuffer = skipBuffer in Thread B,
> > it might make this.skipBuffer to a byte[6] in thread A, and thus cause a
> > IndexOutofBoundException in Thread A.
>
> No, it won't. The later `skipBuffer` reference
On Sat, 9 Oct 2021 17:08:50 GMT, XenoAmess wrote:
> in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, it
> might make this.skipBuffer to a byte[6] in thread A, and thus cause a
> IndexOutofBoundException in Thread A.
No, it won't. The later `skipBuffer` references are
On Sat, 9 Oct 2021 17:01:16 GMT, XenoAmess wrote:
>> You should really post your changes to jdk-dev at openjdk.java.net before
>> submitting these so you can know if a change is potentially good or bad.
>> Since jdk pull requests require issue numbers, you can ask people on the
>> list if this
On Sat, 9 Oct 2021 15:49:01 GMT, liach wrote:
> You should really post your changes to jdk-dev at openjdk.java.net before
> submitting these so you can know if a change is potentially good or bad.
> Since jdk pull requests require issue numbers, you can ask people on the list
> if this is a go
On Fri, 8 Oct 2021 21:19:36 GMT, XenoAmess wrote:
> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)
You should really post your changes to jdk-dev at openjdk.java.net before
submitting these so you can know if a change is potentially good or
83 matches
Mail list logo
