March 2021 - core-libs-dev

RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview
by Patrick Concannon 09 Mar '21

09 Mar '21

Hi, Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). Kind regards, Patrick ------------- Commit messages: - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview Changes: https://git.openjdk.java.net/jdk/pull/2544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252399 Stats: 68 lines in 2 files changed: 64 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544

5 17

RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
by Patrick Concannon 09 Mar '21

09 Mar '21

Hi, Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable? Kind regards, Patrick ------------- Commit messages: - 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/2879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2879&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263190 Stats: 60 lines in 15 files changed: 0 ins; 27 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/2879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2879/head:pull/2879 PR: https://git.openjdk.java.net/jdk/pull/2879

10 10

RFR: 8262001: java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
by Alex Menkov 09 Mar '21

09 Mar '21

The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures. Additional changes: - store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better); - flags for thread termination are moved to thread class; - store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values) ------------- Commit messages: - Update ResetPeakThreadCount.java Changes: https://git.openjdk.java.net/jdk/pull/2885/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2885&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262001 Stats: 139 lines in 1 file changed: 20 ins; 61 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/2885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2885/head:pull/2885 PR: https://git.openjdk.java.net/jdk/pull/2885

1 0

RFR: 8263038: Optimize String.format for simple specifiers
by Claes Redestad 08 Mar '21

08 Mar '21

This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this. Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings. ------------- Commit messages: - Fix boundary condition - Add complex pattern micro - Harmonize micro to generate same length strings and mix trivial and non-trivial specifiers - Accidentally mutating Flags.NONE - Merge branch 'master' into format_opt - Fixes, cleanups, improvements - Consolidate slow path - Fix various edge cases - Improve Formatter for simple patterns Changes: https://git.openjdk.java.net/jdk/pull/2830/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263038 Stats: 265 lines in 2 files changed: 121 ins; 58 del; 86 mod Patch: https://git.openjdk.java.net/jdk/pull/2830.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2830/head:pull/2830 PR: https://git.openjdk.java.net/jdk/pull/2830

3 17

RFR: 8261366: Add discussion of IEEE 754 to BigDecimal
by Joe Darcy 08 Mar '21

08 Mar '21

Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic. Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc. ------------- Commit messages: - 8261366: Add discussion of IEEE 754 to BigDecimal Changes: https://git.openjdk.java.net/jdk/pull/2868/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2868&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261366 Stats: 88 lines in 3 files changed: 60 ins; 3 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/2868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2868/head:pull/2868 PR: https://git.openjdk.java.net/jdk/pull/2868

4 6

RFR: 8260664: Phaser.arrive() memory consistency effects
by Martin Buchholz 08 Mar '21

08 Mar '21

8260664: Phaser.arrive() memory consistency effects ------------- Commit messages: - JDK-8260664 Changes: https://git.openjdk.java.net/jdk/pull/2388/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2388&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260664 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2388.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2388/head:pull/2388 PR: https://git.openjdk.java.net/jdk/pull/2388

2 3

Question about java.system.class.loader and the module system
by Volker Simonis 08 Mar '21

08 Mar '21

Hi, I have a question about how changing the system class loader by setting "java.system.class.loader" interacts with the module system. I couldn't find a lot of information on this topic but if it has been discussed before please point me to the corresponding place. Traditionally, setting "java.system.class.loader" to the name of a class loader will instruct the JVM to use that class loader as the system class loader which will be used to load the application main class. But this class loader has to be loaded itself by a class loader. So the JVM defines its own "default system class loader" which will be used to load the custom system class loader and which will act as delegation parent for it [1]. By writing a custom class loader which intercepts calls to loadClass() and defining it as the system class loader by setting "java.system.class.loader" it can be easily verified that the JVM will load the applications main class with that custom class loader. This behaviour changes however if we use the new module syntax "-m <module>/<class>" to start an application. In that case, the main application class will always be loaded by the default system class loader, no matter if we define "java.system.class.loader" or not. >From what I've found by looking into the sources, this is because the application module will be added to the boot layer and associated with the default system class loader early in the JVM boot process (i.e. "initPhase2") when only classes from java.base can be loaded and the custom class loader is therefore not available. The system class loader is only initialized later in "initiPhase3" at which it seems to be already to late to associate it with the application module (is this really the case?). My question now is if this is an inherent property of the module system or merely an implementation detail? I.e. would it be possible to put the application module into its own layer and initialize that only later when the custom system class loader will be available? I think this would be relatively easy if the custom class loader can be found on the class path. If the custom class loader is in a module itself, that module would have to be in the boot layer to make it accessible to the default system class loader. The current API documentation of the system class loader [1] mentions that the system class loader "is typically the class loader used to start the application". Shouldn't that be updated to mention that this will not be the case for modular applications? Thank you and best regards, Volker [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Clas…

