March 2021 - core-libs-dev

RFR: 8263890: Broken links to Unicode.org
by Naoto Sato 19 Mar '21

19 Mar '21

Fixed several broken links to Unicode.org. ------------- Commit messages: - 8263890: Broken links to Unicode.org Changes: https://git.openjdk.java.net/jdk/pull/3093/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3093&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263890 Stats: 22 lines in 8 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/3093.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3093/head:pull/3093 PR: https://git.openjdk.java.net/jdk/pull/3093

4 7

RFR: 8263658: Use the blessed modifier order in java.base
by Alex Blewitt 19 Mar '21

19 Mar '21

Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required. ------------- Commit messages: - 8263658: Use the blessed modifier order in java.base Changes: https://git.openjdk.java.net/jdk/pull/3094/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3094&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263658 Stats: 19 lines in 5 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3094/head:pull/3094 PR: https://git.openjdk.java.net/jdk/pull/3094

4 5

RFR: 8263885: Use the blessed modifier order in java.sql/rowset/transation.xa
by Alex Blewitt 19 Mar '21

19 Mar '21

Fixes for the `java.sql`, `java.sql.rowset` and `java.transaction.xa` packages. @cl4es would you mind creating a subtask of JDK-8263854 so I can update the PR title? ------------- Commit messages: - Use the blessed modifier order in java.sql/rowset/transation.xa Changes: https://git.openjdk.java.net/jdk/pull/3090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3090&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263885 Stats: 133 lines in 6 files changed: 0 ins; 0 del; 133 mod Patch: https://git.openjdk.java.net/jdk/pull/3090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3090/head:pull/3090 PR: https://git.openjdk.java.net/jdk/pull/3090

3 4

RFR: JDK-8263545: Convert jpackage to use Stream.toList()
by Ian Graves 19 Mar '21

19 Mar '21

This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions. ------------- Commit messages: - Converting jpackage to use Stream.toList() Changes: https://git.openjdk.java.net/jdk/pull/2997/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2997&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263545 Stats: 47 lines in 17 files changed: 1 ins; 3 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/2997.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2997/head:pull/2997 PR: https://git.openjdk.java.net/jdk/pull/2997

4 13

RFR: 8263658: Use the blessed modifier order in java.base
by Alex Blewitt 19 Mar '21

19 Mar '21

Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred. This fixes the issues in the `java.base` package for ease of reviewing. https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolve… ------------- Commit messages: - 8263658: Use the blessed modifier order in java.base Changes: https://git.openjdk.java.net/jdk/pull/2993/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263658 Stats: 140 lines in 29 files changed: 0 ins; 0 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/2993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2993/head:pull/2993 PR: https://git.openjdk.java.net/jdk/pull/2993

5 15

RFR: 8263821: Remove unused MethodTypeForm canonicalization codes
by Claes Redestad 19 Mar '21

19 Mar '21

MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This removes these canonicalization codes and cleans up related code. ------------- Commit messages: - Minor simplifications - Remove unused MethodTypeForm canonicalization codes Changes: https://git.openjdk.java.net/jdk/pull/3075/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3075&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263821 Stats: 45 lines in 2 files changed: 0 ins; 35 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3075/head:pull/3075 PR: https://git.openjdk.java.net/jdk/pull/3075

2 4

Re: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields(Internet mail)
by linzang(臧琳) 19 Mar '21

19 Mar '21

Hi Lance, Thanks a lot for your comments! The CSR has been proposed at https://bugs.openjdk.java.net/browse/JDK-8263793, but it seems I can not add it to the github PR. I am WIP on the test coverage, will update the PR when it is ready. BRs, Lin From: Lance Andersen <lance.andersen(a)oracle.com> Date: Thursday, March 18, 2021 at 11:25 PM To: Lin Zang <lzang(a)openjdk.java.net> Cc: "core-libs-dev(a)openjdk.java.net" <core-libs-dev(a)openjdk.java.net> Subject: Re: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields(Internet mail) Hi Lin, Thank you for your contribution. I have no looked at this in any detail. A few general comments: · This will require a CSR · Please update your PR to include test coverage demonstrating that the data can be written and then read back Best, Lance On Mar 18, 2021, at 6:57 AM, Lin Zang <lzang(a)openjdk.java.net<mailto:lzang@openjdk.java.net>> wrote: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields ------------- Commit messages: - remove trailing spaces - 4890732: support optional GZIP fields in GZIPOutputStream Changes: https://git.openjdk.java.net/jdk/pull/3072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4890732 Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072 [cid:image001.gif@01D71CAA.9557DB60] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com<mailto:Lance.Andersen@oracle.com>

1 0

RFR: 8263320: [test] Add Object Stream Formatter to work with test utility HexPrinter
by Roger Riggs 18 Mar '21

18 Mar '21

ObjectStreamPrinter is a Formatter plugin to the test library HexPrinter. A binary stream of serialized java objects is converted into a textual form by parsing the header, typecodes, and interpreting the stream contents. The formatter can be used standalone or with the HexPrinter to align the formatted stream with the corresponding hexadecimal bytes. StreamDump is a test utility to pass the contents of a file to the HexPrinter utility. The format of the file is guessed from the encoding and initial bytes. ASN.1 and serialized object streams are supported. ------------- Commit messages: - 8263320: [test] Add Object Stream Formatter to work with test utility HexPrinter Changes: https://git.openjdk.java.net/jdk/pull/2900/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2900&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263320 Stats: 1684 lines in 4 files changed: 1684 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2900.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2900/head:pull/2900 PR: https://git.openjdk.java.net/jdk/pull/2900

2 3

RFR: 8260605: Various java.lang.invoke cleanups
by Claes Redestad 18 Mar '21

18 Mar '21

- Remove unused code - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc) - Apply pattern matching to make some code more readable ------------- Commit messages: - Avoid unnecessary reboxing checks, inline and simplify class/mt invokes - j.l.invoke cleanups Changes: https://git.openjdk.java.net/jdk/pull/2300/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260605 Stats: 269 lines in 14 files changed: 11 ins; 161 del; 97 mod Patch: https://git.openjdk.java.net/jdk/pull/2300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300 PR: https://git.openjdk.java.net/jdk/pull/2300

2 14

RFR: 8263108: Class initialization deadlock in java.lang.constant
by Jaikiran Pai 18 Mar '21

18 Mar '21

Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108? As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows: "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait() [0x000070000a4c6000] java.lang.Thread.State: RUNNABLE at java.lang.constant.DynamicConstantDesc.<clinit>(java.base@16-ea/DynamicConstantDesc.java:67) - waiting on the Class initialization monitor for java.lang.constant.ConstantDescs at Deadlock.threadA(Deadlock.java:14) at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source) at java.lang.Thread.run(java.base@16-ea/Thread.java:831) "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait() [0x000070000a5c9000] java.lang.Thread.State: RUNNABLE at java.lang.constant.ClassDesc.ofDescriptor(java.base@16-ea/ClassDesc.java:145) - waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc at java.lang.constant.ConstantDescs.<clinit>(java.base@16-ea/ConstantDescs.java:239) at Deadlock.threadB(Deadlock.java:24) at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source) at java.lang.Thread.run(java.base@16-ea/Thread.java:831) The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map. The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time. An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference. The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test. ------------- Commit messages: - 8263108: Class initialization deadlock in java.lang.constant Changes: https://git.openjdk.java.net/jdk/pull/2893/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263108 Stats: 170 lines in 2 files changed: 160 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2893.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2893/head:pull/2893 PR: https://git.openjdk.java.net/jdk/pull/2893

4 23