December 2021 - core-libs-dev

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: 8273322: Enhance macro logic optimization for masked logic operations.
by Jatin Bhateja 06 Jan '22

06 Jan '22

Patch extends existing macrologic inferencing algorithm to handle masked logic operations. Existing algorithm: 1. Identify logic cone roots. 2. Packs parent and logic child nodes into a MacroLogic node in bottom up traversal if input constraint are met. i.e. maximum number of inputs which a macro logic node can have. 3. Perform symbolic evaluation of logic expression tree by assigning value corresponding to a truth table column to each input. 4. Inputs along with encoded function together represents a macro logic node which mimics a truth table. Modification: Extended the packing algorithm to operate on both predicated or non-predicated logic nodes. Following rules define the criteria under which nodes gets packed into a macro logic node:- 1. Parent and both child nodes are all unmasked or masked with same predicates. 2. Masked parent can be packed with left child if it is predicated and both have same prediates. 3. Masked parent can be packed with right child if its un-predicated or has matching predication condition. 4. An unmasked parent can be packed with an unmasked child. New jtreg test case added with the patch exhaustively covers all the different combinations of predications of parent and child nodes. Following are the performance number for JMH benchmark included with the patch. Machine Configuration: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (40C 2S Icelake Server) Benchmark | ARRAYLEN | Baseline (ops/s) | Withopt (ops/s) | Gain ( withopt/baseline) -- | -- | -- | -- | -- o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 64 | 2365.421 | 5136.283 | 2.171403315 o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 128 | 2034.1 | 4073.381 | 2.002547072 o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 256 | 1568.694 | 2811.975 | 1.792558013 o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 512 | 883.261 | 1662.771 | 1.882536419 o.o.b.vm.compiler.MacroLogicOpt.workload1_caller | 1024 | 469.513 | 732.81 | 1.560787454 o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 64 | 273.049 | 552.106 | 2.022003377 o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 128 | 219.624 | 359.775 | 1.63814064 o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 256 | 131.649 | 182.23 | 1.384211046 o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 512 | 71.452 | 81.522 | 1.140933774 o.o.b.vm.compiler.MacroLogicOpt.workload2_caller | 1024 | 37.427 | 41.966 | 1.121276084 o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 64 | 2805.759 | 3383.16 | 1.205791374 o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 128 | 2069.012 | 2250.37 | 1.087654397 o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 256 | 1098.766 | 1101.996 | 1.002939661 o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 512 | 470.035 | 484.732 | 1.031267884 o.o.b.vm.compiler.MacroLogicOpt.workload3_caller | 1024 | 202.827 | 209.073 | 1.030794717 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt128 | 256 | 3435.989 | 4418.09 | 1.285827749 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt128 | 512 | 1524.803 | 1678.201 | 1.100601848 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt128 | 1024 | 972.501 | 1166.734 | 1.199725244 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt256 | 256 | 5980.85 | 7584.17 | 1.268075608 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt256 | 512 | 3258.108 | 3939.23 | 1.209054457 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt256 | 1024 | 1475.365 | 1511.159 | 1.024261115 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt512 | 256 | 4208.766 | 4220.678 | 1.002830283 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt512 | 512 | 2056.651 | 2049.489 | 0.99651764 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationInt512 | 1024 | 1110.461 | 1116.448 | 1.005391455 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong256 | 256 | 3259.348 | 3947.94 | 1.211266793 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong256 | 512 | 1515.147 | 1536.647 | 1.014190042 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong256 | 1024 | 911.58 | 1030.54 | 1.130498695 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong512 | 256 | 2034.611 | 2073.764 | 1.019243482 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong512 | 512 | 1110.659 | 1116.093 | 1.004892591 o.o.b.jdk.incubator.vector.MaskedLogicOpts.bitwiseBlendOperationLong512 | 1024 | 559.269 | 559.651 | 1.000683034 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt128 | 256 | 3636.141 | 4446.505 | 1.222863745 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt128 | 512 | 1433.145 | 1681.261 | 1.173126934 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt128 | 1024 | 1000.107 | 1172.866 | 1.172740517 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt256 | 256 | 5568.313 | 7670.259 | 1.37748345 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt256 | 512 | 3350.108 | 3927.803 | 1.172440709 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt256 | 1024 | 1495.966 | 1541.56 | 1.030477965 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt512 | 256 | 4230.379 | 4282.154 | 1.012238856 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt512 | 512 | 2029.801 | 2049.638 | 1.009772879 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsInt512 | 1024 | 1108.738 | 1118.897 | 1.00916267 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsLong256 | 256 | 3802.801 | 3783.537 | 0.99493426 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsLong256 | 512 | 1546.244 | 1552.691 | 1.004169458 o.o.b.jdk.incubator.vector.MaskedLogicOpts.maskedLogicOperationsLong256 | 1024 | 1017.512 | 1020.075 | 1.002518889 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt128 | 256 | 4159.835 | 4527.676 | 1.088426825 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt128 | 512 | 1665.335 | 1733.04 | 1.040655484 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt128 | 1024 | 1150.319 | 1181.935 | 1.02748455 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt256 | 256 | 6989.791 | 7382.883 | 1.056238019 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt256 | 512 | 3711.362 | 3911.921 | 1.054039191 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt256 | 1024 | 1540.341 | 1554.175 | 1.008981128 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt512 | 256 | 4164.559 | 4213.546 | 1.01176283 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt512 | 512 | 2072.91 | 2079.105 | 1.002988552 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsInt512 | 1024 | 1112.678 | 1116.675 | 1.003592234 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong256 | 256 | 3702.998 | 3906.093 | 1.0548461 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong256 | 512 | 1536.571 | 1546.043 | 1.006164375 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong256 | 1024 | 996.906 | 1013.649 | 1.016794964 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong512 | 256 | 2045.594 | 2048.966 | 1.001648421 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong512 | 512 | 1111.933 | 1117.689 | 1.005176571 o.o.b.jdk.incubator.vector.MaskedLogicOpts.partiallyMaskedLogicOperationsLong512 | 1024 | 559.971 | 561.144 | 1.002094751 Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - 8273322: Enhance macro logic optimization for masked logic operations. Changes: https://git.openjdk.java.net/jdk/pull/6893/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273322 Stats: 1413 lines in 12 files changed: 1370 ins; 6 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/6893.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6893/head:pull/6893 PR: https://git.openjdk.java.net/jdk/pull/6893

