November 2021 - core-libs-dev

RFR: 8277013: Allow creation of module graphs without defining modules to the VM
by Ivan Ristović 08 Jan '22

08 Jan '22

Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013 The GraalVM Native Image module support must create the runtime boot-module layer at image build time; module instances created at build time need to reflect module relations at runtime, i.e., their opens, reads, and exports. To achieve this, we had to duplicate and modify a significant portion of the module synthesis methods from the JDK. The GraalVM PR that demonstrates this duplication can be found at: https://github.com/oracle/graal/blob/9bfa3a312d7d0309eb014d52e49afd7136d9e77e/substratevm/src/com.oracle.svm.hosted.jdk11/src/com/oracle/svm/hosted/ModuleLayerFeature.java#L269 The hard-to-maintain code duplication is necessary as synthesizing module graphs in the JDK unconditionally defines modules to the VM which causes an error due to module redefinition. For example, methods `System.defineModule`, `ModuleLayer` factories and constructor, and `Module` constructor unconditionally update the VM state. All these methods eventually reach the `Module` constructor or the `Modules.defineModules` method. We propose that the `Module` constructor and the `Modules.defineModules` conditionally update the VM state (similarly to 'Module.implAddReads`). The JDK would call these methods so they update the VM state and GraalVM Native Image would call them without updating the state. ------------- Commit messages: - Update parameter names; Add constructor overload for backward compatibility - Enhance Module.defineModules to accept switches to update VM state Changes: https://git.openjdk.java.net/jdk/pull/6356/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6356&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277013 Stats: 52 lines in 1 file changed: 36 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/6356.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6356/head:pull/6356 PR: https://git.openjdk.java.net/jdk/pull/6356

3 3

RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging
by Sergey Bylokhov 07 Jan '22

07 Jan '22

The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via an AppContext to support "applet logging isolation". The AppContext class became useless since the plugin and webstart are no longer supported and removed in jdk11. This is the request to delete the usage of AppContext in the LogManager and related tests. Tested by tier1/tier2/tier3 and jdk_desktop tests. ------------- Commit messages: - Some tests deleted - Update the RootLevelInConfigFile test - Initial version of JDK-8273101 Changes: https://git.openjdk.java.net/jdk/pull/5326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273101 Stats: 1423 lines in 10 files changed: 0 ins; 1418 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5326/head:pull/5326 PR: https://git.openjdk.java.net/jdk/pull/5326

6 18

RFR: 8276700: Improve java.lang.ref.Cleaner javadocs
by Hendrik Schreiber 03 Jan '22

03 Jan '22

