April 2021 - core-libs-dev

RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant
by Richard Fussenegger 17 Jun '21

17 Jun '21

6594730: UUID.getVersion() is only meaningful for Leach-Salz variant ------------- Commit messages: - 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant Changes: https://git.openjdk.java.net/jdk/pull/1467/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1467&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6594730 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1467/head:pull/1467 PR: https://git.openjdk.java.net/jdk/pull/1467

4 12

New convenience methods on Stream
by Donald Raab 14 Jun '21

14 Jun '21

Hi all, I’d like to propose adding one or two of the following methods on Stream to cover more surface area of the Collections ecosystem, without requiring a big increase in the size of the Stream interface. Apologies if this has come up for discussion before. 1. Stream contents into a mutable collection created by a Supplier. default <R extends Collection<T>> R toCollection(Supplier<R> supplier) { return this.collect(Collectors.toCollection(supplier)); } Usage Examples: HashSet<String> set = stream.toCollection(HashSet::new); TreeSet<String> sortedSet = stream.toCollection(TreeSet::new); ArrayDeque<String> deque = stream.toCollection(ArrayDeque::new); 2. Pass the result of toArray directly into a function that can then return a Collection. This should work with Set.of, List.of and any 3rd party collections which take arrays. default <R extends Collection<T>> R to(Function<T[], R> function) { return function.apply((T[]) this.toArray()); } Usage Examples: Set<String> set = stream.to(Set::of); List<String> list = stream.to(List::of); List<String> arrayList = stream.to(Arrays::asList); 3. Stream contents directly into any mutable collection. This would then work with all other mutable JDK Collection types. default <R extends Collection<T>> R into(R result) { Collections.addAll(result, (T[]) this.toArray()); return result; } Usage Examples: HashSet<String> set = stream.into(new HashSet<>()); TreeSet<String> sortedSet = stream.into(new TreeSet<>(Comparator.reverseOrder())); CopyOnWriteArrayList<String> list = stream.into(new CopyOnWriteArrayList<>()); There may be better default implementations, but I just wanted something here for illustrative purposes. Thoughts? Don

4 6

RFR: 8265039: Adjust javadoc for ByteArray*Stream and InputStream
by Сергей Цыпанов 07 Jun '21

07 Jun '21

