February 2021 - core-libs-dev

RFR: 8261851: update ReflectionCallerCacheTest.java test to use ForceGC from test library
by Mandy Chung 17 Feb '21

17 Feb '21

Update test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java to use ForceGC from test library which has additional instrumentation to diagnose problem. In addition, this will get the fix for JDK-8258007. ------------- Commit messages: - fix copyright header update - update copyright header - 8261851: update test to use ForceGC from test library Changes: https://git.openjdk.java.net/jdk/pull/2597/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2597&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261851 Stats: 39 lines in 1 file changed: 1 ins; 37 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2597.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2597/head:pull/2597 PR: https://git.openjdk.java.net/jdk/pull/2597

2 2

Comment on 8259896: Base64 MIME decoder should allow unrecognised characters within padding
by Raffaello Giulietti 17 Feb '21

17 Feb '21

Hi, in my opinion, the reporter of [1] is right in requiring that extraneous characters be discarded, even inside the padding. Indeed, the first full paragraph on [2] reads: "Any characters outside of the base64 alphabet are to be ignored in base64-encoded data." where "the base64 alphabet" also includes the padding character '=' and "base64-encoded data" extends to padding as well, because padding is an essential part of encoding. The legitimate doubt expressed in comment [3] should thus be solved in favor of a bug fix. My 2 cents Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8259896 [2] https://tools.ietf.org/html/rfc2045#page-26 [3] https://bugs.openjdk.java.net/browse/JDK-8259896?focusedCommentId=14395485&…

2 1

RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods
by Joe Darcy 17 Feb '21

17 Feb '21

A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. ------------- Commit messages: - Merge branch 'master' into 8261123 - Initial changes for JDK-8261123. Changes: https://git.openjdk.java.net/jdk/pull/2471/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261123 Stats: 80 lines in 4 files changed: 38 ins; 14 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471

5 33

RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702
by Christoph Langer 16 Feb '21

16 Feb '21

After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. java.lang.Error: 11.2 != 11.2.1 This is a proposal to relax the test and throw a SkippedException in such cases. ------------- Commit messages: - JDK-8261753 Changes: https://git.openjdk.java.net/jdk/pull/2576/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2576&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261753 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2576/head:pull/2576 PR: https://git.openjdk.java.net/jdk/pull/2576

2 7

RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage
by Matthias Baesken 16 Feb '21

16 Feb '21

JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage ------------- Commit messages: - JDK-8261422 Changes: https://git.openjdk.java.net/jdk/pull/2483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2483&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261422 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2483/head:pull/2483 PR: https://git.openjdk.java.net/jdk/pull/2483

5 8

RFR: 8261731: shallow copy the internal buffer of a scalar-replaced java.lang.String object
by Xin Liu 15 Feb '21

15 Feb '21