3 17

[jdk18] RFR: 8278897: Alignment of heap segments is not enforced correctly
by Maurizio Cimadamore 05 Jan '22

05 Jan '22

This PR fixes an issue with alignment constraints not being enforced correctly on on-heap segments dereference/copy operations. Alignment of on-heap segments cannot be computed exactly, as alignment of elements in arrays is, ultimately a VM implementation detail. Because of this, alignment checks on heap segments can fail or pass depending on the platform being used. For more details about the problem and the solution please refer to: https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk18/pull/37/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=37&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278897 Stats: 600 lines in 20 files changed: 566 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk18/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk18/pull/37

2 4

RFR: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
by Naoto Sato 04 Jan '22

04 Jan '22

The proposed fix is to address the performance degradation caused by the fix to JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now falls back up to the bundles at Locale.ROOT. However, by lowering the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it can avoid the excess bundle lookups for regions. I also changed the test case `TestZoneTextPrinterParser.java`, which currently iterates over 3 nested loops, i.e., all-locales x all-timezones x 8, which is absolutely unnecessary. Made it to sample some locales. In addition, I added a microbenchmark for the DateFormatSymbols.getZoneStrings() method. Here is the result: Before the fix to JDK-8275721: Benchmark Mode Cnt Score Error Units ZoneStrings.testZoneStrings ss 5 6.865 ± 0.696 s/op Before the proposed fix: Benchmark Mode Cnt Score Error Units ZoneStrings.testZoneStrings ss 5 15.741 ± 4.300 s/op After the proposed fix: Benchmark Mode Cnt Score Error Units ZoneStrings.testZoneStrings ss 5 9.756 ± 3.685 s/op ------------- Commit messages: - Added a microbenchmark for zone strings - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java Changes: https://git.openjdk.java.net/jdk/pull/6790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6790&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278434 Stats: 72 lines in 3 files changed: 59 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6790/head:pull/6790 PR: https://git.openjdk.java.net/jdk/pull/6790