Hello, to avoid cases detected in [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pu… I propose to modify JavaDoc of `ByteArray*Stream` to explicitly mention redundancy of wrapping with `BufferedInputStream`. As of `InputStream` I think in notation `It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.` the word 'never' should be replaced with 'usually': apart from `ByteArrayInputStream` e.g. `FileInputStream.available()` often returns the count of remaining bytes (the only exclusion I'm aware of is the files located under `/proc/`) and indeed this count can be used to allocate a buffer to read all the bytes in one call. Consider benchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class ByteArrayInputStreamBenchmark { @Benchmark public void read(Data data, Blackhole bh) { int value; var in = data.bais; while ((value = in.read()) != -1) { bh.consume(value); } } @Benchmark public void readBuffered(Data data, Blackhole bh) throws IOException { int value; var in = new BufferedInputStream(data.bais); while ((value = in.read()) != -1) { bh.consume(value); } } @Benchmark public Object readAllBytes(Data data) { var in = data.bais; return in.readAllBytes(); } @Benchmark public Object readAllBytesBuffered(Data data) throws IOException { var in = data.bais; return new BufferedInputStream(in).readAllBytes(); } @State(Scope.Thread) public static class Data { @Param({"8", "128", "512", "1024"}) private int length; private byte[] bytes; private ByteArrayInputStream bais; @Setup(Level.Iteration) public void setUp() { bytes = new byte[length]; ThreadLocalRandom.current().nextBytes(bytes); } @Setup(Level.Invocation) public void setUpBais() { bais = new ByteArrayInputStream(bytes); } } } giving (length) Score Error Units read 8 55.737 ± 0.431 ns/op read 128 533.172 ± 1.613 ns/op read 512 2066.238 ± 23.989 ns/op read 1024 4335.570 ± 20.137 ns/op readBuffered 8 521.936 ± 2.454 ns/op readBuffered 128 971.617 ± 100.469 ns/op readBuffered 512 2284.472 ± 251.390 ns/op readBuffered 1024 4168.598 ± 77.980 ns/op readAllBytes 8 34.850 ± 0.072 ns/op readAllBytes 128 36.751 ± 0.133 ns/op readAllBytes 512 45.304 ± 0.699 ns/op readAllBytes 1024 61.790 ± 0.386 ns/op readAllBytesBuffered 8 870.454 ± 4.406 ns/op readAllBytesBuffered 128 910.176 ± 32.258 ns/op readAllBytesBuffered 512 896.155 ± 6.005 ns/op readAllBytesBuffered 1024 965.596 ± 29.225 ns/op read:·gc.alloc.rate.norm 8 32.006 ± 0.001 B/op read:·gc.alloc.rate.norm 128 32.007 ± 0.004 B/op read:·gc.alloc.rate.norm 512 32.010 ± 0.010 B/op read:·gc.alloc.rate.norm 1024 32.011 ± 0.008 B/op readBuffered:·gc.alloc.rate.norm 8 8280.354 ± 0.016 B/op readBuffered:·gc.alloc.rate.norm 128 8240.484 ± 0.015 B/op readBuffered:·gc.alloc.rate.norm 512 8240.599 ± 0.056 B/op readBuffered:·gc.alloc.rate.norm 1024 8280.978 ± 0.024 B/op readAllBytes:·gc.alloc.rate.norm 8 56.008 ± 0.001 B/op readAllBytes:·gc.alloc.rate.norm 128 176.017 ± 0.001 B/op readAllBytes:·gc.alloc.rate.norm 512 560.035 ± 0.002 B/op readAllBytes:·gc.alloc.rate.norm 1024 1072.057 ± 0.002 B/op readAllBytesBuffered:·gc.alloc.rate.norm 8 16512.660 ± 0.026 B/op readAllBytesBuffered:·gc.alloc.rate.norm 128 16632.684 ± 0.008 B/op readAllBytesBuffered:·gc.alloc.rate.norm 512 17016.694 ± 0.017 B/op readAllBytesBuffered:·gc.alloc.rate.norm 1024 17528.748 ± 0.012 B/op ------------- Commit messages: - Adjust javadoc for ByteArray*Stream Changes: https://git.openjdk.java.net/jdk/pull/3341/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3341&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265039 Stats: 20 lines in 3 files changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3341/head:pull/3341 PR: https://git.openjdk.java.net/jdk/pull/3341

3 3

RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native
by Nick Gasson 04 Jun '21

04 Jun '21

macOS on Apple silicon uses slightly different ABI conventions to the standard AArch64 ABI. The differences are outlined in [1]. In particular in the standard (AAPCS) ABI, variadic arguments may be passed in either registers or on the stack following the normal calling convention. To handle this, va_list is a struct containing separate pointers for arguments located in integer registers, floating point registers, and on the stack. Apple's ABI simplifies this by passing all variadic arguments on the stack and the va_list type becomes a simple char* pointer. This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to represent the new ABI variant on macOS. StackVaList is based on WinVaList lightly modified to handle the different TypeClasses on AArch64. The original AArch64Linker is renamed to AapcsLinker and is currently used for all non-Mac platforms. I think we also need to add a WinAArch64 CABI but I haven't yet been able to test on a Windows system so will do that later. The macOS ABI also uses a different method of spilling arguments to the stack (the standard ABI pads each argument to a multiple of 8 byte stack slots, but the Mac ABI packs arguments according to their natural alignment). None of the existing tests exercise this so I'll open a new JBS issue and work on that separately. Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. ------------- Commit messages: - 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native Changes: https://git.openjdk.java.net/jdk/pull/3617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263512 Stats: 770 lines in 12 files changed: 568 ins; 112 del; 90 mod Patch: https://git.openjdk.java.net/jdk/pull/3617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3617/head:pull/3617 PR: https://git.openjdk.java.net/jdk/pull/3617

3 30

RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics
by Sandhya Viswanathan 03 Jun '21

03 Jun '21

Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. The following changes are made: The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. The assembly source files are named as “*.S” and include files are named as “*.S.inc”. The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. Changes are made to build system to support dependency tracking for assembly files with includes. The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie(a)oracle.com) This work is part of second round of incubation of the Vector API. JEP: https://bugs.openjdk.java.net/browse/JDK-8261663 Please review. Performance: Micro benchmark Base Optimized Unit Gain(Optimized/Base) Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 Double128Vector.COS 49.94 245.89 ops/ms 4.92 Double128Vector.COSH 26.91 126.00 ops/ms 4.68 Double128Vector.EXP 71.64 379.65 ops/ms 5.30 Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 Double128Vector.LOG 61.95 279.84 ops/ms 4.52 Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 Double128Vector.SIN 49.36 240.79 ops/ms 4.88 Double128Vector.SINH 26.59 103.75 ops/ms 3.90 Double128Vector.TAN 41.05 152.39 ops/ms 3.71 Double128Vector.TANH 45.29 169.53 ops/ms 3.74 Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 Double256Vector.COS 58.26 389.77 ops/ms 6.69 Double256Vector.COSH 29.44 151.11 ops/ms 5.13 Double256Vector.EXP 86.67 564.68 ops/ms 6.52 Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 Double256Vector.LOG 71.52 394.90 ops/ms 5.52 Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 Double256Vector.SIN 57.06 380.98 ops/ms 6.68 Double256Vector.SINH 29.40 117.37 ops/ms 3.99 Double256Vector.TAN 44.90 279.90 ops/ms 6.23 Double256Vector.TANH 54.08 274.71 ops/ms 5.08 Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 Double512Vector.COS 59.88 837.04 ops/ms 13.98 Double512Vector.COSH 30.34 172.76 ops/ms 5.70 Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 Double512Vector.LOG 74.84 996.00 ops/ms 13.31 Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 Double512Vector.POW 37.42 384.13 ops/ms 10.26 Double512Vector.SIN 59.74 728.45 ops/ms 12.19 Double512Vector.SINH 29.47 143.38 ops/ms 4.87 Double512Vector.TAN 46.20 587.21 ops/ms 12.71 Double512Vector.TANH 57.36 495.42 ops/ms 8.64 Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 Double64Vector.COS 23.42 152.01 ops/ms 6.49 Double64Vector.COSH 17.34 113.34 ops/ms 6.54 Double64Vector.EXP 27.08 203.53 ops/ms 7.52 Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 Double64Vector.LOG 26.75 142.63 ops/ms 5.33 Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 Double64Vector.SIN 23.28 146.91 ops/ms 6.31 Double64Vector.SINH 17.62 88.59 ops/ms 5.03 Double64Vector.TAN 21.00 86.43 ops/ms 4.12 Double64Vector.TANH 23.75 111.35 ops/ms 4.69 Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 Float128Vector.COS 42.82 803.02 ops/ms 18.75 Float128Vector.COSH 31.44 118.34 ops/ms 3.76 Float128Vector.EXP 72.43 855.33 ops/ms 11.81 Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 Float128Vector.LOG 52.95 877.94 ops/ms 16.58 Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 Float128Vector.SIN 43.38 745.31 ops/ms 17.18 Float128Vector.SINH 31.11 112.91 ops/ms 3.63 Float128Vector.TAN 37.25 332.13 ops/ms 8.92 Float128Vector.TANH 57.63 453.77 ops/ms 7.87 Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 Float256Vector.COS 43.75 926.69 ops/ms 21.18 Float256Vector.COSH 33.52 130.46 ops/ms 3.89 Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 Float256Vector.SIN 44.07 911.04 ops/ms 20.67 Float256Vector.SINH 33.16 122.50 ops/ms 3.69 Float256Vector.TAN 37.85 497.75 ops/ms 13.15 Float256Vector.TANH 64.27 537.20 ops/ms 8.36 Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 Float512Vector.COS 40.92 1567.93 ops/ms 38.32 Float512Vector.COSH 33.42 138.36 ops/ms 4.14 Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 Float512Vector.POW 32.73 1015.85 ops/ms 31.04 Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 Float512Vector.SINH 33.05 129.39 ops/ms 3.91 Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 Float64Vector.COS 44.28 394.33 ops/ms 8.91 Float64Vector.COSH 28.35 95.27 ops/ms 3.36 Float64Vector.EXP 65.80 486.37 ops/ms 7.39 Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 Float64Vector.LOG 51.93 163.25 ops/ms 3.14 Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 Float64Vector.SIN 44.41 382.09 ops/ms 8.60 Float64Vector.SINH 28.20 90.68 ops/ms 3.22 Float64Vector.TAN 36.29 160.89 ops/ms 4.43 Float64Vector.TANH 47.65 214.04 ops/ms 4.49 ------------- Commit messages: - remove whitespace - Merge master - Small fix - cleanup - x86 short vector math optimization for Vector API Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265783 Stats: 417153 lines in 124 files changed: 416959 ins; 126 del; 68 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638

5 33

RFR: 8264896: Remove redundant '& 0xFF' from int-to-byte cast
by Сергей Цыпанов 03 Jun '21

03 Jun '21

When we do byte b1 = (byte) (value & 0xFF); we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below: public class Main { public static void main(String[] args) throws Exception { IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> { byte b1 = (byte) (value & 0xFF); byte b2 = (byte) value; if (b1 != b2) { throw new RuntimeException("" + value); } }); } Also tier1 and tier2 are both OK. ------------- Commit messages: - Merge branch 'master' into bitwise - Remove redundant '& 0xFF' from int-to-byte cast Changes: https://git.openjdk.java.net/jdk/pull/2826/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2826&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264896 Stats: 50 lines in 14 files changed: 0 ins; 0 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/2826.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2826/head:pull/2826 PR: https://git.openjdk.java.net/jdk/pull/2826

5 4

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6]
by Yi Yang 03 Jun '21