Trivial improvement. Explicitly show how to create a `Cleaner` instance using `Cleaner.create()`. Repeat (again) in the code example that the `State` `Runnable `should be implemented as static class and not reference the instance to be cleaned, to make the point even more clear to those people who never read the javadoc *prose*. I have signed the OCA a while back as [hschreiber](https://openjdk.java.net/census#hschreiber). ------------- Commit messages: - Improved java.lang.ref.Cleaner javadocs. Changes: https://git.openjdk.java.net/jdk/pull/6076/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6076&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276700 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6076.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6076/head:pull/6076 PR: https://git.openjdk.java.net/jdk/pull/6076

7 26

RFR: 8277868: Use Comparable.compare() instead of surrogate code
by Сергей Цыпанов 16 Dec '21

16 Dec '21

Instead of something like long x; long y; return (x < y) ? -1 : ((x == y) ? 0 : 1); we can use `return Long.compare(x, y);` All replacements are done with IDE. ------------- Commit messages: - 8277868: Use Comparable.compare() instead of surrogate code Changes: https://git.openjdk.java.net/jdk/pull/6575/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6575&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277868 Stats: 70 lines in 12 files changed: 2 ins; 44 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/6575.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6575/head:pull/6575 PR: https://git.openjdk.java.net/jdk/pull/6575

6 14

RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content
by Andrew Leonard 11 Dec '21

11 Dec '21

Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic. Signed-off-by: Andrew Leonard <anleonar(a)redhat.com> ------------- Commit messages: - 8276766: Enable jar and jmod to produce deterministic timestamped content - 8276766: Enable jar and jmod to produce deterministic timestamped content Changes: https://git.openjdk.java.net/jdk/pull/6481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276766 Stats: 169 lines in 10 files changed: 141 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/6481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481 PR: https://git.openjdk.java.net/jdk/pull/6481

9 110

RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive
by Roman Kennke 10 Dec '21

10 Dec '21

The caches in ObjectStreamClass basically map WeakReference<Class> to SoftReference<ObjectStreamClass>, where the ObjectStreamClass also references the same Class. That means that the cache entry, and thus the class and its class-loader, will not get reclaimed, unless the GC determines that memory pressure is very high. However, this seems bogus, because that unnecessarily keeps ClassLoaders and all its classes alive much longer than necessary: as soon as a ClassLoader (and all its classes) become unreachable, there is no point in retaining the stuff in OSC's caches. The proposed change is to use WeakReference instead of SoftReference for the values in caches. Testing: - [x] tier1 - [x] tier2 - [ ] tier3 - [ ] tier4 ------------- Commit messages: - Fix indentation of new testcase - 8277072: ObjectStreamClass caches keep ClassLoaders alive Changes: https://git.openjdk.java.net/jdk/pull/6375/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6375&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277072 Stats: 112 lines in 2 files changed: 107 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6375.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6375/head:pull/6375 PR: https://git.openjdk.java.net/jdk/pull/6375

5 35

RFR: JDK-8273146: Start of release updates for JDK 19
by Joe Darcy 09 Dec '21

09 Dec '21

The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates: JDK-8277512: Add SourceVersion.RELEASE_19 https://bugs.openjdk.java.net/browse/JDK-8277512 JDK-8277514: Add source 19 and target 19 to javac https://bugs.openjdk.java.net/browse/JDK-8277514 Clean local tier 1 test runs for langtools, jdk, and hotspot. ------------- Commit messages: - Add --release 18 information. Good tier1 test results. - JDK-8273146: Start of release updates for JDK 19 Changes: https://git.openjdk.java.net/jdk/pull/6493/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273146 Stats: 3242 lines in 67 files changed: 3202 ins; 0 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/6493.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493 PR: https://git.openjdk.java.net/jdk/pull/6493

7 19

RFR: 8277992: Add fast jdk_svc subtests to jdk:tier3
by Aleksey Shipilev 07 Dec '21

07 Dec '21

OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly long-running vmTestbase tests, which take many hours even on a very parallel machines. This, unfortunately, has a chilling effect on `jdk:tier4`, which is seldom run by contributors, because `hotspot:tier4` is in the way. But, there are plenty of fast and stable tests in `jdk:tier4` that can be run in `jdk:tier3`. `jdk_svc` is the example of such tests: management features (including but not limited to JFR) are important to keep from regressions, and significant subset of them runs pretty fast. So, it makes sense to move some `jdk_svc` tests to `jdk:tier3` to expose it to more contributors. I think the only group we don't want to run is `svc_tools`, which includes lots of non-parallel tests that are rather slow. Sample run before: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/jdk:tier3 174 174 0 0 ============================== TEST SUCCESS Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' real 2m38.242s user 80m7.216s sys 2m13.846s ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier4 2904 2901 3 0 << ============================== TEST FAILURE real 18m13.933s user 546m50.556s sys 25m7.086s Sample run after: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/jdk:tier3 1296 1296 0 0 ============================== TEST SUCCESS Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' real 7m49.017s user 287m30.943s sys 13m20.060s ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier4 1783 1780 3 0 << ============================== TEST FAILURE real 12m19.973s user 351m48.561s sys 14m51.566s ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6619/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6619&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277992 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6619/head:pull/6619 PR: https://git.openjdk.java.net/jdk/pull/6619

6 15

RFR: JDK-8276447 Deprecate finalization-related methods for removal
by Brent Christian 06 Dec '21

06 Dec '21

Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. The CSR has been approved. An automated test build+test run passes cleanly (FWIW :D ). ------------- Commit messages: - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - Fix @since on @Deprecated for java.lang.Enum - Clarify conditions for removal of Object.finalize method - ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2 Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276447 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465

9 14

RFR: 8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh()
by Vamsi Parasa 03 Dec '21

03 Dec '21

This change optimizes random number generators using Math.unsignedMultiplyHigh() ------------- Commit messages: - Update Math.java - 8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh() Changes: https://git.openjdk.java.net/jdk/pull/6206/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6206&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275821 Stats: 31 lines in 3 files changed: 0 ins; 28 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6206/head:pull/6206 PR: https://git.openjdk.java.net/jdk/pull/6206

4 17