There are 3 nodes involving in the construction of a java.lang.String object. 1. Allocate of itself, aka. alloc 2. AllocateArray of a byte array, which is value:byte[], aka. aa 3. ArrayCopyNode which copys in the contents of value, aka. ac Lemma When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`. Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well. It is possible to rewire `aa` to the source of ac with the correct offset. That is to say, we can replace both `aa` and `ac` with a “shallow copy” of the source of `ac`. It’s safe if C2 keeps a reference of the source oop for all safepoints. ------------- Commit messages: - fix regression for x86-32 - add a statistical counter for OptimizeTempArray. - [SIM-JVM-450] support deoptimization v2 - add a unit test for deoptimization - [SIM-JVM-450] support deoptimization part2 - enable OptimizeTempArray by default - Merge branch 'master' into optimize_substring - Revert "8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set" - Revert "add a new bucket afterea_late_inlines" - [SIM-JVM-450] support deoptimization - ... and 25 more: https://git.openjdk.java.net/jdk/compare/4619f372...fd9ca4b8 Changes: https://git.openjdk.java.net/jdk/pull/2570/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2570&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261731 Stats: 861 lines in 16 files changed: 844 ins; 2 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2570.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2570/head:pull/2570 PR: https://git.openjdk.java.net/jdk/pull/2570

1 0

Thread safety of SunFontManager.platformFontMap
by Andrey Turbanov 13 Feb '21

13 Feb '21

Hello. I recently found suspicious field (with SpotBugs help) in class SunFontManager: static HashMap<String, FamilyDescription> platformFontMap; This HashMap is accessed (read and write) in a method sun.font.SunFontManager#findFontFromPlatformMap. As I see there is no synchronization when this HashMap is accessed. This method can be called from client code with this simple stack trace: at sun.font.SunFontManager.findFontFromPlatformMap(SunFontManager.java:1508) at sun.font.SunFontManager.findFont2D(SunFontManager.java:2069) at java.awt.Font.getFont2D(Font.java:500) at java.awt.Font.getPSName(Font.java:1416) I wonder if this unsynchronized access is expected. Looks like it can break things when accessed from multiple threads simultaneously. Do I miss something? Is it done this way, because Font objects are supposed to be accessed from a single thread only? Andrey Turbanov

1 0

RFR: 8260401: StackOverflowError on open WindowsPreferences
by Jaikiran Pai 13 Feb '21

13 Feb '21

Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8260401? As noted in that issue, when the constructor of `java.util.prefs.WindowsPreferences` runs into an error while dealing with the Windows registry, it logs a warning message. The message construction calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being constructed) which then ultimately ends up calling the constructor of `WindowsPreferences` which then again runs into the Windows registry error and attempts to log a message and this whole cycle repeats indefinitely leading to that `StackOverFlowError`. Based on my limited knowledge of the code in that constructor and analyzing that code a bit, it's my understanding (and also the input provided by the reporter of the bug) that the log message should actually be using the `rootNativeHandle` parameter that is passed to this constructor instead of invoking the `rootNativeHandle()` method. The commit in this PR does this change to use the passed `rootNativeHandle` in the log message. Furthermore, there's another constructor in this class which does a similar thing and potentially can run into the same error as this one. I've changed that constructor too, to avoid the call to `rootNativeHandle()` method in that log message. Reading the log message that's being generated there, it's my understanding that this change shouldn't cause any inaccuracy in what's being logged and in fact, I think it's now more precise about which handle returned the error code. Finally, this log message creation, in both the constructors, also calls `windowsAbsolutePath()` and `byteArrayToString()` methods. The `byteArrayToString()` is a static method and a call to it doesn't lead back to the constructor again. The `windowsAbsolutePath()` is a instance method and although it does use a instance variable `absolutePath`, that instance variable is already initialized appropriately by the time this `windowsAbsolutePath()` gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't lead back to the constructor of the `WindowsPreferences` so it doesn't pose the same issue as a call to `rootNativeHandle()`. Given the nature of this issue, I haven't added any jtreg test for this change. ------------- Commit messages: - 8260401: StackOverflowError on open WindowsPreferences Changes: https://git.openjdk.java.net/jdk/pull/2326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260401 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2326/head:pull/2326 PR: https://git.openjdk.java.net/jdk/pull/2326

2 11

RFR: 8261160: Add a deserialization JFR event
by Chris Hegarty 12 Feb '21

12 Feb '21

This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. ------------- Commit messages: - minor cleanup; all tests passing - Unconditionally fire a deser event regardless of filter, and add test - commit 2 - commit 1 Changes: https://git.openjdk.java.net/jdk/pull/2479/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261160 Stats: 516 lines in 12 files changed: 496 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479

5 22

RFR: 8261004: java.util.Formatter throws wrong exception for mismatched flags in %% conversion
by Ian Graves 12 Feb '21

12 Feb '21

Updating the specification to reflect well-established behavior in Formatter when incorrect flags used for `%`. ------------- Commit messages: - Changing docs to reflect behavior Changes: https://git.openjdk.java.net/jdk/pull/2389/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2389&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261004 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2389/head:pull/2389 PR: https://git.openjdk.java.net/jdk/pull/2389

2 2