September 2021 - core-libs-dev

RFR: 8245095: Implementation of JEP 408: Simple Web Server
by Julia Boes 19 Oct '21

19 Oct '21

This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. Additionally, a small API is introduced for programmatic creation and customization. Testing: tier1-3. ------------- Commit messages: - fix whitespace - Move changes from sandbox to mainline Changes: https://git.openjdk.java.net/jdk/pull/5505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245095 Stats: 6891 lines in 42 files changed: 6856 ins; 15 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/5505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505 PR: https://git.openjdk.java.net/jdk/pull/5505

12 67

RFR: 8266936: Add a finalization JFR event
by Markus Grönlund 18 Oct '21

18 Oct '21

Greetings, Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. We would also like to assist users in replacing and mitigating uses in non-JDK code. Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). Thanks Markus ------------- Commit messages: - whitespace - update - update - whitespace - 8266936-alt: Add a finalization JFR event - shortcut calling Jfr::is_recording() - 8266936: Add a finalization JFR event Changes: https://git.openjdk.java.net/jdk/pull/4731/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266936 Stats: 249 lines in 9 files changed: 248 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731

6 47

RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE
by TatWai Chong 14 Oct '21

14 Oct '21

This patch implements string_compare intrinsic in SVE. It supports all LL, LU, UL and UU comparisons. As we haven't found an existing benchmark to measure performance impact, we created a benchmark derived from the test [1] for this evaluation. This benchmark is attached to this patch. Besides, remove the unused temporary register `vtmp3` from the existing match rules for StrCmp. The result below shows all varients can be benefited largely. Command: make exploded-test TEST="micro:StringCompareToDifferentLength" Benchmark (size) Mode Cnt Score Speedup Units compareToLL 24 avgt 10 1.0x ms/op compareToLL 36 avgt 10 1.0x ms/op compareToLL 72 avgt 10 1.0x ms/op compareToLL 128 avgt 10 1.4x ms/op compareToLL 256 avgt 10 1.8x ms/op compareToLL 512 avgt 10 2.7x ms/op compareToLU 24 avgt 10 1.6x ms/op compareToLU 36 avgt 10 1.8x ms/op compareToLU 72 avgt 10 2.3x ms/op compareToLU 128 avgt 10 3.8x ms/op compareToLU 256 avgt 10 4.7x ms/op compareToLU 512 avgt 10 6.3x ms/op compareToUL 24 avgt 10 1.6x ms/op compareToUL 36 avgt 10 1.7x ms/op compareToUL 72 avgt 10 2.2x ms/op compareToUL 128 avgt 10 3.3x ms/op compareToUL 256 avgt 10 4.4x ms/op compareToUL 512 avgt 10 6.1x ms/op compareToUU 24 avgt 10 1.0x ms/op compareToUU 36 avgt 10 1.0x ms/op compareToUU 72 avgt 10 1.4x ms/op compareToUU 128 avgt 10 2.2x ms/op compareToUU 256 avgt 10 2.6x ms/op compareToUU 512 avgt 10 3.7x ms/op [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intr… ------------- Commit messages: - 8269559: AArch64: Implement string_compare intrinsic in SVE Changes: https://git.openjdk.java.net/jdk/pull/5129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269559 Stats: 550 lines in 12 files changed: 447 ins; 12 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129

5 12

RFR: 8273682: Upgrade Jline to 3.20.0
by Jan Lahoda 13 Oct '21

13 Oct '21

I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed. Thanks! ------------- Commit messages: - Removing trailing whitespace. - Fixing tests. - Fixing Windows build. - Upgrading JLine to 3.20.0 Changes: https://git.openjdk.java.net/jdk/pull/5655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273682 Stats: 2667 lines in 47 files changed: 1830 ins; 473 del; 364 mod Patch: https://git.openjdk.java.net/jdk/pull/5655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5655/head:pull/5655 PR: https://git.openjdk.java.net/jdk/pull/5655

2 3

RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries
by Maurizio Cimadamore 12 Oct '21

12 Oct '21

This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. ------------- Commit messages: - Improve javadoc - Initial push Changes: https://git.openjdk.java.net/jdk/pull/4316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268129 Stats: 1278 lines in 44 files changed: 569 ins; 617 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316

6 23

RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable
by Сергей Цыпанов 12 Oct '21

12 Oct '21

