Re: RFR: JDK-8277095 : Empty streams create too many objects

2021-11-15 Thread Philippe Marschall
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

Re: RFR: JDK-8277095 : Empty streams create too many objects

2021-11-15 Thread Philippe Marschall
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

Integrated: 4926314: Optimize Reader.read(CharBuffer)

2021-04-26 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]

2021-04-25 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v10]

2021-04-25 Thread Philippe Marschall
iate 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

Looking for reviewer and sponsor for 4926314

2021-04-16 Thread Philippe Marschall
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] https://github.com/openjdk

Re: RFR: 4926314: Optimize Reader.read(CharBuffer)

2021-04-08 Thread Philippe Marschall
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 `InputStreamRea

Re: RFR: 4926314: Optimize Reader.read(CharBuffer)

2021-03-13 Thread Philippe Marschall
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 > `read(Ch

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]

2021-03-13 Thread Philippe Marschall
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 a

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]

2021-03-13 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]

2021-03-13 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]

2021-03-13 Thread Philippe Marschall
iate 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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v8]

2021-03-13 Thread Philippe Marschall
iate 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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]

2021-02-18 Thread Philippe Marschall
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

Re: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2]

2021-02-18 Thread Philippe Marschall
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, w

Re: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths

2021-02-15 Thread Philippe Marschall
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. >> >> - Fast-pa

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]

2021-02-12 Thread Philippe Marschall
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 >> wit

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]

2021-02-12 Thread Philippe Marschall
iate 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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5]

2021-02-09 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v6]

2021-02-09 Thread Philippe Marschall
iate 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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]

2021-02-09 Thread Philippe Marschall
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

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9]

2021-02-09 Thread Philippe Marschall
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: Refa

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9]

2021-02-08 Thread Philippe Marschall
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: Refa

Re: RFR: 4926314: Optimize Reader.read(CharBuffer)

2021-02-03 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5]

2021-01-26 Thread Philippe Marschall
iate 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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]

2021-01-26 Thread Philippe Marschall
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:

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]

2021-01-18 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]

2021-01-17 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer)

2021-01-17 Thread Philippe Marschall
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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v4]

2021-01-09 Thread Philippe Marschall
iate 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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer)

2021-01-05 Thread Philippe Marschall
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 made

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]

2021-01-05 Thread Philippe Marschall
iate 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

Re: RFR: 4926314: Optimize Reader.read(CharBuffer) [v2]

2021-01-04 Thread Philippe Marschall
iate 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

RFR: 4926314: Optimize Reader.read(CharBuffer)

2020-12-31 Thread Philippe Marschall
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`. * Implem

Re: RFR: 4926314: Optimize Reader.read(CharBuffer)

2020-12-31 Thread Philippe Marschall
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

Re: [BUG] InputStream.readNBytes doesn't correctly check for EOF

2020-12-22 Thread Philippe Marschall
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

Re: [BUG] InputStream.readNBytes doesn't correctly check for EOF

2020-12-20 Thread Philippe Marschall
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 excepti

Re: Optimization potential in Reader#read(CharBuffer)

2020-12-16 Thread Philippe Marschall
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 in

Re: Optimization potential in Reader#read(CharBuffer)

2020-12-11 Thread Philippe Marschall
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

Re: Optimization potential in Reader#read(CharBuffer)

2020-12-11 Thread Philippe Marschall
> > 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. […] &g

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v6]

2020-09-27 Thread Philippe Marschall
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 t

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]

2020-09-23 Thread Philippe Marschall
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

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5]

2020-09-23 Thread Philippe Marschall
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 con

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]

2020-09-23 Thread Philippe Marschall
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 of the

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v4]

2020-09-22 Thread Philippe Marschall
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 con

Looking for a sponsor for JDK-8138732

2020-09-21 Thread Philippe Marschall
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]

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v3]

2020-09-21 Thread Philippe Marschall
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 con

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package

2020-09-09 Thread Philippe Marschall
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 understa

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]

2020-09-09 Thread Philippe Marschall
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

How to proceed with 8138732

2020-09-09 Thread Philippe Marschall
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 proj

RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package

2020-09-07 Thread Philippe Marschall
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 k

Re: Remove exception from sun.rmi.runtime.Log#getSource()

2019-08-23 Thread Philippe Marschall
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 sun.rmi.runtime.Log.LogStreamLog.unqu

Remove exception from sun.rmi.runtime.Log#getSource()

2019-08-22 Thread Philippe Marschall
odName()}) + .findFirst() + .get()); } } [1] https://github.com/marschall/webrevs/raw/master/Log-getSource/webrev.zip Cheers Philippe Marschall

Re: ArrayStoreException in Class#getAnnotations

2013-11-26 Thread 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 load

ArrayStoreException in Class#getAnnotations

2013-11-24 Thread Philippe Marschall
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 t

Re: Possible HashSet memory improvement

2013-10-06 Thread Philippe Marschall
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 prov

Possible HashSet memory improvement

2013-10-05 Thread Philippe Marschall
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 wo

Re: AutoCloseable XMLStreamReader and XMLStreamWriter?

2013-05-28 Thread Philippe Marschall
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. The

Re: ConcurrentMap.putIfAbsent(Object, Supplier)?

2013-05-26 Thread Philippe Marschall
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

ConcurrentMap.putIfAbsent(Object, Supplier)?

2013-05-26 Thread Philippe Marschall
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 = newValu

AutoCloseable XMLStreamReader and XMLStreamWriter?

2013-05-26 Thread Philippe Marschall
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