On Mon, 15 Nov 2021 18:08:22 GMT, Philippe Marschall
wrote:
> 3. I made many methods just return `this` after checking for operated on
> and closed:
Reading the Javadoc again I'm not sure this is allowed. The method Javadoc
doesn't clearly say it but the package Javadoc for interm
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
On Thu, 31 Dec 2020 10:10:56 GMT, Philippe Marschall
wrote:
> Implement three optimiztations for Reader.read(CharBuffer)
>
> * Add a code path for heap buffers in Reader#read to use the backing array
> instead of allocating a new one.
> * Change the code path for direct buffers
On Fri, 16 Apr 2021 17:00:16 GMT, Brian Burkhalter wrote:
>> Philippe Marschall has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 15 commits:
>>
>> - Merge master
>> - Fix bug in CharArrayReader an
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with one
additional commit since the
Hello
I am looking for reviewers and a sponsor for JDK-4926314: Optimize
Reader.read(CharBuffer) [1]. The PR [2] went through quite some changes
and is now back to few changes to reduce the impact and the risk.
[1] https://bugs.openjdk.java.net/browse/JDK-4926314
[2]
On Sat, 13 Mar 2021 14:40:14 GMT, Philippe Marschall
wrote:
>> I think the implementation changes here look good. I don't know however
>> whether there is enough coverage in the tests. These should verify that the
>> `Reader`, `CharArrayReader`, and `InputStreamReade
On Tue, 16 Feb 2021 23:49:36 GMT, Brian Burkhalter wrote:
> I think the implementation changes here look good. I don't know however
> whether there is enough coverage in the tests. These should verify that the
> `Reader`, `CharArrayReader`, and `InputStreamReader` implementations of
>
On Fri, 19 Feb 2021 07:34:57 GMT, Alan Bateman wrote:
>> I think that's what @AlanBateman intended. The `skip()` changes would revert
>> also (I think) but the C-style array changes can stay. Thanks.
>
> Yes, let's bring it back to just eliminating the intermediate array when the
> buffer has
On Tue, 16 Feb 2021 23:52:09 GMT, Brian Burkhalter wrote:
>> Philippe Marschall has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Replace c-style array declarations
>> - Share work buffer between #skip
On Tue, 16 Feb 2021 23:50:30 GMT, Brian Burkhalter wrote:
>> Philippe Marschall has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Replace c-style array declarations
>> - Share work buffer between #skip
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request with a new target base due to a
merge or a rebase. Th
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with three
additional commits since the
On Wed, 17 Feb 2021 15:37:11 GMT, Alan Bateman wrote:
>> Philippe Marschall has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Replace c-style array declarations
>> - Share work buffer between #skip and
On Wed, 17 Feb 2021 17:22:21 GMT, Alan Bateman wrote:
>>> Right, I'm not exactly sure why the more limited changes I attempted in
>>> [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e)
>>> failed. In that change I simply changed the initialization order,
On Mon, 15 Feb 2021 11:30:54 GMT, Claes Redestad wrote:
>> This patch exposes a couple of intrinsics used by String to speed up ASCII
>> checking and byte[] -> char[] inflation, which can be used by latin1 and
>> ASCII-compatible CharsetDecoders to speed up decoding operations.
>>
>> -
On Wed, 10 Feb 2021 21:58:02 GMT, Brian Burkhalter wrote:
>> That would be possible. It would help in cases where a large Reader is read
>> into one or several relatively small off-heap CharBuffers, requiring
>> multiple #read calls. This can only be done when the caller is able to work
>>
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with two
additional commits since the l
On Fri, 5 Feb 2021 22:08:17 GMT, Brian Burkhalter wrote:
>> Philippe Marschall has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Limit amount read to avoid BufferOverflowException
>>
>> - li
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with four
additional commits since th
On Tue, 5 Jan 2021 18:10:52 GMT, Brian Burkhalter wrote:
>> Philippe Marschall has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright years
>
> src/java.base/share/classes/java/io/R
On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272:
On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272:
On 17.01.21 18:48, Philippe Marschall wrote:
...
To be honest backing out of the StreamDecoder changes looks like a good
comprise to me to reduce the risk while still improving throughput and
reducing allocation rate, especially in the on-heap path.
I gave it some more thought and propose
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with one
additional commit since the las
On Tue, 19 Jan 2021 07:22:49 GMT, Philippe Marschall
wrote:
>> src/java.base/share/classes/java/io/Reader.java line 207:
>>
>>> 205: target.put(cbuf, 0, n);
>>> 206: nread += n;
>>> 207:
On Mon, 18 Jan 2021 07:47:30 GMT, Peter Levart wrote:
>> Philippe Marschall has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add unit tests
>>
>> - add unit test for Reader#read(CharBuffer)
>&g
On Sun, 10 Jan 2021 01:59:18 GMT, Brett Okken
wrote:
>> Philippe Marschall has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add unit tests
>>
>> - add unit test for Reader#read(CharBuffer)
>&g
On 05.01.21 01:53, Brian Burkhalter wrote:
On Thu, 31 Dec 2020 10:11:58 GMT, Philippe Marschall
wrote:
...
How does the performance of `InputStreamReader.read(CharBuffer)` compare for
the case where only the change to `Reader` is made versus if all your proposed
changes are applied?
I
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with one
additional commit since the
On 05.01.21 01:53, Brian Burkhalter wrote:
...
I changed the JBS issue summary to match the title of this PR so that
integration blocker is removed.
Thank you.
How does the performance of `InputStreamReader.read(CharBuffer)` compare for
the case where only the change to `Reader` is
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with one
additional commit since t
mediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to
> `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
Philippe Marschall has updated the pull request incrementally with one
additional commit since the las
Implement three optimiztations for Reader.read(CharBuffer)
* Add a code path for heap buffers in Reader#read to use the backing array
instead of allocating a new one.
* Change the code path for direct buffers in Reader#read to limit the
intermediate allocation to `TRANSFER_BUFFER_SIZE`.
*
On Thu, 31 Dec 2020 10:10:56 GMT, Philippe Marschall
wrote:
> Implement three optimiztations for Reader.read(CharBuffer)
>
> * Add a code path for heap buffers in Reader#read to use the backing array
> instead of allocating a new one.
> * Change the code path for direct buffers
On 20.12.20 19:15, Philippe Marschall wrote:
On 20.12.20 18:47, Rob Spoor wrote:
...
That "> 0" is incorrect here; it's allowed to return 0 before EOF
I don't think the method is allowed to return 0 before EOF. To quote
from the method Javadoc.
> This method blocks
On 20.12.20 18:47, Rob Spoor wrote:
...
That "> 0" is incorrect here; it's allowed to return 0 before EOF
I don't think the method is allowed to return 0 before EOF. To quote
from the method Javadoc.
> This method blocks until input data is available, end of file is
detected, or an
On Fri, Dec 11, 2020 at 5:35 PM Brian Burkhalter
wrote:
>
> Hello,
>
> ...
>
>
> I think perhaps they could all go in the same PR as the things are quite
> related. It would be good to have simple JMH benchmarks to measure the
> improvements. The benchmark code does not necessarily have to be
On Thu, Dec 10, 2020 at 9:25 PM Brian Burkhalter
wrote:
>
> Hi Philippe,
>
> On Dec 10, 2020, at 12:03 PM, Philippe Marschall
> wrote:
>
> ...
>
>
> I think that core-libs-dev (CCed) would be more appropriate as java.io
> package changes are usually discussed
; > wrote:
> >
> > Hi Philippe,
> >
> >> On Dec 10, 2020, at 12:03 PM, Philippe Marschall
> >> wrote:
> >>
> >> I recently came across Reader#read(CharBuffer) and noticed it was
> >> missing an optimization for heap buffers. […]
>
ss.
> - One jpackage/jlink tier2 test fails but I don't believe it is related.
> - Some tier3 Swing tests fail but I don't think they are related.
Philippe Marschall has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
contains two commits
On 23.09.20 07:13, David Holmes wrote:
On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote:
Marked as reviewed by kvn (Reviewer).
Have you run the JFR tests in test/jdk/jdk/jfr?
@marschall Please do not force-push anything as it breaks the commit history in
the PR and renders previous
ss.
> - One jpackage/jlink tier2 test fails but I don't believe it is related.
> - Some tier3 Swing tests fail but I don't think they are related.
Philippe Marschall has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
contains o
On 22.09.20 10:45, Erik Gahlin wrote:
On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote:
Philippe Marschall 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
ss.
> - One jpackage/jlink tier2 test fails but I don't believe it is related.
> - Some tier3 Swing tests fail but I don't think they are related.
Philippe Marschall has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
contains o
Hello
I am looking for a sponsor for JDK-8138732 [1]. The ready to integrate
PR is here [2].
Changes between the current code and the reviewed code:
- I removed the jdk.internal export to jdk.jfr, that was a review comment.
- I had to rebase and resolve a merge conflict with JDK-8243066.
[1]
ss.
> - One jpackage/jlink tier2 test fails but I don't believe it is related.
> - Some tier3 Swing tests fail but I don't think they are related.
Philippe Marschall has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
contains o
On Mon, Sep 7, 2020 at 7:54 PM Alan Bateman wrote:
>
> On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall
> wrote:
>
> > Hello, newbie here
> >
> > I picked JDK-8138732 to work on because it has a "starter" label and I
> > believe I unde
ss.
> - One jpackage/jlink tier2 test fails but I don't believe it is related.
> - Some tier3 Swing tests fail but I don't think they are related.
Philippe Marschall has refreshed the contents of this pull request, and
previous commits have been removed. The
incremental views will show
Hello
I started working on 8138732 [2] as described in the issue [1]. However
the question about the impact and coordination with other projects came
up, eg.:
- projects that implement their own intrinsics
- Graal
- somebody else?
How do we want to address this and coordinate with these
Hello, newbie here
I picked JDK-8138732 to work on because it has a "starter" label and I believe
I understand what to do.
- I tried to update the copyright year to 2020 in every file.
- I decided to change `@since` from 9 to 16 since it is a new annotation name
in a new package.
- I tried to
On 22.08.19 19:56, Mandy Chung wrote:
Hi Philippe,
This is a good use of StackWalker. getSource can simply return
StackFrame and avoid the creation of String[].
Updated webrev [1] and inline diff at the end.
Something I noted is that we could replace
odName()})
+ .findFirst()
+ .get());
}
}
[1]
https://github.com/marschall/webrevs/raw/master/Log-getSource/webrev.zip
Cheers
Philippe Marschall
On 25.11.2013 23:01, Alan Bateman wrote:
On 24/11/2013 17:07, Philippe Marschall wrote:
Hi
The following issue was been bothering me for a while:
When you have an annotation with a value that is an array of classes
[1] and one of those classes can't be loaded with the class loader
Hi
The following issue was been bothering me for a while:
When you have an annotation with a value that is an array of classes
[1] and one of those classes can't be loaded with the class loader of
defining class of the element the annotation is defined on you get a
ArrayStoreException (stack
On 05.10.2013 21:57, Brian Goetz wrote:
Is there something I missed? Is this something that has been considered?
If memory efficiency were the only metric in the world, this would be a
no-brainer. But, by having different classes for different nodes, many many
paths where the VM could
Hi
I attended Nathan Reynolds Java Memory Hogs [CON4695] talk where he
talked about about memory waste in Java collections and attempts in 7u40
and later to improve the situation.
One thing he mentioned was that there is a patch floating around that
makes HashSet no longer use HashMap. This
On 27.05.2013 10:40, Alan Bateman wrote:
On 26/05/2013 12:04, Philippe Marschall wrote:
Hi
It would be nice if javax.xml.stream.XMLStreamReader and
javax.xml.stream.XMLStreamWriter could be made to extend
java.lang.AutoCloseable so that they can be used in a
try-with-resouces statement
Hi
It would be nice if javax.xml.stream.XMLStreamReader and
javax.xml.stream.XMLStreamWriter could be made to extend
java.lang.AutoCloseable so that they can be used in a try-with-resouces
statement. The some does for XMLEventReader and XMLEventReader.
I'm not sure this is the right mailing
Hi
I often find myself writing code like this:
ConcurrentMap map = ...;
Object value = map.get(key);
if (value == null) {
Object newValue = expensiveComputation();
Object previous = map.putIfAbsent(key, newValue);
if (previous != null) {
value = previous;
} else {
value =
On 26.05.2013 13:25, Peter Levart wrote:
Hi Philippe,
I think you are looking for Map.computeIfAbsent(K, Supplier) which was
added to Map interface recently.
Yes I am, thanks.
Philippe
61 matches
Mail list logo
