Re: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

2021-08-01 Thread Sergey Bylokhov
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] > Colleciton.toArray()` call and then manually copy array into another array > with required type. > This PR cleanups such places to more shorter call `T[] >

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

2021-08-01 Thread Jie Fu
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >>

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

2021-08-01 Thread David Holmes
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >>

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-08-01 Thread Markus KARG
On Sun, 1 Aug 2021 08:24:13 GMT, Markus KARG wrote: >>> The modified code found in >>> [4b501b2](https://github.com/openjdk/jdk/commit/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20) >>> should be safe from infinite loops, as it checks the actual file length in >>> each iteration (even if this

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13]

2021-08-01 Thread Markus KARG
> This PR-*draft* is **work in progress** and an invitation to discuss a > possible solution for issue > [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not > yet* intended for a final review. > > As proposed in JDK-8265891, this PR provides an implementation for >

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v12]

2021-08-01 Thread Markus KARG
> This PR-*draft* is **work in progress** and an invitation to discuss a > possible solution for issue > [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not > yet* intended for a final review. > > As proposed in JDK-8265891, this PR provides an implementation for >

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-08-01 Thread Markus KARG
On Sat, 31 Jul 2021 17:33:50 GMT, Alan Bateman wrote: >>> Also can you can check that IllegalBlockingModeException is thrown for the >>> case ch is a SelectableChannel configured non-blocking and the destination >>> is a FileChannel? >> >> Done in >>

Re: RFR: JDK-8256844: Make NMT late-initializable [v2]

2021-08-01 Thread Thomas Stuefe
On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe wrote: >> Short: this patch makes NMT available in custom-launcher scenarios and >> during gtests. It simplifies NMT initialization. It adds a lot of >> NMT-specific testing, cleans them up and makes them sideeffect-free. >> >> - >> >>

Re: RFR: JDK-8256844: Make NMT late-initializable [v2]

2021-08-01 Thread Thomas Stuefe
On Fri, 30 Jul 2021 20:14:04 GMT, Zhengyu Gu wrote: >> Thomas Stuefe has updated the pull request incrementally with six additional >> commits since the last revision: >> >> - feedback zhengyu >> - feeback Coleen/Kim (constness fix) >> - Feedback David >> - Add test to test for non-java

Re: RFR: JDK-8256844: Make NMT late-initializable [v2]

2021-08-01 Thread Thomas Stuefe
> Short: this patch makes NMT available in custom-launcher scenarios and during > gtests. It simplifies NMT initialization. It adds a lot of NMT-specific > testing, cleans them up and makes them sideeffect-free. > > - > > NMT continues to be an extremely useful tool for SAP to tackle

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-08-01 Thread Markus KARG
On Sun, 1 Aug 2021 07:46:36 GMT, Markus KARG wrote: >>> I need to look at it closely but I suspect this introduces a potential >>> overflow. Also if output stream is backed by a SocketChannel configured >>> non-blocking then FC::transferTo may return 0 so I assume there is a >>> potential

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-08-01 Thread Markus KARG
On Sat, 31 Jul 2021 21:20:28 GMT, Markus KARG wrote: > I suspect the eventually patch will need have to make use of the blockingLock > to prevent the underlying channels from being changed to non-blocking during > the transfer. The blocking lock now is used since

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v11]

2021-08-01 Thread Markus KARG
> This PR-*draft* is **work in progress** and an invitation to discuss a > possible solution for issue > [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not > yet* intended for a final review. > > As proposed in JDK-8265891, this PR provides an implementation for >