On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only on
On Wed, 5 Oct 2022 15:24:10 GMT, Сергей Цыпанов wrote:
> Anyone to sponsor, or should I get more approves?
I see that both Alan and Daniel have approved these changes and there hasn't
been a commit in this PR, after the approval (which is a good thing). I'll run
some internal tests and if all
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only on
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only on
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only on
On Wed, 14 Sep 2022 07:33:32 GMT, Сергей Цыпанов wrote:
> > Does that mean there is no explicit test for DataInputStream endianess
>
> @ecki I think this is not strictly necessary as order of bytes is explicitly
> specified in JavaDoc of `DataInput` implemented by `DataInputStream`
Hm, maybe I
On Tue, 13 Sep 2022 20:04:08 GMT, Bernd wrote:
> Does that mean there is no explicit test for DataInputStream endianess
@ecki I think this is not strictly necessary as order of bytes is explicitly
specified in JavaDoc of `DataInput` implemented by `DataInputStream`
-
PR: https://g
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
> > What is wrong with the change?
>
> You'll need parentheses to make that work, changing it to use '|' would work
> too.
Does that mean there is no explicit test for DataInputStream endianess (if only
accidential tests checking for magic
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>>
>> public final int readInt() throws IOException {
>> readFully(readBuffer, 0, 4);
>> return (readBuffer[0] & 0xff) << 24
>> + (readBuffer[1]
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>>
>> public final int readInt() throws IOException {
>> readFully(readBuffer, 0, 4);
>> return (readBuffer[0] & 0xff) << 24
>> + (readBuffer[1]
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only on
On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`:
>>
>> public final int readInt() throws IOException {
>> readFully(readBuffer, 0, 4);
>> return (readBuffer[0] & 0xff) << 24
>> + (readBuffer[1]
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> field only once per operation.
>
> Current implementation does it for each
On Thu, 25 Aug 2022 07:46:13 GMT, Сергей Цыпанов wrote:
> What is wrong with the change?
You'll need parentheses to make that work, changing it to use '|' would work
too.
-
PR: https://git.openjdk.org/jdk/pull/9956
On Sun, 21 Aug 2022 20:07:10 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only on
On Wed, 24 Aug 2022 06:17:19 GMT, Alan Bateman wrote:
> I can't imagine a subclass of DataInputStream setting 'in' to null. If it
> handles async close then it's possible that it replaces it with an input
> stream where read throws IOException unconditionally. This is why the
> original patch
On Tue, 23 Aug 2022 18:57:07 GMT, Сергей Цыпанов wrote:
> Suppose we have a scenario where `in` is replaced asynchronously in one of
> implementations and the implementation is passed into constructor of
> `DataInputStream`. In this case the patched code is less NPE-vulnerable,
> isn't it?
I
On Tue, 23 Aug 2022 17:12:50 GMT, Alan Bateman wrote:
> The main thing is to think through the implications for async close where the
> close method replaces 'in'.
Suppose we have a scenario where `in` is replaced asynchronously in one of
implementations and the implementation is passed into c
On Tue, 23 Aug 2022 15:50:56 GMT, Daniel Fuchs wrote:
> But assuming I've reverted the changes that are dubious, how could there be
> bugs caused by replacement of multiple reads with a single one? I was sure
> that such replacement improves thread safety as soon as we rid racy reads.
The main
On Tue, 23 Aug 2022 14:31:26 GMT, Сергей Цыпанов wrote:
> > I agree that caution is warranted
>
> But assuming I've reverted the changes that are dubious, how could there be
> bugs caused by replacement of multiple reads with a single one? I was sure
> that such replacement improves thread saf
On Tue, 23 Aug 2022 13:57:35 GMT, Daniel Fuchs wrote:
> I agree that caution is warranted
But assuming I've reverted the changes that are dubious, how could there be
bugs caused by replacement of multiple reads with a single one? I was sure that
such replacement improves thread safety as soon
On Sun, 21 Aug 2022 07:21:08 GMT, Alan Bateman wrote:
> 'in' is a protected field so it requires thinking about subclasses that might
> change 'in', say when the input stream is asynchronously closed.
> BufferedInputStream is an example of a FilterInputStream that sets 'in' to
> null when asyn
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> field only once per operation.
>
> Current implementation does it for each
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> field only once per operation.
>
> Current implementation does it for each
On Sun, 21 Aug 2022 06:29:43 GMT, Сергей Цыпанов wrote:
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> field only once p
On Sun, 21 Aug 2022 06:29:43 GMT, Сергей Цыпанов wrote:
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> field only once p
I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream`
(as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can
be significantly improved by accessing volatile `in` field only once per
operation.
Current implementation does it for each call of `in
27 matches
Mail list logo