In some JDK classes there's still the following hashCode() implementation: long objNum; public int hashCode() { return (int) objNum; } This outdated expression should be replaced with Long.hashCode(long) as it - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. See https://stackoverflow.com/a/4045083 This is related to https://github.com/openjdk/jdk/pull/4309 ------------- Commit messages: - 8268764: Use Long.hashCode() instead of int-cast where applicable Changes: https://git.openjdk.java.net/jdk/pull/4491/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268764 Stats: 15 lines in 9 files changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491 PR: https://git.openjdk.java.net/jdk/pull/4491

5 12

RFR: 8177814: jdk/editpad is not in jdk TEST.groups
by Aleksey Shipilev 12 Oct '21

12 Oct '21

@prrace notices this here: https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it is the already open issue that this patch is fixing. While the original patch added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`. Additional testing: - [x] `jdk_editpad` is passing ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5648/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5648&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8177814 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5648/head:pull/5648 PR: https://git.openjdk.java.net/jdk/pull/5648

2 5

RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
by Wang Huang 09 Oct '21

09 Oct '21

Dear all, Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. * We add a JMH test case * Here is the result of this test case Benchmark |(size)| Mode| Cnt|Score | Error |Units ---------------------------------|------|-----|----|------|--------|----- StringCompare.compareLL | 64 | avgt| 5 |7.992 | ± 0.005|us/op StringCompare.compareLL | 72 | avgt| 5 |15.029| ± 0.006|us/op StringCompare.compareLL | 80 | avgt| 5 |14.655| ± 0.011|us/op StringCompare.compareLL | 91 | avgt| 5 |16.363| ± 0.12 |us/op StringCompare.compareLL | 101 | avgt| 5 |16.966| ± 0.007|us/op StringCompare.compareLL | 121 | avgt| 5 |19.276| ± 0.006|us/op StringCompare.compareLL | 181 | avgt| 5 |19.002| ± 0.417|us/op StringCompare.compareLL | 256 | avgt| 5 |24.707| ± 0.041|us/op StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ± 0.121|us/op StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ± 0.003|us/op StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ± 0.004|us/op StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ± 0.201|us/op StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ± 0.004|us/op StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ± 1.342|us/op StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ± 0.581|us/op StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ± 1.775|us/op StringCompare.compareUU | 64 | avgt| 5 |13.476| ± 0.01 |us/op StringCompare.compareUU | 72 | avgt| 5 |15.078| ± 0.006|us/op StringCompare.compareUU | 80 | avgt| 5 |23.512| ± 0.011|us/op StringCompare.compareUU | 91 | avgt| 5 |24.284| ± 0.008|us/op StringCompare.compareUU | 101 | avgt| 5 |20.707| ± 0.017|us/op StringCompare.compareUU | 121 | avgt| 5 |29.302| ± 0.011|us/op StringCompare.compareUU | 181 | avgt| 5 |39.31 | ± 0.016|us/op StringCompare.compareUU | 256 | avgt| 5 |54.592| ± 0.392|us/op StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ± 0.008|us/op StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ± 0.158|us/op StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ± 0.024|us/op StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ± 0.006|us/op StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ± 0.434|us/op StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ± 0.016|us/op StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ± 0.017|us/op StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ± 3.5 |us/op >From this table, we can see that in most cases, our patch is better than old one. Thank you for your review. Any suggestions are welcome. ------------- Commit messages: - 8268231: Aarch64: Use ldp in intrinsics for String.compareTo Changes: https://git.openjdk.java.net/jdk/pull/4722/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268231 Stats: 259 lines in 3 files changed: 255 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4722/head:pull/4722 PR: https://git.openjdk.java.net/jdk/pull/4722

6 40

RFR: 8274525: Replace uses of StringBuffer with StringBuilder in java.xml
by Andrey Turbanov 06 Oct '21

06 Oct '21

StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: 1. Plain String concatenation should be preferred 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance ------------- Commit messages: - [PATCH] Cleanup usages of StringBuffer in java.xml Changes: https://git.openjdk.java.net/jdk/pull/5759/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5759&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274525 Stats: 32 lines in 5 files changed: 0 ins; 11 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5759/head:pull/5759 PR: https://git.openjdk.java.net/jdk/pull/5759

5 5

RFR: 8273711: Remove redundant stream() call before forEach in jdk.jlink
by Andrey Turbanov 06 Oct '21

06 Oct '21

8273711: Remove redundant stream() call before forEach in jdk.jlink ------------- Commit messages: - [PATCH] Remove redundant stream() call before forEach in jdk.jlink Changes: https://git.openjdk.java.net/jdk/pull/5500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5500&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273711 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5500/head:pull/5500 PR: https://git.openjdk.java.net/jdk/pull/5500

4 5