RFR: 8299441: Fix typos in some test files under core-libs component
Can I please get a review of this change which fixes the final few typos in test files in the core-libs area? This addresses the remaining core-libs related typos from the original PR https://github.com/openjdk/jdk/pull/10029. - Commit messages: - 8299441: Fix typos in some test files under core-libs component Changes: https://git.openjdk.org/jdk/pull/11810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11810&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299441 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11810.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11810/head:pull/11810 PR: https://git.openjdk.org/jdk/pull/11810
Re: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be 16384
On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG wrote: > I/O had always been much slower than CPU and memory access, and thanks to > physical constraints, always will be. > While CPUs can get shrinked more and more, and can hold more and more memory > cache on or nearby a CPU core, the distance between CPU core and I/O device > cannot get reduced much: It will stay "far" away. > Due to this simple logic (and other factors), the spread between performance > of CPU and memory access on one hand, and performance of I/O on the other > hand, increases with every new CPU generation. > As a consequence, internal adjustment factors of the JDK need to get revised > from time to time to ensure optimum performance and each hardware generation. > > One such factor is the size of the temporary transfer buffer used internally > by `InputStream::transferTo`. > Since its introduction with JDK 9 many years (hence hardware generations) > have passed, so it's time to check the appropriateness of that buffer's size. > > Using JMH on a typical, modern cloud platform, it was proven that the current > 8K buffer is (much) too small on modern hardware: > The small buffer clearly stands in the way of faster transfers. > The ops/s of a simple `FileInputStream.transferTo(ByteArrayOutputStream)` > operation on JDK 21 could be doubled (!) by only doubling the buffer size > from 8K to 16K, which seems to be a considerable and cheap deal. > Doubling the buffer even more shows only marginal improvements of approx. 1% > to 3% per duplication of size, which does not justify additional memory > consumption. > > > TransferToPerformance.transferTo 8192 1048576 thrpt 25 1349.929 ± 47.057 ops/s > TransferToPerformance.transferTo 16384 1048576 thrpt 25 2633.560 ± 93.337 > ops/s > TransferToPerformance.transferTo 32768 1048576 thrpt 25 2721.025 ± 89.555 > ops/s > TransferToPerformance.transferTo 65536 1048576 thrpt 25 2855.949 ± 96.623 > ops/s > TransferToPerformance.transferTo 131072 1048576 thrpt 25 2903.062 ± 40.798 > ops/s > > > Even on small or limited platforms, an investment of 8K additonal temporary > buffer is very cheap and very useful, as it doubles the performance of > `InputStream::transferTo`, in particular for legacy (non-NIO) applications > still using `FileInputStream` and `ByteArrayOutputStream`. > I dare to say, even if not proven, that is a very considerable (possibly the > major) number of existing applications, as NIO was only adopted gradually by > programmers. > > Due to the given reasons, it should be approporiate to change > `DEFAULT_BUFFER_SIZE` from 8192 to 16384. Here's also results for "modern" architecture - I executed the benchmark in a k8s container on an Oracle cloud ARM64 virtual machine. With dropCaches=true: https://jmh.morethan.io/?gist=2db4c3b51073e90c1a84d7eed8e1a988 With dropCaches=false: https://jmh.morethan.io/?gist=d7dfb5def5899af41722b2768a827006 Here, the benefit of increasing buffer from 8k to 16k gets from about 10% (doing IO) up to 20% (reading from cache) increase in performance. - PR: https://git.openjdk.org/jdk/pull/11783
Re: RFR: 8299441: Fix typos in some test files under core-libs component
On Mon, 2 Jan 2023 09:52:59 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the final few typos in > test files in the core-libs area? This addresses the remaining core-libs > related typos from the original PR https://github.com/openjdk/jdk/pull/10029. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.org/jdk/pull/11810
Integrated: 8298590: Refactor LambdaForm constructors
On Fri, 9 Dec 2022 18:02:53 GMT, Jorn Vernee wrote: > Refactor LambdaForm constructors into static factories. > > In the new code, there's only 1 constructor, which simply initializes all > fields. Multiple factory methods are built on top of this, which add various > argument validation/pre-processing and post processing of the constructed > lambda forms. > > In the LambdaFrom class itself, it is easier to see which LF creation goes > through which checks due to names of factory, or if all checks are bypassed > by calling the constructor. > > New factories can easily be added that bypass all the checks in the existing > factories and just call the root constructor if they so wish to (we likely > want to add several for lazy lambda form resolution > https://bugs.openjdk.org/browse/JDK-8288041). > > Additionally: replaced some default values literals with named constants so > it's easy to see that it's just the default value for that arg at the call > site. This pull request has now been integrated. Changeset: 0532045e Author:Jorn Vernee URL: https://git.openjdk.org/jdk/commit/0532045edb709a995a42c07d95cb1cbabe886bed Stats: 97 lines in 8 files changed: 32 ins; 13 del; 52 mod 8298590: Refactor LambdaForm constructors Reviewed-by: redestad - PR: https://git.openjdk.org/jdk/pull/11612
Re: RFR: JDK-8299336 - InputStream::DEFAULT_BUFFER_SIZE should be 16384
On Mon, 2 Jan 2023 10:03:02 GMT, Peter Levart wrote: > Here, the benefit of increasing buffer from 8k to 16k gets from about 10% > (doing IO) up to 20% (reading from cache) increase in performance. I think 10% to 20% is good enough as an argument to go with 16k instead of 8k. - PR: https://git.openjdk.org/jdk/pull/11783
Re: RFR: 8240567: MethodTooLargeException thrown while creating a jlink image [v9]
> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): > "MethodTooLargeException thrown while creating a jlink image". > > Java still has a 64kb limit: A method may not be longer than 64kb. The idea > of the fix is to split up the generated methods in several smaller methods Oliver Kopp has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - More recursion Co-authored-by: Christoph - Merge remote-tracking branch 'origin/master' into fix-8240567 - Refine tests Co-authored-by: Christoph Co-authored-by: Carl Christian Snethlage <50491877+calix...@users.noreply.github.com> - Revert to original SystemModulesPlugin Co-authored-by: Christoph Co-authored-by: Carl Christian Snethlage <50491877+calix...@users.noreply.github.com> - Merge remote-tracking branch 'origin/master' into fix-8240567 - Refine test Co-authored-by: Christoph - Adapt number to have javac working (and refine test) - Remove obsolete comment - Begin to craft test - Reduce comment text - ... and 3 more: https://git.openjdk.org/jdk/compare/4c9038c4...ede0e87f - Changes: - all: https://git.openjdk.org/jdk/pull/10704/files - new: https://git.openjdk.org/jdk/pull/10704/files/96362d54..ede0e87f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=07-08 Stats: 5946 lines in 539 files changed: 3276 ins; 1260 del; 1410 mod Patch: https://git.openjdk.org/jdk/pull/10704.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704 PR: https://git.openjdk.org/jdk/pull/10704
Re: RFR: 8299441: Fix typos in some test files under core-libs component
On Mon, 2 Jan 2023 09:52:59 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the final few typos in > test files in the core-libs area? This addresses the remaining core-libs > related typos from the original PR https://github.com/openjdk/jdk/pull/10029. Thank you Lance for the review. - PR: https://git.openjdk.org/jdk/pull/11810
Integrated: 8299441: Fix typos in some test files under core-libs component
On Mon, 2 Jan 2023 09:52:59 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the final few typos in > test files in the core-libs area? This addresses the remaining core-libs > related typos from the original PR https://github.com/openjdk/jdk/pull/10029. This pull request has now been integrated. Changeset: 417d01ea Author:Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/417d01ea63261afb4fb29b4d11de799f2c0846d7 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod 8299441: Fix typos in some test files under core-libs component Co-authored-by: Michael Ernst Reviewed-by: lancea - PR: https://git.openjdk.org/jdk/pull/11810