03 Jun '21

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: better check1-4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/1a96be7e..954abc6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04-05 Stats: 32 lines in 1 file changed: 31 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615

4 10

RFR: 8263561: Re-examine uses of LinkedList
by Сергей Цыпанов 02 Jun '21

02 Jun '21

The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. jdk:tier1 and jdk:tier2 are both ok ------------- Commit messages: - Remove remaining usages of LinkedList in java.base Changes: https://git.openjdk.java.net/jdk/pull/2744/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263561 Stats: 40 lines in 9 files changed: 0 ins; 2 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744

7 27

RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator)
by Maurizio Cimadamore 02 Jun '21

02 Jun '21

This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. [1] - https://openjdk.java.net/jeps/412 ------------- Commit messages: - Add linker test excludes for x86 and other platforms which do not support `CLinker` - Integrate latest API tweaks - Fix x86 build - Fix `TestLinkToNativeRBP` - Initial push Changes: https://git.openjdk.java.net/jdk/pull/3699/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264774 Stats: 14083 lines in 213 files changed: 8502 ins; 3605 del; 1976 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699

8 81

RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName()
by Сергей Цыпанов 28 May '21

28 May '21

As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. ------------- Commit messages: - 8265418: Clean-up redundant null-checks of Class.getPackageName() Changes: https://git.openjdk.java.net/jdk/pull/3571/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3571&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265418 Stats: 19 lines in 7 files changed: 1 ins; 8 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3571/head:pull/3571 PR: https://git.openjdk.java.net/jdk/pull/3571

5 22