2 4

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

a quick question about String
by Alan Snyder 03 Jan '22

03 Jan '22

Do the public constructors of String actually do what their documentation says (allocate a new instance), or is there some kind of compiler magic that might avoid allocation?

12 14

Type narrowing security leak
by Fabrice Tiercelin 01 Jan '22

01 Jan '22

Greetings, Any Java application may be concerned by a hacker attack using a type narrowing leak. If a program does the following things in this order: - Assert that a numerical id is allowed - Do a type narrowing among other things, even followed by a type widening - Do an action with the numerical id ...the hacker can do forbidden actions. Let's say that a given user doesn't have rights to change an amount for the id 63: public void changeAmount(long userId, double newAmount) throws IllegalArgumentException { isUserIdAllowedOrThrowException(userId); // userId = 4294967359 int theUserId = (int) userId; // theUserId = 63 userId = theUserId; // userId = 63 doChangeAmount(userId, newAmount); // userId = 63 } It will fail passing 63 but it will success passing 4294967359 because 4_294_967_359 is narrowed into 63. Let's call 4_294_967_359 a rebound of 63. 4294967359 can be retrieved in few seconds by a basic program like this: public class MyClass { public static void main(String args[]) { long targettedNumber = 63; for (long rebound = Integer.MAX_VALUE + 1; true; rebound++) { int typeNarrowing = (int) rebound; long typeWidening = typeNarrowing; if (typeWidening == targettedNumber) { System.out.println("Rebound for " + targettedNumber + " found: " + rebound); return; } } } } And it can be optimized. It works for any type narrowing. It not only works for numerical id but also for flags. If a numerical value should contain or not several flags, you can search a rebound among billions of rebounds until you find one with the perfect features. All the Java versions are concerned. The security layer can even be coded in another programming language. To fix it, I suggest to add a test just before the type narrowing in the bytecode. The test verifies if the type narrowing will alter the numerical value. If true, it throws an unchecked exception or an error. Otherwise, it continues as currently. Note that it changes the behavior but the current behavior is dangerous, useless and is a failing case. You can add a compiler option to restore the original behavior but the new behavior should be the default. Best regards,Fabrice TIERCELIN

3 4

RFR: 8279134: Fix Amazon copyright in various files
by Sergey Bylokhov 26 Dec '21

26 Dec '21

This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 Currently, some of the files in the OpenJDK repo have Amazon copyright notices which are all slightly different and do not conform to Amazons preferred copyright notice which is simply (intentionally without copyright year): "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." @simonis @phohensee ------------- Commit messages: - Initial fix JDK-8279134 Changes: https://git.openjdk.java.net/jdk/pull/6915/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6915&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279134 Stats: 15 lines in 14 files changed: 0 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6915/head:pull/6915 PR: https://git.openjdk.java.net/jdk/pull/6915

3 4

RFR: Merge jdk18
by Jesper Wilhelmsson 23 Dec '21

23 Dec '21

Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large - 8268297: jdk/jfr/api/consumer/streaming/TestLatestEvent.java times out - 8279076: C2: Bad AD file when matching SqrtF with UseSSE=0 - 8278967: rmiregistry fails to start because SecurityManager is disabled - 8278239: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine failed with EXCEPTION_ACCESS_VIOLATION at 0x000000000000000d The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6931&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/6931/files Stats: 299 lines in 17 files changed: 141 ins; 126 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/6931.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6931/head:pull/6931 PR: https://git.openjdk.java.net/jdk/pull/6931

1 2

RFR: JDK-8276302: Locale.filterTags methods ignore actual weight when matching "*" (as if it is 1)
by Daniel Le 23 Dec '21

23 Dec '21

Locale.filterTags methods ignore actual weight when matching "*" (as if it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so. Fix the bug and add regression test cases for it as well as existing behavior. ------------- Commit messages: - Locale.filterTags must respect the weight of "*" Changes: https://git.openjdk.java.net/jdk/pull/6789/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6789&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276302 Stats: 121 lines in 2 files changed: 59 ins; 54 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6789.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6789/head:pull/6789 PR: https://git.openjdk.java.net/jdk/pull/6789

2 6