2 3

RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category)
by Claes Redestad 08 Mar '21

08 Mar '21

This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy. ------------- Commit messages: - Add microbenchmark - Reduce volatile reads in Locale.getDefault(Category) Changes: https://git.openjdk.java.net/jdk/pull/2845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263090 Stats: 92 lines in 2 files changed: 72 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2845/head:pull/2845 PR: https://git.openjdk.java.net/jdk/pull/2845

6 14

RFR: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
by Claes Redestad 08 Mar '21

08 Mar '21

This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up. I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement. ------------- Commit messages: - Fold CharacterData.isOtherUpper-/Lowercase into isUpper-/LowerCase Changes: https://git.openjdk.java.net/jdk/pull/2846/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2846&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263091 Stats: 98 lines in 8 files changed: 1 ins; 71 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/2846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2846/head:pull/2846 PR: https://git.openjdk.java.net/jdk/pull/2846

4 5

ThreadLocal lookup elimination
by Eirik Bjørsnøs 06 Mar '21

06 Mar '21

Hello, ThreadLocals are commonly used to transfer state across method boundaries in situations where passing them as method parameters is impractical. Examples include crossing APIs you don't own, or instrumenting code you don't own. Consider the following pseudo-instrumented code (where the original code calls a getter inside a loop): public class Student { private int age; public int maxAge(Student[] students) { // Instrumented code: ExpensiveObject expensive = new ExpensiveObject(); expensive.recordSomething(); threadLocal.set(expensive); // Original code: int max = 0; for (Student student : students) { max = Math.max(max, student.getAge()); } return max; } public int getAge() { // Instrumented code ExpensiveObject exp = threadLocal.get(); exp.recordSomething(); // Original code: return age; } // Instrumented field: private static ThreadLocal<ExpensiveObject> threadLocal = new ThreadLocal<>(); } The ThreadLocal is used here to avoid constructing ExpensiveObject instances in each invocation of getAge. However, once a compiler worth its salt sees this code, it immediately wants to inline the getAge method: // Instrumented code: ExpensiveObject expensive = new ExpensiveObject(); expensive.recordSomething(); threadLocal.set(expensive); for (Student student : students) { // Instrumented code ExpensiveObject exp = threadLocal.get(); exp.recordSomething(); // Original code max = Math.max(max, student.age); } At this point, we see that the last write to threadLocal is 'expensive', so any following 'threadLocal.get()' should be substitutable for 'expensive'. So we could do the following instead: for (Student student : students) { // Instrumented code expensive.recordSomething(); // Original code max = Math.max(max, student.age); } More generally, a compiler could record the first lookup of a ThreadLocal in a scope and substitute any following lookup with the first read (until the next write). I'm pretty sure this would be immensely useful for my current use case (which instruments methods to count invocations), but perhaps it is also a useful optimization in a more general sense? Examples that come to mind are enterprise apps where transaction and security contexts are passed around using ThreadLocals. Has this type of optimization been discussed before? Is it even possible to implement, or did I miss some dragons hiding in the details? What would the estimated work for an implementation look like? Are we looking at bachelor's thesis? Master's thesis? PhD? Would love to hear some thoughts on this idea. Cheers, Eirik.

3 5