From raffaello.giulietti at gmail.com Sat Jan 1 19:45:34 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Sat, 1 Jan 2022 20:45:34 +0100 Subject: Type narrowing security leak In-Reply-To: <417610419.33595.1640760201406@mail.yahoo.com> References: <417610419.33595.1640760201406.ref@mail.yahoo.com> <417610419.33595.1640760201406@mail.yahoo.com> Message-ID: <48e2e805-c79f-3bdc-ac07-211d2948cba1@gmail.com> Hi, if I understand correctly, you are supposing that method changeAmount() is part of a security sensitive application under attack. Its implementation first attempts a data validation by invoking isUserIdAllowedOrThrowException(), then transforms validated data in a lossy way (narrowing, then widening) for further usage (invoking doChangeAmount()). A seriously conducted review of security related code, whether by experienced engineers or by means of tools, would reject this code as fatally flawed in the first place, code that should never become productive. (BTW, (1L << Integer.SIZE) + 63 is a more efficient way to produce e rebound of 63 for your example.) Yours is just one example of the more general class of integer overflow attacks that potentially affects modular integer arithmetic in Java and many other languages. To prevent such attacks, operations on integer values should throw on overflow. Modifying the Java spec to mandate throwing on overflow would be a substantial change with major compatibility issues and preventing many legitimate usages of modular arithmetic as it is currently specified. Security sensitive code can (and does) make good use of j.l.Math.*Exact() methods (addExact(), toIntExact(), etc.) Greetings Raffaello On 2021-12-29 07:43, Fabrice Tiercelin wrote: > 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 > From raffaello.giulietti at gmail.com Sat Jan 1 19:59:35 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Sat, 1 Jan 2022 20:59:35 +0100 Subject: a quick question about String In-Reply-To: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com> References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com> Message-ID: <8fa8466f-3be5-9296-d79b-19634d8a28cb@gmail.com> Hello, the simple answer is that new String(...) == new String(...) *never* evaluates to true )it might throw, though), whatever constructors you are using and whatever arguments you pass to to them. Some garbage collectors *might* de-duplicate the underlying arrays (but you cannot tell), but the references to the Strings will be different. HTH Raffaello On 2021-12-23 18:59, Alan Snyder wrote: > 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? > From kim.barrett at oracle.com Sun Jan 2 07:46:36 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 2 Jan 2022 07:46:36 +0000 Subject: a quick question about String In-Reply-To: References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com> <8B4C1375-48D1-45A9-AB65-3085228864CD@cbfiddle.com> Message-ID: > On Dec 24, 2021, at 2:46 PM, liangchenblue at gmail.com wrote: > >> Are you saying that new would always create a new object but the GC might merge multiple instances of String into a single instance? > > About jvm's string optimizations, jvm may make different string > objects with the same content share the backing array in order to > reduce allocation (like what the original poster alan wonders). This > optimization does not alter the identity of the relative string > objects and thus has zero effect on the user end. For HotSpot this is enabled by -XX:+UseStringDeduplication. For more details see https://openjdk.java.net/jeps/192 Note that as of JDK 18 all of the HotSpot collectors support this, not just G1. From shade at openjdk.java.net Mon Jan 3 08:17:37 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 3 Jan 2022 08:17:37 GMT Subject: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 Message-ID: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Seems like a missing include. C++ docs say `offsetof` is from ``, adding that include explicitly fixes the build. Seems to only happen with older GCCs, but it seems to be a happy accident it works on newer ones, probably through the transitive include somewhere. Additional testing: - [x] Linux x86_64 fastdebug `tools/jpackage` tests - [x] Linux x86_64 release `tools/jpackage` tests ------------- Commit messages: - Sort - Fix Changes: https://git.openjdk.java.net/jdk18/pull/74/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=74&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279370 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk18/pull/74.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/74/head:pull/74 PR: https://git.openjdk.java.net/jdk18/pull/74 From aph-open at littlepinkcloud.com Mon Jan 3 11:57:27 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 3 Jan 2022 11:57:27 +0000 Subject: a quick question about String In-Reply-To: <3c5244a8-5656-f24b-e4fc-e8d0fa188b2e@bell-sw.com> References: <8C66BC3F-0F0C-465B-9E60-DC10A5AC2984@cbfiddle.com> <3c5244a8-5656-f24b-e4fc-e8d0fa188b2e@bell-sw.com> Message-ID: <6ae4bec4-523b-fa57-1c20-d30b2c625b42@littlepinkcloud.com> On 12/30/21 16:12, Alexander Scherbatiy wrote: > Would it be useful to have some kind of an immutable array in Java language > which works in the same way as ordinary array except it is not to > possible to change > its values after creation? Yes. https://openjdk.java.net/jeps/8261007 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jbhateja at openjdk.java.net Mon Jan 3 12:31:50 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 3 Jan 2022 12:31:50 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v2] In-Reply-To: References: Message-ID: > 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 Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8273322 - 8273322: Enhance macro logic optimization for masked logic operations. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6893/files - new: https://git.openjdk.java.net/jdk/pull/6893/files/b14079e9..f8120acb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=00-01 Stats: 6814 lines in 274 files changed: 5024 ins; 944 del; 846 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 From hschreiber at openjdk.java.net Mon Jan 3 16:01:18 2022 From: hschreiber at openjdk.java.net (Hendrik Schreiber) Date: Mon, 3 Jan 2022 16:01:18 GMT Subject: Integrated: 8276700: Improve java.lang.ref.Cleaner javadocs In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 08:03:34 GMT, Hendrik Schreiber wrote: > 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). This pull request has now been integrated. Changeset: c295e71b Author: Hendrik Schreiber Committer: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/c295e71b49db20ab398ae1e8ba504d8ebff5fb77 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8276700: Improve java.lang.ref.Cleaner javadocs Reviewed-by: rriggs, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/6076 From naoto at openjdk.java.net Mon Jan 3 19:37:03 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 3 Jan 2022 19:37:03 GMT Subject: RFR: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java [v2] In-Reply-To: References: Message-ID: <8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com> > 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 Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into JDK-8278434 - Copyright year update - Added a microbenchmark for zone strings - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6790/files - new: https://git.openjdk.java.net/jdk/pull/6790/files/f14f5450..5f38bd13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6790&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6790&range=00-01 Stats: 20434 lines in 643 files changed: 14380 ins; 3767 del; 2287 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 From duke at openjdk.java.net Mon Jan 3 19:59:18 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 3 Jan 2022 19:59:18 GMT Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5] In-Reply-To: References: Message-ID: <1Eo7MLycvyX-hlNr1RZITE8Dz-xMHGlZAHap7_LRyAw=.c820ea59-acbe-4216-b6cd-9741d3113a56@github.com> On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing BufferedInputStream Maybe we need to include into this patch the benchmark referenced to in the body of the ticket? ------------- PR: https://git.openjdk.java.net/jdk/pull/6935 From vdyakov at openjdk.java.net Mon Jan 3 21:23:23 2022 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Mon, 3 Jan 2022 21:23:23 GMT Subject: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 In-Reply-To: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> References: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Message-ID: On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote: > Seems like a missing include. C++ docs say `offsetof` is from ``, adding that include explicitly fixes the build. Seems to only happen with older GCCs, but it seems to be a happy accident it works on newer ones, probably through the transitive include somewhere. > > Additional testing: > - [x] Linux x86_64 fastdebug `tools/jpackage` tests > - [x] Linux x86_64 release `tools/jpackage` tests it requires @alexeysemenyukoracle review (owner of JDK-8274856 changeset) ------------- PR: https://git.openjdk.java.net/jdk18/pull/74 From almatvee at openjdk.java.net Mon Jan 3 23:24:22 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 3 Jan 2022 23:24:22 GMT Subject: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 In-Reply-To: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> References: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Message-ID: On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote: > Seems like a missing include. C++ docs say `offsetof` is from ``, adding that include explicitly fixes the build. Seems to only happen with older GCCs, but it seems to be a happy accident it works on newer ones, probably through the transitive include somewhere. > > Additional testing: > - [x] Linux x86_64 fastdebug `tools/jpackage` tests > - [x] Linux x86_64 release `tools/jpackage` tests Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/74 From joehw at openjdk.java.net Mon Jan 3 23:48:19 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 3 Jan 2022 23:48:19 GMT Subject: RFR: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java [v2] In-Reply-To: <8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com> References: <8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com> Message-ID: On Mon, 3 Jan 2022 19:37:03 GMT, Naoto Sato wrote: >> 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 > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8278434 > - Copyright year update > - Added a microbenchmark for zone strings > - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java Marked as reviewed by joehw (Reviewer). It?s nice to see you?ve got most of the performance back. Hope looping through Zone strings isn't really necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/6790 From naoto at openjdk.java.net Tue Jan 4 00:00:15 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 4 Jan 2022 00:00:15 GMT Subject: RFR: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java [v2] In-Reply-To: References: <8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com> Message-ID: On Mon, 3 Jan 2022 23:45:16 GMT, Joe Wang wrote: > Hope looping through Zone strings isn't really necessary. Thanks, Joe. IMHO, `DateFormatSymbols.getZoneStrings()` is badly designed. It just simply exposes the names in the underlying ResourceBundle, and I cannot think of any use cases for this method, rather than using `ZoneId` or `TimeZone`'s display names retrieval methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/6790 From kvn at openjdk.java.net Tue Jan 4 02:29:17 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 4 Jan 2022 02:29:17 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v2] In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 12:31:50 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8273322 > - 8273322: Enhance macro logic optimization for masked logic operations. I think whole "Bitwise operation packing optimization" code should be moved out from `compile.cpp`. May be to `vectornode.cpp where `MacroLogicVNode` code is located. Copyright year should be updated to 2022 in all changed files. src/hotspot/cpu/x86/x86.ad line 1900: > 1898: > 1899: case Op_MacroLogicV: > 1900: if(bt != T_INT && bt != T_LONG) { Missing `VM_Version::supports_evex()` check? ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6893 From naoto at openjdk.java.net Tue Jan 4 02:52:22 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 4 Jan 2022 02:52:22 GMT Subject: Integrated: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 00:27:25 GMT, Naoto Sato wrote: > 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 This pull request has now been integrated. Changeset: 8dc4437d Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/8dc4437d002db5d025b47f48e7420e3bae55bdec Stats: 73 lines in 3 files changed: 59 ins; 7 del; 7 mod 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/6790 From mcimadamore at openjdk.java.net Tue Jan 4 11:39:08 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 Jan 2022 11:39:08 GMT Subject: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced correctly [v2] In-Reply-To: References: Message-ID: <2IS_pwdOIbjzmlgcLlj5FjVcfpthKqpnCRxmoAVJxlg=.b3d58dcc-c006-45ec-8e66-a432d4e6cf2f@github.com> > 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 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into heap-align - Initial push ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/37/files - new: https://git.openjdk.java.net/jdk18/pull/37/files/40a3acc3..3a860afa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=37&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=37&range=00-01 Stats: 2046 lines in 116 files changed: 1430 ins; 125 del; 491 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 From jbhateja at openjdk.java.net Tue Jan 4 15:04:22 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 4 Jan 2022 15:04:22 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v2] In-Reply-To: References: Message-ID: <4VSvjMRoSQkyMfFJz9b6IL_2rk8Zr-lm3hkvVBGaKCE=.2501e4f7-5248-46cc-a8a5-6ca4eccc7fb3@github.com> On Tue, 4 Jan 2022 02:21:35 GMT, Vladimir Kozlov wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8273322 >> - 8273322: Enhance macro logic optimization for masked logic operations. > > src/hotspot/cpu/x86/x86.ad line 1900: > >> 1898: >> 1899: case Op_MacroLogicV: >> 1900: if(bt != T_INT && bt != T_LONG) { > > Missing `VM_Version::supports_evex()` check? Hi @vnkozlov, we already have that check (UseAVX < 3) in match_rule_supported routine which gets called from this function. ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From jbhateja at openjdk.java.net Tue Jan 4 15:11:47 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 4 Jan 2022 15:11:47 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v3] In-Reply-To: References: Message-ID: > 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 Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8273322: Updating copywrite header. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6893/files - new: https://git.openjdk.java.net/jdk/pull/6893/files/f8120acb..d18f504f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=01-02 Stats: 12 lines in 12 files changed: 0 ins; 0 del; 12 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 From jvernee at openjdk.java.net Tue Jan 4 15:26:11 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 4 Jan 2022 15:26:11 GMT Subject: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced correctly [v2] In-Reply-To: <2IS_pwdOIbjzmlgcLlj5FjVcfpthKqpnCRxmoAVJxlg=.b3d58dcc-c006-45ec-8e66-a432d4e6cf2f@github.com> References: <2IS_pwdOIbjzmlgcLlj5FjVcfpthKqpnCRxmoAVJxlg=.b3d58dcc-c006-45ec-8e66-a432d4e6cf2f@github.com> Message-ID: On Tue, 4 Jan 2022 11:39:08 GMT, Maurizio Cimadamore wrote: >> 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 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into heap-align > - Initial push Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/37 From shade at openjdk.java.net Tue Jan 4 16:53:25 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 4 Jan 2022 16:53:25 GMT Subject: RFR: 8279453: Disable tools/jar/ReproducibleJar.java on 32-bit platforms Message-ID: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> The real problem is Y2038 ([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does not look solvable at this time. So for test cleanliness, we might just disable this test on 32-bit platforms. Additional testing: - [x] Linux x86_64 fastdebug, affected test still passes - [x] Linux x86_32 fastdebug, affected test is now skipped ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/6957/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6957&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279453 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6957/head:pull/6957 PR: https://git.openjdk.java.net/jdk/pull/6957 From alanb at openjdk.java.net Tue Jan 4 18:41:14 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 Jan 2022 18:41:14 GMT Subject: RFR: 8279453: Disable tools/jar/ReproducibleJar.java on 32-bit platforms In-Reply-To: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> References: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> Message-ID: On Tue, 4 Jan 2022 16:46:09 GMT, Aleksey Shipilev wrote: > The real problem is Y2038 ([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does not look solvable at this time. So for test cleanliness, we might just disable this test on 32-bit platforms. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test is now skipped Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6957 From kvn at openjdk.java.net Tue Jan 4 21:03:15 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 4 Jan 2022 21:03:15 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v2] In-Reply-To: <4VSvjMRoSQkyMfFJz9b6IL_2rk8Zr-lm3hkvVBGaKCE=.2501e4f7-5248-46cc-a8a5-6ca4eccc7fb3@github.com> References: <4VSvjMRoSQkyMfFJz9b6IL_2rk8Zr-lm3hkvVBGaKCE=.2501e4f7-5248-46cc-a8a5-6ca4eccc7fb3@github.com> Message-ID: On Tue, 4 Jan 2022 15:01:22 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/x86.ad line 1900: >> >>> 1898: >>> 1899: case Op_MacroLogicV: >>> 1900: if(bt != T_INT && bt != T_LONG) { >> >> Missing `VM_Version::supports_evex()` check? > > Hi @vnkozlov, we already have that check (UseAVX < 3) in match_rule_supported routine which gets called from this function. Good. ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From kvn at openjdk.java.net Tue Jan 4 21:09:10 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 4 Jan 2022 21:09:10 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v3] In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 15:11:47 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273322: Updating copywrite header. Let me test it before approval. You need second review. And file RFE to move vector code from `compile.cpp`. Let do it separately from these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From kvn at openjdk.java.net Wed Jan 5 00:39:17 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 5 Jan 2022 00:39:17 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v3] In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 15:11:47 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273322: Updating copywrite header. `compiler/vectorapi/TestMaskedMacroLogicVector.java` test failed on Aarch64 machines: Unrecognized VM option 'UseAVX=3' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. java.lang.RuntimeException: TestFramework flag VM exited with 1 at compiler.lib.ir_framework.driver.FlagVMProcess.checkFlagVMExitCode(FlagVMProcess.java:135) at compiler.lib.ir_framework.driver.FlagVMProcess.start(FlagVMProcess.java:121) at compiler.lib.ir_framework.driver.FlagVMProcess.(FlagVMProcess.java:63) at compiler.lib.ir_framework.TestFramework.start(TestFramework.java:658) at compiler.lib.ir_framework.TestFramework.start(TestFramework.java:322) at compiler.lib.ir_framework.TestFramework.runWithFlags(TestFramework.java:230) at compiler.vectorapi.TestMaskedMacroLogicVector.main(TestMaskedMacroLogicVector.java:837) ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From bpb at openjdk.java.net Wed Jan 5 00:41:16 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 Jan 2022 00:41:16 GMT Subject: RFR: 8279453: Disable tools/jar/ReproducibleJar.java on 32-bit platforms In-Reply-To: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> References: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> Message-ID: On Tue, 4 Jan 2022 16:46:09 GMT, Aleksey Shipilev wrote: > The real problem is Y2038 ([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does not look solvable at this time. So for test cleanliness, we might just disable this test on 32-bit platforms. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test is now skipped Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6957 From sviswanathan at openjdk.java.net Wed Jan 5 01:11:15 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 5 Jan 2022 01:11:15 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v3] In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 15:11:47 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273322: Updating copywrite header. src/hotspot/cpu/x86/assembler_x86.cpp line 9740: > 9738: emit_int8(0x25); > 9739: emit_int8((unsigned char)(0xC0 | encode)); > 9740: emit_int8(imm8); Please use emit_int24() here. src/hotspot/cpu/x86/assembler_x86.cpp line 9773: > 9771: emit_int8(0x25); > 9772: emit_int8((unsigned char)(0xC0 | encode)); > 9773: emit_int8(imm8); Please use emit_int24() here. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4164: > 4162: } > 4163: } > 4164: "merge" argument not used in method body. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4174: > 4172: } > 4173: } > 4174: "merge" argument is not used in the method body. src/hotspot/cpu/x86/x86.ad line 9590: > 9588: format %{ "vternlog_masked $dst,$src2,$src3,$func,$mask\t! vternlog masked operation" %} > 9589: ins_encode %{ > 9590: int vector_len = vector_length_encoding(this); It would be good to name this as vlen_enc instead of vector_len. ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From shade at openjdk.java.net Wed Jan 5 07:32:30 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 5 Jan 2022 07:32:30 GMT Subject: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 In-Reply-To: References: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Message-ID: On Mon, 3 Jan 2022 21:18:12 GMT, Victor Dyakov wrote: > it requires @alexeysemenyukoracle review (owner of JDK-8274856 changeset) Well, this looks trivial to me. Should we really wait @alexeysemenyukoracle, who, I assume, might be on NY holiday break? ------------- PR: https://git.openjdk.java.net/jdk18/pull/74 From ioi.lam at oracle.com Wed Jan 5 07:38:36 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 4 Jan 2022 23:38:36 -0800 Subject: [Ping] RFR: 8275731: CDS archived enums objects are recreated at runtime In-Reply-To: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: <211a7559-e8e8-29a8-0df0-6fd94fbe1c2d@oracle.com> Still looking for reviewers .... Thanks - Ioi On 12/1/21 1:02 PM, Ioi Lam wrote: > **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { > public static final SUNDAY = new Day("SUNDAY"); > public static final MONDAY = new Day("MONDAY"); ... > } > > > With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) > > **Fix:** > > During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. > > This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. > > **Verification:** > > To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt > > **Testing:** > > Passed Oracle CI tiers 1-4. WIll run tier 5 as well. > > ------------- > > Commit messages: > - 8275731: CDS archived enums objects are recreated at runtime > > Changes: https://git.openjdk.java.net/jdk/pull/6653/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8275731 > Stats: 829 lines in 16 files changed: 787 ins; 2 del; 40 mod > Patch: https://git.openjdk.java.net/jdk/pull/6653.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653 > > PR: https://git.openjdk.java.net/jdk/pull/6653 From jbhateja at openjdk.java.net Wed Jan 5 08:59:00 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 5 Jan 2022 08:59:00 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v4] In-Reply-To: References: Message-ID: > 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 Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8273322: Review comments resolution. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6893/files - new: https://git.openjdk.java.net/jdk/pull/6893/files/d18f504f..f101fff7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=02-03 Stats: 15 lines in 4 files changed: 1 ins; 4 del; 10 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 From jbhateja at openjdk.java.net Wed Jan 5 08:59:02 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 5 Jan 2022 08:59:02 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v2] In-Reply-To: References: Message-ID: <7OnV1ECl4Tu-nnR-of-IpWCOyLPMLd1JKTmwfkkcbCg=.dddab71f-36b3-49a8-a456-be3601f15096@github.com> On Tue, 4 Jan 2022 02:25:36 GMT, Vladimir Kozlov wrote: > I think whole "Bitwise operation packing optimization" code should be moved out from `compile.cpp`. May be to `vectornode.cpp where `MacroLogicVNode` code is located. > Hi @vnkozlov , Yes we can also extended AndV/OrV/XorV/AndVMask/OrVMask/XorVMask idealizations to perform macro logic folding, current changes keeps the implementation clean and limited to one optimization stage. > Copyright year should be updated to 2022 in all changed files. ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From jbhateja at openjdk.java.net Wed Jan 5 08:59:05 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 5 Jan 2022 08:59:05 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v3] In-Reply-To: References: Message-ID: <6C6sIfXUSofDmnHWK-PllMJ9PwlihIunGNQYwUBg234=.0634541c-b98f-4d0f-aae5-9e4e8be038bd@github.com> On Tue, 4 Jan 2022 15:11:47 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273322: Updating copywrite header. Hi @sviswa7 , @vnkozlov , your comments have been addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From myano at openjdk.java.net Wed Jan 5 10:13:13 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 5 Jan 2022 10:13:13 GMT Subject: RFR: 8276694: Pattern trailing unescaped backslash causes internal error In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 09:57:14 GMT, Masanori Yano wrote: > Could you please review the 8276694 bug fixes? > > A message specific for this exception should be printed instead of an internal error. This fix adds a new check to output an appropriate exception message when the regular expression ends with an unescaped backslash. This fix also checks the position of the cursor to rule out other syntax errors at the middle position of the regular expression. Could someone please review this pull request? ------------- PR: https://git.openjdk.java.net/jdk/pull/6891 From myano at openjdk.java.net Wed Jan 5 10:20:17 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 5 Jan 2022 10:20:17 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2] In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 16:42:50 GMT, Alan Bateman wrote: >> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > src/java.base/share/classes/java/util/zip/ZipFile.java line 1501: > >> 1499: // read in the CEN and END >> 1500: if (end.cenlen + ENDHDR >= Integer.MAX_VALUE) { >> 1501: zerror("invalid END header (too large central directory size)"); > > This check looks correct. It might be a bit clearer to say that "central directory size too large" rather than "too large central directory size". > > The bug report says that JDK 8 and the native zip handle these zip files, were you able to check that? @AlanBateman Could you please review the above comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From mcimadamore at openjdk.java.net Wed Jan 5 10:51:32 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 10:51:32 GMT Subject: [jdk18] Integrated: 8278897: Alignment of heap segments is not enforced correctly In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 12:31:01 GMT, Maurizio Cimadamore wrote: > 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 This pull request has now been integrated. Changeset: 9d43d25d Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk18/commit/9d43d25da8bcfff425a795dcc230914a384a5c82 Stats: 600 lines in 20 files changed: 566 ins; 0 del; 34 mod 8278897: Alignment of heap segments is not enforced correctly Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/jdk18/pull/37 From shade at openjdk.java.net Wed Jan 5 16:22:16 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 5 Jan 2022 16:22:16 GMT Subject: RFR: 8279453: Disable tools/jar/ReproducibleJar.java on 32-bit platforms In-Reply-To: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> References: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> Message-ID: <_PewBkf3klL7JVnKWtHhwcTv9o5CZFkRW_OaSQbLGhU=.65e04da3-c63d-4b8f-8523-a926443ce51c@github.com> On Tue, 4 Jan 2022 16:46:09 GMT, Aleksey Shipilev wrote: > The real problem is Y2038 ([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does not look solvable at this time. So for test cleanliness, we might just disable this test on 32-bit platforms. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test is now skipped Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/6957 From shade at openjdk.java.net Wed Jan 5 16:22:16 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 5 Jan 2022 16:22:16 GMT Subject: Integrated: 8279453: Disable tools/jar/ReproducibleJar.java on 32-bit platforms In-Reply-To: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> References: <599LltEWJN5FNH7q-PY0KiToHp3CPLsWhx9dDnwmYxY=.cf12978c-7996-42c2-9b39-718eed45c0cb@github.com> Message-ID: On Tue, 4 Jan 2022 16:46:09 GMT, Aleksey Shipilev wrote: > The real problem is Y2038 ([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does not look solvable at this time. So for test cleanliness, we might just disable this test on 32-bit platforms. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test is now skipped This pull request has now been integrated. Changeset: a741b927 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a741b927a3cdc8e339ae557c77886ea850aa06b6 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8279453: Disable tools/jar/ReproducibleJar.java on 32-bit platforms Reviewed-by: alanb, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/6957 From mcimadamore at openjdk.java.net Wed Jan 5 17:07:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 17:07:34 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution Message-ID: This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: Benchmark Mode Cnt Score Error Units LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: Benchmark Mode Cnt Score Error Units LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk18/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279527 Stats: 108 lines in 8 files changed: 41 ins; 49 del; 18 mod Patch: https://git.openjdk.java.net/jdk18/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Wed Jan 5 17:07:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 17:07:34 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 16:59:30 GMT, Maurizio Cimadamore wrote: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 367: > 365: > 366: void checkValidState() { > 367: scope.checkValidStateSlow(); Not to be confused with `ResourceScope::checkValidState` - this method is only really used by other non-performance critical code around `AbstractMemorySegmentImpl`. ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From psandoz at openjdk.java.net Wed Jan 5 17:27:11 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 5 Jan 2022 17:27:11 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 16:59:30 GMT, Maurizio Cimadamore wrote: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 190: > 188: @ForceInline > 189: public final void checkValidState() { > 190: if (owner != null && owner != Thread.currentThread()) { For consistency we could change code `checkValidStateSlow` to refer directly to `owner`. It would be satisfying, but I don't know if it's possible, to compose `checkValidStateSlow` from `checkValidState` e.g. public final checkValidStateSlow() { checkValidState(); if (!isAlive() { ... } } ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From izzeldeen03 at gmail.com Wed Jan 5 17:28:20 2022 From: izzeldeen03 at gmail.com (Izz Rainy) Date: Wed, 5 Jan 2022 17:28:20 +0000 Subject: Idea: Collection Literals Message-ID: Hello! Hopefully this is the right place for this suggestion - I originally posted this on the discuss list, but was told this list would be more appropriate. Recently, I've read some of the discussion linked in JEP 269 (Convenience Factory Methods for Collections), including why Collection Literals were shelved when brought up in Project Coin and Lambda. I believe that things may be different enough now (with dynamic constants possible, local variable inference and lambdas present, value types closer to completion, and Project Amber bringing "smaller" features under consideration) to bring them up yet again. I've tried writing an informal proposal for them that tries to answer the main questions brought up in those original discussions: https://gist.github.com/l-Luna/08b6574d0c840de93634cf8d1e43c494 I understand that it's still unlikely to be added in the near future, but thought it wouldn't hurt to bring up again. From dcubed at openjdk.java.net Wed Jan 5 17:34:33 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 5 Jan 2022 17:34:33 GMT Subject: [jdk18] RFR: 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 Message-ID: A couple of trivial ProblemListings: JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java ------------- Commit messages: - 8279532: ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java - 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk18/pull/83/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=83&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279529 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk18/pull/83.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/83/head:pull/83 PR: https://git.openjdk.java.net/jdk18/pull/83 From jnimeh at openjdk.java.net Wed Jan 5 17:42:22 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Wed, 5 Jan 2022 17:42:22 GMT Subject: [jdk18] RFR: 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:22:54 GMT, Daniel D. Daugherty wrote: > A couple of trivial ProblemListings: > > JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 > JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java Looks good to me. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/83 From mcimadamore at openjdk.java.net Wed Jan 5 18:01:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 18:01:10 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:23:40 GMT, Paul Sandoz wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 190: > >> 188: @ForceInline >> 189: public final void checkValidState() { >> 190: if (owner != null && owner != Thread.currentThread()) { > > For consistency we could change code `checkValidStateSlow` to refer directly to `owner`. > > It would be satisfying, but I don't know if it's possible, to compose `checkValidStateSlow` from `checkValidState` e.g. > > public final checkValidStateSlow() { > checkValidState(); > if (!isAlive() { ... } > } I'll change use of `owner`. It's not really possible to write checkValidStateSlow in terms of checkValidState, because the latter does a plain read of the state, whereas the former does a volatile read. Reusing one from the other would result in two reads (a plain and a volatile). ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Wed Jan 5 18:08:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 18:08:01 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: Message-ID: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Use owner field instead of accessor in checkValidStateSlow ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/82/files - new: https://git.openjdk.java.net/jdk18/pull/82/files/c6082953..04a1e9f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk18/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk18/pull/82 From kvn at openjdk.java.net Wed Jan 5 18:20:12 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 5 Jan 2022 18:20:12 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v4] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 08:59:00 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273322: Review comments resolution. Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6893 From psandoz at openjdk.java.net Wed Jan 5 18:28:22 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 5 Jan 2022 18:28:22 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:57:44 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 190: >> >>> 188: @ForceInline >>> 189: public final void checkValidState() { >>> 190: if (owner != null && owner != Thread.currentThread()) { >> >> For consistency we could change code `checkValidStateSlow` to refer directly to `owner`. >> >> It would be satisfying, but I don't know if it's possible, to compose `checkValidStateSlow` from `checkValidState` e.g. >> >> public final checkValidStateSlow() { >> checkValidState(); >> if (!isAlive() { ... } >> } > > I'll change use of `owner`. It's not really possible to write checkValidStateSlow in terms of checkValidState, because the latter does a plain read of the state, whereas the former does a volatile read. Reusing one from the other would result in two reads (a plain and a volatile). Ok. My thought was that since this is slow two reads do not matter, but i did not reason fully about the concurrent implications (if the fast alive check returns false, the slow alive check can still return true so that seems good, if the fast check returns true i was presume the slow alive check would also be true, given the way state changes monotonically?) ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From psandoz at openjdk.java.net Wed Jan 5 18:49:11 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 5 Jan 2022 18:49:11 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> References: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> Message-ID: On Wed, 5 Jan 2022 18:08:01 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Use owner field instead of accessor in checkValidStateSlow Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Wed Jan 5 18:54:13 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 18:54:13 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 18:24:39 GMT, Paul Sandoz wrote: >> I'll change use of `owner`. It's not really possible to write checkValidStateSlow in terms of checkValidState, because the latter does a plain read of the state, whereas the former does a volatile read. Reusing one from the other would result in two reads (a plain and a volatile). > > Ok. My thought was that since this is slow two reads do not matter, but i did not reason fully about the concurrent implications (if the fast alive check returns false, the slow alive check can still return true so that seems good, if the fast check returns true i was presume the slow alive check would also be true, given the way state changes monotonically?) If we're ok with a redundant plain read, then I don't think there are issues. You just do two reads, and the latter (the volatile one) is the one that counts. I don't think we can rely much on dependencies between what the plain read and what the volatile read will see. The state is updated in both direction (for shared segments) e.g. we can go from ALIVE to CLOSING then back to ALIVE. Or we could go from ALIVE to CLOSING to CLOSE. That said, I guess my main reservation for writing one routine on top of the other is that we really want checkValidState to be only used in critical hot paths. It has a non-volatile semantics and an exception handling which only really makes sense when combined with ScopedMemoryAccess - for this reason, using it as an internal building primitive didn't seem to me as a great idea. ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From naoto at openjdk.java.net Wed Jan 5 22:51:48 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 5 Jan 2022 22:51:48 GMT Subject: RFR: 8268081: Support for Unicode 14 Message-ID: Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. ------------- Commit messages: - Amend unicode.md and icu.md files - Minor fixup - Merge branch 'master' into unicode - Copyright year to 2022 - ICU4J 70.1 - 18 -> 19 - Merge branch 'master' into unicode - Unicode 14.0.0 (final) - UCD ver. 14.0 (beta) / Unicode Text Segmentation rev. 38 (draft) - ICU4J 69.1 Changes: https://git.openjdk.java.net/jdk/pull/6974/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6974&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268081 Stats: 3443 lines in 41 files changed: 2353 ins; 101 del; 989 mod Patch: https://git.openjdk.java.net/jdk/pull/6974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6974/head:pull/6974 PR: https://git.openjdk.java.net/jdk/pull/6974 From jwilhelm at openjdk.java.net Thu Jan 6 00:52:49 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 6 Jan 2022 00:52:49 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18 - 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 - 8278612: [macos] test/jdk/java/awt/dnd/RemoveDropTargetCrashTest crashes with VoiceOver on macOS - 8279525: ProblemList java/awt/GraphicsDevice/CheckDisplayModes.java on macosx-aarch64 - 8278897: Alignment of heap segments is not enforced correctly - 8279222: Incorrect legacyMap.get in java.security.Provider after JDK-8276660 - 8278948: compiler/vectorapi/reshape/TestVectorCastAVX1.java crashes in assembler The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=6975&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=6975&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/6975/files Stats: 750 lines in 28 files changed: 687 ins; 8 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/6975.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6975/head:pull/6975 PR: https://git.openjdk.java.net/jdk/pull/6975 From jwilhelm at openjdk.java.net Thu Jan 6 01:30:25 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 6 Jan 2022 01:30:25 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 00:42:14 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 844dfb3a Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/844dfb3ab6a1d8b68ccdcc73726ee0f73cfcb3c8 Stats: 750 lines in 28 files changed: 687 ins; 8 del; 55 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/6975 From joehw at openjdk.java.net Thu Jan 6 01:49:12 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 6 Jan 2022 01:49:12 GMT Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6974 From joehw at openjdk.java.net Thu Jan 6 01:52:12 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 6 Jan 2022 01:52:12 GMT Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. I like how they changed dizzy face to face with crossed-out eyes. Pistol to water pistol, that's even better, just to avoid any confusion ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6974 From iris at openjdk.java.net Thu Jan 6 05:24:14 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 6 Jan 2022 05:24:14 GMT Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6974 From alanb at openjdk.java.net Thu Jan 6 09:37:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 Jan 2022 09:37:11 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2] In-Reply-To: References: Message-ID: <_ZJQ-BdUa0YfdRlNEA0oYa_PpflCqGy2n7AIPn9U7eg=.079f136a-3323-4b61-bad8-809e61ab5ab5@github.com> On Thu, 23 Dec 2021 16:42:50 GMT, Alan Bateman wrote: >> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > src/java.base/share/classes/java/util/zip/ZipFile.java line 1501: > >> 1499: // read in the CEN and END >> 1500: if (end.cenlen + ENDHDR >= Integer.MAX_VALUE) { >> 1501: zerror("invalid END header (too large central directory size)"); > > This check looks correct. It might be a bit clearer to say that "central directory size too large" rather than "too large central directory size". > > The bug report says that JDK 8 and the native zip handle these zip files, were you able to check that? > @AlanBateman Could you please review the above comments. Thanks for changing the message, the update to ZipFile looks good to me although I'm still surprised that the native tools support a CEN larger than 2Gb. I'm slow to add myself as a Reviewer because I'm concerned about the test. I ran it on a couple of systems and it take several minutes to create the ZIP file. This test may potentially run concurrently with other I/O bound tests and I'm concerned about intermittent timeouts. @LanceAndersen - do you have any opinions on this? ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From lancea at openjdk.java.net Thu Jan 6 11:38:14 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 6 Jan 2022 11:38:14 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2] In-Reply-To: <_ZJQ-BdUa0YfdRlNEA0oYa_PpflCqGy2n7AIPn9U7eg=.079f136a-3323-4b61-bad8-809e61ab5ab5@github.com> References: <_ZJQ-BdUa0YfdRlNEA0oYa_PpflCqGy2n7AIPn9U7eg=.079f136a-3323-4b61-bad8-809e61ab5ab5@github.com> Message-ID: <1Fx3GqWhtX90543OLkzqw7fd8G9_m7Pm_mQJ_HoBRqM=.bfa67c12-ab8d-4a7d-8d43-bdc1ca7ce4ae@github.com> On Thu, 6 Jan 2022 09:34:24 GMT, Alan Bateman wrote: > > @AlanBateman Could you please review the above comments. > > Thanks for changing the message, the update to ZipFile looks good to me although I'm still surprised that the native tools support a CEN larger than 2Gb. > > I'm slow to add myself as a Reviewer because I'm concerned about the test. I ran it on a couple of systems and it take several minutes to create the ZIP file. This test may potentially run concurrently with other I/O bound tests and I'm concerned about intermittent timeouts. @LanceAndersen - do you have any opinions on this? I haven't had a chance to look at this yet but will kick off some runs to see what the runtime via mach5. We might have issues with some of the test machines. > > @AlanBateman Could you please review the above comments. > > Thanks for changing the message, the update to ZipFile looks good to me although I'm still surprised that the native tools support a CEN larger than 2Gb. > > I'm slow to add myself as a Reviewer because I'm concerned about the test. I ran it on a couple of systems and it take several minutes to create the ZIP file. This test may potentially run concurrently with other I/O bound tests and I'm concerned about intermittent timeouts. @LanceAndersen - do you have any opinions on this? I have not had a chance to look at this yet in detail but in the meantime I will kick off a mach5 run to see what the runtime is on our test machines today A couple quick passing comments. The test should delete the file after the run/error given the potential size. Was there a reason you did not the test is not TestNG based? ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From jvernee at openjdk.java.net Thu Jan 6 12:19:32 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 6 Jan 2022 12:19:32 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> References: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> Message-ID: On Wed, 5 Jan 2022 18:08:01 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Use owner field instead of accessor in checkValidStateSlow Marked as reviewed by jvernee (Reviewer). src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 45: > 43: private int lockCount = 0; > 44: private int asyncReleaseCount = 0; > 45: private final Thread owner; Is this `owner` field still needed now that the super class also has it? ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Thu Jan 6 12:19:33 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 6 Jan 2022 12:19:33 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> Message-ID: On Thu, 6 Jan 2022 12:11:29 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use owner field instead of accessor in checkValidStateSlow > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 45: > >> 43: private int lockCount = 0; >> 44: private int asyncReleaseCount = 0; >> 45: private final Thread owner; > > Is this `owner` field still needed now that the super class also has it? Forgot to remove - well spotted ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Thu Jan 6 12:36:52 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 6 Jan 2022 12:36:52 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v3] In-Reply-To: References: Message-ID: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Drop redundant owner field * Reuse `state` variable for confined lock count ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/82/files - new: https://git.openjdk.java.net/jdk18/pull/82/files/04a1e9f2..e0bbc8f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk18/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk18/pull/82 From jlaskey at openjdk.java.net Thu Jan 6 13:17:19 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 6 Jan 2022 13:17:19 GMT Subject: RFR: 8276694: Pattern trailing unescaped backslash causes internal error In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 09:57:14 GMT, Masanori Yano wrote: > Could you please review the 8276694 bug fixes? > > A message specific for this exception should be printed instead of an internal error. This fix adds a new check to output an appropriate exception message when the regular expression ends with an unescaped backslash. This fix also checks the position of the cursor to rule out other syntax errors at the middle position of the regular expression. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6891 From alanb at openjdk.java.net Thu Jan 6 13:23:09 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 Jan 2022 13:23:09 GMT Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5] In-Reply-To: References: Message-ID: On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing BufferedInputStream I think you'll need to look at the interaction with mark/reset. I don't think you can bypass the buffering when there is a mark set. ------------- PR: https://git.openjdk.java.net/jdk/pull/6935 From duke at openjdk.java.net Thu Jan 6 14:30:12 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 6 Jan 2022 14:30:12 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code In-Reply-To: References: Message-ID: <0k-rvO75HmzTg1ZBv9aK4_XOBZitJDM6m_ct03Wpjwg=.cb42cb41-3b7d-44a1-a2ff-2f6b36d78078@github.com> On Thu, 9 Dec 2021 11:50:50 GMT, ?????? ??????? wrote: > `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. Let's wait ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From redestad at openjdk.java.net Thu Jan 6 16:48:20 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 6 Jan 2022 16:48:20 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 11:50:50 GMT, ?????? ??????? wrote: > `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. Changes requested by redestad (Reviewer). src/java.base/share/classes/java/lang/reflect/Constructor.java line 374: > 372: sb.append('('); > 373: StringJoiner sj = new StringJoiner(","); > 374: for (Class parameterType : getSharedParameterTypes()) { Good. src/java.base/share/classes/java/lang/reflect/Executable.java line 313: > 311: // getParameterTypes(). > 312: if (!genericInfo) { > 313: return getSharedParameterTypes(); Since this returns the trusted array it delegates responsibility to the callers of `getAllGenericParameterTypes` to not mutate or further expose/leak the parameter type array. This needs to at least be called out in the method specification. The comment here needs to be updated, as well. Is the added fragility in this case worth the performance win? src/java.base/share/classes/java/lang/reflect/Executable.java line 317: > 315: final boolean realParamData = hasRealParameterData(); > 316: final Type[] genericParamTypes = getGenericParameterTypes(); > 317: final Type[] nonGenericParamTypes = getSharedParameterTypes(); (If removing these allocations is important, I note that `ConstructorRepository.getGenericParameterTypes()` lacks an equivalent to `getSharedParameterType` for trusted callers) Similarly here I'm not sure the win from avoiding the clone is worth delegating the additional responsibility. You could still do this here if you add `.clone()` after `nonGenericParamTypes` on L344 src/java.base/share/classes/java/lang/reflect/Method.java line 434: > 432: String toShortSignature() { > 433: StringJoiner sj = new StringJoiner(",", getName() + "(", ")"); > 434: for (Class parameterType : getSharedParameterTypes()) { Good. ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From sviswanathan at openjdk.java.net Thu Jan 6 17:44:21 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 6 Jan 2022 17:44:21 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v4] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 08:59:00 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273322: Review comments resolution. test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java line 26: > 24: /** > 25: * @test > 26: * @bug 8273322 Needs @key randomness as we use random number without a fixed seed here. Please see: https://openjdk.java.net/jtreg/faq.html#when-should-i-use-the-intermittent-or-randomness-keyword-in-a-test ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From lancea at openjdk.java.net Thu Jan 6 17:58:16 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 6 Jan 2022 17:58:16 GMT Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6974 From jbhateja at openjdk.java.net Thu Jan 6 18:29:55 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 6 Jan 2022 18:29:55 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v5] In-Reply-To: References: Message-ID: > 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 Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8273322: Adding missing randomness key. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6893/files - new: https://git.openjdk.java.net/jdk/pull/6893/files/f101fff7..2d196f71 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6893&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 From sviswanathan at openjdk.java.net Thu Jan 6 18:29:59 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 6 Jan 2022 18:29:59 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v5] In-Reply-To: References: Message-ID: <2iOckJMWdG_WG-xv9KooD_axsb7KPOv2kxE62St6uDs=.09e2ea86-e54b-4460-8bb5-d206ffabc7c5@github.com> On Thu, 6 Jan 2022 18:26:32 GMT, Jatin Bhateja wrote: >> 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 > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273322: Adding missing randomness key. Marked as reviewed by sviswanathan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From jbhateja at openjdk.java.net Thu Jan 6 18:30:04 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 6 Jan 2022 18:30:04 GMT Subject: RFR: 8273322: Enhance macro logic optimization for masked logic operations. [v4] In-Reply-To: References: Message-ID: <2quKnr47M9C9BLfvd84ObeNyOdA7mFzV2iLZ6-CQ8NQ=.d0c1acb7-de5f-4bea-962d-d6423f246256@github.com> On Thu, 6 Jan 2022 17:39:20 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273322: Review comments resolution. > > test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java line 26: > >> 24: /** >> 25: * @test >> 26: * @bug 8273322 > > Needs @key randomness as we use random number without a fixed seed here. > Please see: > https://openjdk.java.net/jtreg/faq.html#when-should-i-use-the-intermittent-or-randomness-keyword-in-a-test DONE ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From jbhateja at openjdk.java.net Thu Jan 6 18:44:28 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 6 Jan 2022 18:44:28 GMT Subject: Integrated: 8273322: Enhance macro logic optimization for masked logic operations. In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 13:33:01 GMT, Jatin Bhateja wrote: > 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 This pull request has now been integrated. Changeset: 8703f148 Author: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/8703f14808d7256d4b07e7ea8a232889bbca4894 Stats: 1419 lines in 12 files changed: 1368 ins; 6 del; 45 mod 8273322: Enhance macro logic optimization for masked logic operations. Reviewed-by: kvn, sviswanathan ------------- PR: https://git.openjdk.java.net/jdk/pull/6893 From duke at openjdk.java.net Fri Jan 7 05:16:19 2022 From: duke at openjdk.java.net (duke) Date: Fri, 7 Jan 2022 05:16:19 GMT Subject: Withdrawn: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for launching various applications in one JVM was used to reduce memory usage and each application was isolated from each other. > > This isolation was implemented via ThreadGroups where each application created its own thread group and all data for the application was stored in the context of its own group. > > Some parts of the JDK used ThreadGroups directly, others used special classes like sun.awt.AppContext. > > Such sandboxing became useless since the plugin and webstart are no longer supported and were removed in jdk11. > > Note that this is just a first step for the overall cleanup, here is my plan: > 1. Cleanup the usage of AppContext in the ?java.util.logging.LogManager" class in the java.base module. > 2. Cleanup the usage of TheadGroup in the JavaSound > 3. Cleanup the usage of TheadGroup in the JavaBeans > 4. Cleanup the usage of AppContext in the Swing > 5. Cleanup the usage of AppContext in the AWT > 6. Delete the AppContext class. > > The current PR is for the first step. So 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5326 From jvernee at openjdk.java.net Fri Jan 7 13:11:17 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 7 Jan 2022 13:11:17 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v3] In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 12:36:52 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Drop redundant owner field > * Reuse `state` variable for confined lock count Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Fri Jan 7 13:45:19 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 7 Jan 2022 13:45:19 GMT Subject: [jdk18] Integrated: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 16:59:30 GMT, Maurizio Cimadamore wrote: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. This pull request has now been integrated. Changeset: d65c6658 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk18/commit/d65c665839c0a564c422ef685f2673fac37315d7 Stats: 116 lines in 8 files changed: 40 ins; 52 del; 24 mod 8279527: Dereferencing segments backed by different scopes leads to pollution Reviewed-by: psandoz, jvernee ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From duke at openjdk.java.net Sat Jan 8 02:10:30 2022 From: duke at openjdk.java.net (duke) Date: Sat, 8 Jan 2022 02:10:30 GMT Subject: Withdrawn: 8277013: Allow creation of module graphs without defining modules to the VM In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 14:53:13 GMT, Ivan Ristovi? wrote: > 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6356 From lancea at openjdk.java.net Sat Jan 8 16:13:24 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 8 Jan 2022 16:13:24 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2] In-Reply-To: References: Message-ID: On Fri, 24 Dec 2021 11:07:04 GMT, Masanori Yano wrote: >> Could you please review the JDK-8272746 bug fixes? >> Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. >> It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. >> In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8272746: ZipFile can't open big file (NegativeArraySizeException) Thank you for your work here. Have you also run your test using Apache Commons? I have run this test over 2000 times via Mach5 on various hardware with some runs taking over 12 minutes for the test to complete. So unless you can refactor the test to be more efficient, we need to make the test a manual test as this is more of a corner case. Please see the additional comments below test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java line 28: > 26: * @summary ZipFile can't open big file (NegativeArraySizeException) > 27: * @requires (sun.arch.data.model == "64" & os.maxMemory > 8g) > 28: * @run main/othervm/timeout=3600 -Xmx8g TestTooManyEntries Please convert to a manual test and use TestNG for the test test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java line 58: > 56: if (System.currentTimeMillis() >= nextLog) { > 57: nextLog = 30_000 + System.currentTimeMillis(); > 58: System.out.printf("Processed %s%% directories (%s), file size is %sMb (%ss)%n", I would clarify the message to use "entries" vs "directories". as the issue deals with the size of the CEN overall not whether the actual entry is for a file or represents a directory. You could probably simplify the time check by just outputting every "n" entries written test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java line 70: > 68: ZipFile zip = new ZipFile(hugeZipFile); > 69: } catch (ZipException ze) { > 70: passed = true; you can use assertThrows here ------------- Changes requested by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6927 From duke at openjdk.java.net Mon Jan 10 09:42:32 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 10 Jan 2022 09:42:32 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 16:38:05 GMT, Claes Redestad wrote: >> `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. > > src/java.base/share/classes/java/lang/reflect/Executable.java line 313: > >> 311: // getParameterTypes(). >> 312: if (!genericInfo) { >> 313: return getSharedParameterTypes(); > > Since this returns the trusted array it delegates responsibility to the callers of `getAllGenericParameterTypes` to not mutate or further expose/leak the parameter type array. This needs to at least be called out in the method specification. The comment here needs to be updated, as well. Is the added fragility in this case worth the performance win? I agree about the spec and comment. I think we have nothing to worry about in this case as `Executable` is sealed and `getAllGenericParameterTypes()` is package-private, so it never gets out of JDK codebase. As of its current usage we only read from returned `Type[]`. Lot's of frameworks utilize reflection, so I think we should try to make it as fast as possible ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From duke at openjdk.java.net Mon Jan 10 09:57:29 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 10 Jan 2022 09:57:29 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 16:45:09 GMT, Claes Redestad wrote: >> `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. > > src/java.base/share/classes/java/lang/reflect/Executable.java line 317: > >> 315: final boolean realParamData = hasRealParameterData(); >> 316: final Type[] genericParamTypes = getGenericParameterTypes(); >> 317: final Type[] nonGenericParamTypes = getSharedParameterTypes(); > > (If removing these allocations is important, I note that `ConstructorRepository.getGenericParameterTypes()` lacks an equivalent to `getSharedParameterType` for trusted callers) > > Similarly here I'm not sure the win from avoiding the clone is worth delegating the additional responsibility. You could still do this here if you add `.clone()` after `nonGenericParamTypes` on L344 @cl4es Do you think it's worth creating a separate PR for `ConstructorRepository.getGenericParameterTypes()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From duke at openjdk.java.net Mon Jan 10 10:02:18 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 10 Jan 2022 10:02:18 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code [v2] In-Reply-To: References: Message-ID: > `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8278461: Revert Executable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6782/files - new: https://git.openjdk.java.net/jdk/pull/6782/files/bbf8bfaa..ee5fdb04 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6782&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6782&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6782.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6782/head:pull/6782 PR: https://git.openjdk.java.net/jdk/pull/6782 From duke at openjdk.java.net Mon Jan 10 10:02:20 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 10 Jan 2022 10:02:20 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 09:38:15 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/reflect/Executable.java line 313: >> >>> 311: // getParameterTypes(). >>> 312: if (!genericInfo) { >>> 313: return getSharedParameterTypes(); >> >> Since this returns the trusted array it delegates responsibility to the callers of `getAllGenericParameterTypes` to not mutate or further expose/leak the parameter type array. This needs to at least be called out in the method specification. The comment here needs to be updated, as well. Is the added fragility in this case worth the performance win? > > I agree about the spec and comment. I think we have nothing to worry about in this case as `Executable` is sealed and `getAllGenericParameterTypes()` is package-private, so it never gets out of JDK codebase. As of its current usage we only read from returned `Type[]`. Lot's of frameworks utilize reflection, so I think we should try to make it as fast as possible P.S. I think I'd better revert this ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From redestad at openjdk.java.net Mon Jan 10 10:28:29 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 10 Jan 2022 10:28:29 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 10:02:18 GMT, ?????? ??????? wrote: >> `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8278461: Revert Executable Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From redestad at openjdk.java.net Mon Jan 10 10:28:29 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 10 Jan 2022 10:28:29 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 09:53:56 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/reflect/Executable.java line 317: >> >>> 315: final boolean realParamData = hasRealParameterData(); >>> 316: final Type[] genericParamTypes = getGenericParameterTypes(); >>> 317: final Type[] nonGenericParamTypes = getSharedParameterTypes(); >> >> (If removing these allocations is important, I note that `ConstructorRepository.getGenericParameterTypes()` lacks an equivalent to `getSharedParameterType` for trusted callers) >> >> Similarly here I'm not sure the win from avoiding the clone is worth delegating the additional responsibility. You could still do this here if you add `.clone()` after `nonGenericParamTypes` on L344 > > @cl4es Do you think it's worth creating a separate PR for `ConstructorRepository.getGenericParameterTypes()`? @stsypanov the remaining improvements in this PR are fine, simple wins. Adding complexity to expose shared arrays would warrant a bit more proof, however. For example a microbenchmark. My gut feeling is it's a marginal win on likely to be rare operations, but I couldn't know for sure without any evidence. ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From duke at openjdk.java.net Mon Jan 10 11:56:57 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 10 Jan 2022 11:56:57 GMT Subject: RFR: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code [v3] In-Reply-To: References: Message-ID: <1av5loDQwiMf7BuSCZXnDxriXXAPv9IN3_nVaK8XVRA=.ace0e9c1-50d5-48e2-b328-9a27d2937529@github.com> > `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - 8278461: Revert Executable - 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code ------------- Changes: https://git.openjdk.java.net/jdk/pull/6782/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6782&range=02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6782.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6782/head:pull/6782 PR: https://git.openjdk.java.net/jdk/pull/6782 From jwilhelm at openjdk.java.net Mon Jan 10 17:10:40 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 10 Jan 2022 17:10:40 GMT Subject: Integrated: Merge jdk18 Message-ID: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8274679: Remove unnecessary conversion to String in security code in java.base - 8142362: Lots of code duplication in Copy class - 8218857: Confusing overloads for os::open - 8183227: read/write APIs in class os shall return ssize_t - 8279300: [arm32] SIGILL when running GetObjectSizeIntrinsicsTest - 8278329: some TraceDeoptimization code not included in PRODUCT build - 8279523: Parallel: Remove unnecessary PSScavenge::_to_space_top_before_gc - 8279522: Serial: Remove unused Generation::clear_remembered_set - 8279528: Unused TypeEnter.diag after JDK-8205187 - ... and 163 more: https://git.openjdk.java.net/jdk/compare/40df5df9...6ff1c607 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/7017/files Stats: 27994 lines in 750 files changed: 20678 ins; 5315 del; 2001 mod Patch: https://git.openjdk.java.net/jdk/pull/7017.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7017/head:pull/7017 PR: https://git.openjdk.java.net/jdk/pull/7017 From jwilhelm at openjdk.java.net Mon Jan 10 17:10:41 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 10 Jan 2022 17:10:41 GMT Subject: Integrated: Merge jdk18 In-Reply-To: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> References: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> Message-ID: On Mon, 10 Jan 2022 17:00:05 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: d9b1bb58 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/d9b1bb58600c03cee43387864d1530d4dd5f1422 Stats: 615 lines in 24 files changed: 478 ins; 77 del; 60 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7017 From rkennke at openjdk.java.net Mon Jan 10 20:46:40 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 10 Jan 2022 20:46:40 GMT Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v3] In-Reply-To: <8u6WbnOQeOGKdgocGPbBLFM57rzzRWkGdIT3Mu5Qj38=.0e9a2dc3-7493-4a91-917b-a3ae33630b72@github.com> References: <8u6WbnOQeOGKdgocGPbBLFM57rzzRWkGdIT3Mu5Qj38=.0e9a2dc3-7493-4a91-917b-a3ae33630b72@github.com> Message-ID: On Fri, 10 Dec 2021 21:07:37 GMT, Roman Kennke wrote: >> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [ ] tier3 > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into JDK-8278065 > - 8278065: Refactor subclassAudits to use ClassValue > - Remove unused EntryFuture inner class from ObjectSteamClass > - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072 > - Use ClassValue to solve JDK-8277072 > - Use ForceGC instead of System.gc() > - Convert test to testng > - Fix indentation of new testcase > - 8277072: ObjectStreamClass caches keep ClassLoaders alive I think we shoul > ...well I tried to do that. And it is not so simple. Here's what I came up with: > > ```java > public final class ClassFlags { > > private static final class AtomicByte { > private static final VarHandle VALUE; > > static { > try { > VALUE = MethodHandles.lookup().findVarHandle(AtomicByte.class, "value", byte.class); > } catch (NoSuchFieldException | IllegalAccessException e) { > throw new InternalError(e); > } > } > > private volatile byte value; > > byte get() { > return value; > } > > byte compareAndExchange(byte expectedValue, byte newValue) { > return (byte) VALUE.compareAndExchange(this, (byte) expectedValue, (byte) newValue); > } > } > > private final Predicate>[] typePredicates; > private final ClassValue flagsCV = new ClassValue<>() { > @Override > protected AtomicByte computeValue(Class type) { > return new AtomicByte(); > } > }; > > @SafeVarargs > public ClassFlags(Predicate>... typePredicates) { > if (typePredicates.length > 4) { > throw new IllegalArgumentException("Up to 4 flags are supported in a single ClassFlags instance"); > } > this.typePredicates = typePredicates; > } > > public boolean get(Class type, int index) { > Objects.checkIndex(index, typePredicates.length); > > AtomicByte flags = flagsCV.get(type); > int f = flags.get() & 0xFF; > int falseMask = 0x1 << (index + index); > int trueMask = falseMask << 1; > int mask = falseMask | trueMask; > int value = 0; > while ((f & mask) == 0) { > if (value == 0) { > value = typePredicates[index].test(type) ? trueMask : falseMask; > } > int fn = (f & ~mask) | value; > int fv = flags.compareAndExchange((byte) f, (byte) fn) & 0xFF; > if (fv == f) { > f = fn; > break; > } else { > f = fv; > } > } > return (f & trueMask) != 0; > } > } > ``` > > So I don't know if it's worth it... Simplicity of your implementation probably out-weights the footprint savings of above code. > > Regards, Peter I think I'd rather keep it simple. Can you please give it a review, too? Thanks, Roman ------------- PR: https://git.openjdk.java.net/jdk/pull/6637 From vyommani at gmail.com Tue Jan 11 06:50:07 2022 From: vyommani at gmail.com (Vyom Tiwari) Date: Tue, 11 Jan 2022 12:20:07 +0530 Subject: jdk11u build failure on Windows Message-ID: Hi, I am facing the build issue with OpenJDK11(jdk11u). I am trying to build jdk11u on Windows and I am getting the below error. #################### ./src/java.base/windows/native/libnet/net_util_md.c(792): error C2065: 'TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS': undeclared identifier make[3]: *** [Lib-java.base.gmk:44: /cygdrive/d/source/mirrors_github_jdk11u/build/windows-x86_64-normal-server-release/support/native/java.base/libnet/net_util_md.obj] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2 ERROR: Build failed for target 'images' in configuration 'windows-x86_64-normal-server-release' (exit code 2) Stopping sjavac server ################### I found that the back-port of JDK-8250521 is causing this failure. My environment details are as follows. OS: Windows Server 2016 Standard, Visual Studio professional 2017 version 15.2(26430.14) When I updated my Visual Studio to 15.9.42(which contains Windows 10 SDK(10.0.17134.0)) the problem went away. My question is do we have a minimum supported Visual Studio(15.9.42) to build jdk11u(11.0.14) ?. If this is not the case then I would like to fix this build failure. Thanks, Vyom From duke at openjdk.java.net Tue Jan 11 09:34:30 2022 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Tue, 11 Jan 2022 09:34:30 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Mon, 15 Nov 2021 19:31:09 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results > > Enhanced intervals in MathUtils. > Updated references to Schubfach v4. En attendant go! go! ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From redestad at openjdk.java.net Tue Jan 11 12:44:46 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 11 Jan 2022 12:44:46 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 Message-ID: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. Results on the updated micros: 19-b04: Benchmark (charsetName) Mode Cnt Score Error Units StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op Patch: Benchmark (charsetName) Mode Cnt Score Error Units StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: 8u311: Benchmark (charsetName) Mode Cnt Score Error Units StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op 9: Benchmark (charsetName) Mode Cnt Score Error Units StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. ------------- Commit messages: - Merge branch 'master' into string_encodeutf8_16 - Loop optimization issue in String.encodeUTF8_UTF16 Changes: https://git.openjdk.java.net/jdk/pull/7026/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7026&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279833 Stats: 85 lines in 2 files changed: 44 ins; 3 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/7026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7026/head:pull/7026 PR: https://git.openjdk.java.net/jdk/pull/7026 From redestad at openjdk.java.net Tue Jan 11 13:05:00 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 11 Jan 2022 13:05:00 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v2] In-Reply-To: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: > In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. > > Results on the updated micros: > 19-b04: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op > > > Patch: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op > > > Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: > > 8u311: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op > > 9: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op > > > (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) > > There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Remove unused Blackholes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7026/files - new: https://git.openjdk.java.net/jdk/pull/7026/files/70d0c5c6..61f7f3d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7026&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7026&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7026/head:pull/7026 PR: https://git.openjdk.java.net/jdk/pull/7026 From shade at openjdk.java.net Tue Jan 11 13:05:01 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 11 Jan 2022 13:05:01 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v2] In-Reply-To: References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: On Tue, 11 Jan 2022 13:02:21 GMT, Claes Redestad wrote: >> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. >> >> Results on the updated micros: >> 19-b04: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op >> >> >> Patch: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op >> >> >> Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: >> >> 8u311: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op >> >> 9: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op >> >> >> (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) >> >> There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused Blackholes Looks fine, consider touchups in benchmark code. test/micro/org/openjdk/bench/java/lang/StringEncode.java line 113: > 111: > 112: @Benchmark > 113: public byte[] encodeUTF16LongEnd(Blackhole bh) throws Exception { Here and later: can drop `bh` argument, since you don't need it anymore. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7026 From redestad at openjdk.java.net Tue Jan 11 13:05:03 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 11 Jan 2022 13:05:03 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v2] In-Reply-To: References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: <6A-PvyxWpFS0TpPyWZ-x_ltv9wypQFVdPgPP5DLxl1E=.12d14639-4b07-4276-9a40-50bb4d2394c4@github.com> On Tue, 11 Jan 2022 12:57:49 GMT, Aleksey Shipilev wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused Blackholes > > test/micro/org/openjdk/bench/java/lang/StringEncode.java line 113: > >> 111: >> 112: @Benchmark >> 113: public byte[] encodeUTF16LongEnd(Blackhole bh) throws Exception { > > Here and later: can drop `bh` argument, since you don't need it anymore. Fixed, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7026 From redestad at openjdk.java.net Tue Jan 11 13:09:07 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 11 Jan 2022 13:09:07 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v3] In-Reply-To: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: > In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. > > Results on the updated micros: > 19-b04: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op > > > Patch: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op > > > Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: > > 8u311: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op > > 9: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op > > > (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) > > There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix odd comment placement ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7026/files - new: https://git.openjdk.java.net/jdk/pull/7026/files/61f7f3d4..5b3dd69a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7026&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7026&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7026/head:pull/7026 PR: https://git.openjdk.java.net/jdk/pull/7026 From alanb at openjdk.java.net Tue Jan 11 13:33:23 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 11 Jan 2022 13:33:23 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v3] In-Reply-To: References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: On Tue, 11 Jan 2022 13:09:07 GMT, Claes Redestad wrote: >> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. >> >> Results on the updated micros: >> 19-b04: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op >> >> >> Patch: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op >> >> >> Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: >> >> 8u311: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op >> >> 9: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op >> >> >> (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) >> >> There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Fix odd comment placement A good find, hopefully it will be linked to the C2 issue. This is the first change to both files in 2022 so you might have to update the copyright headers. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7026 From redestad at openjdk.java.net Tue Jan 11 13:53:58 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 11 Jan 2022 13:53:58 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v4] In-Reply-To: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: > In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. > > Results on the updated micros: > 19-b04: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op > > > Patch: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op > > > Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: > > 8u311: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op > > 9: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op > > > (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) > > There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Happy new year! ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7026/files - new: https://git.openjdk.java.net/jdk/pull/7026/files/5b3dd69a..f13ff236 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7026&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7026&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7026/head:pull/7026 PR: https://git.openjdk.java.net/jdk/pull/7026 From alanb at openjdk.java.net Tue Jan 11 13:53:59 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 11 Jan 2022 13:53:59 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v4] In-Reply-To: References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: On Tue, 11 Jan 2022 13:50:48 GMT, Claes Redestad wrote: >> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. >> >> Results on the updated micros: >> 19-b04: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op >> >> >> Patch: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op >> >> >> Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: >> >> 8u311: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op >> >> 9: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op >> >> >> (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) >> >> There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Happy new year! Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7026 From redestad at openjdk.java.net Tue Jan 11 14:51:34 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 11 Jan 2022 14:51:34 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v4] In-Reply-To: References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: On Tue, 11 Jan 2022 12:58:51 GMT, Aleksey Shipilev wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Happy new year! > > Looks fine, consider touchups in benchmark code. Thanks for reviewing, @shipilev and @AlanBateman ------------- PR: https://git.openjdk.java.net/jdk/pull/7026 From redestad at openjdk.java.net Tue Jan 11 14:51:35 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 11 Jan 2022 14:51:35 GMT Subject: Integrated: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 In-Reply-To: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: <1VusP-N9Oft3c4-d7-Hj7UDggTlV4TJAelxmX_9zN9o=.be884700-fb6c-40ac-ae7f-b1800a6a681d@github.com> On Tue, 11 Jan 2022 12:30:44 GMT, Claes Redestad wrote: > In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. > > Results on the updated micros: > 19-b04: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op > > > Patch: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op > > > Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: > > 8u311: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op > > 9: > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op > > > (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) > > There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. This pull request has now been integrated. Changeset: c3d0a940 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/c3d0a94040d9bd0f4b99da97b89fbfce252a41c0 Stats: 88 lines in 2 files changed: 45 ins; 4 del; 39 mod 8279833: Loop optimization issue in String.encodeUTF8_UTF16 Reviewed-by: shade, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7026 From dfuchs at openjdk.java.net Tue Jan 11 15:27:29 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 11 Jan 2022 15:27:29 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna wrote: >> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. >> >> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. > > Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: > > Allow the test to pass on MacOSX test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java line 88: > 86: env.put("com.sun.jndi.ldap.connect.timeout", String.valueOf(CONNECT_MILLIS)); > 87: env.put("com.sun.jndi.ldap.connect.pool", "true"); > 88: env.put(Context.PROVIDER_URL, "ldap://example.com:1234"); I assume this makes the assumption that requests to "example.com:1234" will fail in timeout? If so wouldn't it be safer to create a ServerSocket that never accepts connections? Otherwise looks OK to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From hohensee at amazon.com Tue Jan 11 16:24:48 2022 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 11 Jan 2022 16:24:48 +0000 Subject: jdk11u build failure on Windows Message-ID: <00FB40D5-A43B-4FE4-8EED-2AB4294E472C@amazon.com> Directing to jdk-updates-dev... Paul ?-----Original Message----- From: core-libs-dev on behalf of Vyom Tiwari Date: Monday, January 10, 2022 at 10:51 PM To: net-dev , core-libs-dev Cc: "kusrinivasan at vmware.com" Subject: jdk11u build failure on Windows Hi, I am facing the build issue with OpenJDK11(jdk11u). I am trying to build jdk11u on Windows and I am getting the below error. #################### ./src/java.base/windows/native/libnet/net_util_md.c(792): error C2065: 'TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS': undeclared identifier make[3]: *** [Lib-java.base.gmk:44: /cygdrive/d/source/mirrors_github_jdk11u/build/windows-x86_64-normal-server-release/support/native/java.base/libnet/net_util_md.obj] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2 ERROR: Build failed for target 'images' in configuration 'windows-x86_64-normal-server-release' (exit code 2) Stopping sjavac server ################### I found that the back-port of JDK-8250521 is causing this failure. My environment details are as follows. OS: Windows Server 2016 Standard, Visual Studio professional 2017 version 15.2(26430.14) When I updated my Visual Studio to 15.9.42(which contains Windows 10 SDK(10.0.17134.0)) the problem went away. My question is do we have a minimum supported Visual Studio(15.9.42) to build jdk11u(11.0.14) ?. If this is not the case then I would like to fix this build failure. Thanks, Vyom From dfuchs at openjdk.java.net Tue Jan 11 18:12:27 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 11 Jan 2022 18:12:27 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna wrote: >> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. >> >> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. > > Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: > > Allow the test to pass on MacOSX Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From daniel.fuchs at oracle.com Tue Jan 11 11:00:46 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 11 Jan 2022 11:00:46 +0000 Subject: jdk11u build failure on Windows In-Reply-To: References: Message-ID: Hi Vyom, That's probably a question to ask on the jdk-updates-dev list, which I put in cc: best regards, -- daniel On 11/01/2022 06:50, Vyom Tiwari wrote: > Hi, > I am facing the build issue with ?OpenJDK11(jdk11u). I am trying to > build jdk11u on Windows and I am ?getting the below error. > > #################### > ./src/java.base/windows/native/libnet/net_util_md.c(792): error C2065: > 'TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS': undeclared identifier > make[3]: *** [Lib-java.base.gmk:44: > /cygdrive/d/source/mirrors_github_jdk11u/build/windows-x86_64-normal-server-release/support/native/java.base/libnet/net_util_md.obj] > Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2 > > ERROR: Build failed for target 'images' in configuration > 'windows-x86_64-normal-server-release' (exit code 2) > Stopping sjavac server > ################### > > I found that the back-port of JDK-8250521 > ? is causing this failure. > > My ?environment details are as follows. > OS: Windows Server 2016 Standard, Visual Studio professional 2017 > version 15.2(26430.14) > > When I updated my Visual Studio to 15.9.42(which contains Windows 10 > SDK(10.0.17134.0)) the problem went away. > > My question is do we have a minimum supported Visual Studio(15.9.42) to > build jdk11u(11.0.14) ?. If this is not the case then I would like to > fix this build failure. > > Thanks, > Vyom From igraves at openjdk.java.net Tue Jan 11 22:41:31 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 11 Jan 2022 22:41:31 GMT Subject: RFR: 8276694: Pattern trailing unescaped backslash causes internal error In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 09:57:14 GMT, Masanori Yano wrote: > Could you please review the 8276694 bug fixes? > > A message specific for this exception should be printed instead of an internal error. This fix adds a new check to output an appropriate exception message when the regular expression ends with an unescaped backslash. This fix also checks the position of the cursor to rule out other syntax errors at the middle position of the regular expression. Looks good to me. Sponsoring. ------------- PR: https://git.openjdk.java.net/jdk/pull/6891 From myano at openjdk.java.net Tue Jan 11 22:41:31 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 11 Jan 2022 22:41:31 GMT Subject: Integrated: 8276694: Pattern trailing unescaped backslash causes internal error In-Reply-To: References: Message-ID: <_rPtxDLDdsYTZ5TqfIsOEM0CpNw_IhL2eZDNo02XBII=.d8481a04-5c96-4cc5-9539-e44939f99eef@github.com> On Mon, 20 Dec 2021 09:57:14 GMT, Masanori Yano wrote: > Could you please review the 8276694 bug fixes? > > A message specific for this exception should be printed instead of an internal error. This fix adds a new check to output an appropriate exception message when the regular expression ends with an unescaped backslash. This fix also checks the position of the cursor to rule out other syntax errors at the middle position of the regular expression. This pull request has now been integrated. Changeset: 3aaa0982 Author: Masanori Yano Committer: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/3aaa0982d8c1735208a331b0097a5aea4a1fef5a Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod 8276694: Pattern trailing unescaped backslash causes internal error Reviewed-by: jlaskey ------------- PR: https://git.openjdk.java.net/jdk/pull/6891 From myano at openjdk.java.net Wed Jan 12 05:55:39 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 12 Jan 2022 05:55:39 GMT Subject: RFR: 8278892: java.naming module description is missing @uses tags to document the services that it uses Message-ID: I have fixed the javadoc comments as the definition. Could you review this fix? ------------- Commit messages: - 8278892: java.naming module description is missing @uses tags to document the services that it uses Changes: https://git.openjdk.java.net/jdk/pull/7041/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7041&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278892 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7041.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7041/head:pull/7041 PR: https://git.openjdk.java.net/jdk/pull/7041 From plevart at openjdk.java.net Wed Jan 12 06:49:32 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 12 Jan 2022 06:49:32 GMT Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v3] In-Reply-To: <8u6WbnOQeOGKdgocGPbBLFM57rzzRWkGdIT3Mu5Qj38=.0e9a2dc3-7493-4a91-917b-a3ae33630b72@github.com> References: <8u6WbnOQeOGKdgocGPbBLFM57rzzRWkGdIT3Mu5Qj38=.0e9a2dc3-7493-4a91-917b-a3ae33630b72@github.com> Message-ID: On Fri, 10 Dec 2021 21:07:37 GMT, Roman Kennke wrote: >> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [ ] tier3 > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into JDK-8278065 > - 8278065: Refactor subclassAudits to use ClassValue > - Remove unused EntryFuture inner class from ObjectSteamClass > - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK-8277072 > - Use ClassValue to solve JDK-8277072 > - Use ForceGC instead of System.gc() > - Convert test to testng > - Fix indentation of new testcase > - 8277072: ObjectStreamClass caches keep ClassLoaders alive Marked as reviewed by plevart (Reviewer). I think this looks good. Reviewed. Only a minor nit if you think it would be better, but not necessary if you don't. The following combo: Boolean result = Caches.subclassAudits.get(cl); assert result != null; could be written as: boolean result = Caches.subclassAudits.get(cl); ...and it would give the same "message" to the reader. WDYT? No need for another round of reviews if you change this. ------------- PR: https://git.openjdk.java.net/jdk/pull/6637 From lbourges at openjdk.java.net Wed Jan 12 08:18:32 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 12 Jan 2022 08:18:32 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v10] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Mon, 29 Nov 2021 21:16:32 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Updated javadoc > * Optimized insertion sort threshold > * Refactored parallel sorting section > * Improved step for pivot candidates > * Changed condition for Radix sort Please review this PR, it is ready for months, or give comments, please ! ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From shade at openjdk.java.net Wed Jan 12 08:18:52 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 12 Jan 2022 08:18:52 GMT Subject: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 In-Reply-To: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> References: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Message-ID: <6mCxRizqy43jtGnFXI4gZ1FBpf6ei-sVITX5h3EMbtQ=.fee2141b-ba19-4e04-bb8a-dacc8e081e48@github.com> On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote: > Seems like a missing include. C++ docs say `offsetof` is from ``, adding that include explicitly fixes the build. Seems to only happen with older GCCs, but it seems to be a happy accident it works on newer ones, probably through the transitive include somewhere. > > Additional testing: > - [x] Linux x86_64 fastdebug `tools/jpackage` tests > - [x] Linux x86_64 release `tools/jpackage` tests Still pending review... Or I can push under "triviality" rule, if any Reviewer agrees. ------------- PR: https://git.openjdk.java.net/jdk18/pull/74 From duke at openjdk.java.net Wed Jan 12 10:20:28 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 12 Jan 2022 10:20:28 GMT Subject: Integrated: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 11:50:50 GMT, ?????? ??????? wrote: > `Executable.getParameterTypes()` creates a copy of underlying array which is redundant in trusted code when we are sure the action is read-only. This pull request has now been integrated. Changeset: ece98d85 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/ece98d859d847196d298a28c1a095b09cebbee6f Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/6782 From rkennke at openjdk.java.net Wed Jan 12 11:15:56 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 12 Jan 2022 11:15:56 GMT Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v4] In-Reply-To: References: Message-ID: <17YSTNkx8foJAsQoiMS-wpkWvuyEqmB0PWx8iwpl1So=.d02aa315-86cf-400b-99c2-65f248ef0dc1@github.com> > As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey. > > Testing: > - [x] tier1 > - [x] tier2 > - [ ] tier3 Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/JDK-8278065' into JDK-8278065 - Avoid assert on unboxing Boolean ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6637/files - new: https://git.openjdk.java.net/jdk/pull/6637/files/6b37d520..78bda4b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6637&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6637&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6637/head:pull/6637 PR: https://git.openjdk.java.net/jdk/pull/6637 From rkennke at openjdk.java.net Wed Jan 12 11:18:28 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 12 Jan 2022 11:18:28 GMT Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v3] In-Reply-To: References: <8u6WbnOQeOGKdgocGPbBLFM57rzzRWkGdIT3Mu5Qj38=.0e9a2dc3-7493-4a91-917b-a3ae33630b72@github.com> Message-ID: On Wed, 12 Jan 2022 06:45:02 GMT, Peter Levart wrote: > I think this looks good. Reviewed. Only a minor nit if you think it would be better, but not necessary if you don't. The following combo: > > ``` > Boolean result = Caches.subclassAudits.get(cl); > assert result != null; > ``` > > could be written as: > > ``` > boolean result = Caches.subclassAudits.get(cl); > ``` > > ...and it would give the same "message" to the reader. WDYT? No need for another round of reviews if you change this. Right! I changed it. BTW, I noticed that Thread.java has a similar subclassAudits machinery with WeakClassKey, which would also benefit from using ClassValue instead. I filed JDK-8279917 to track it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6637 From duke at openjdk.java.net Wed Jan 12 12:14:28 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 12 Jan 2022 12:14:28 GMT Subject: RFR: 8278518: String(byte[], int, int, Charset) constructor and String.translateEscapes() miss bounds check elimination In-Reply-To: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com> References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com> Message-ID: <11Q0vZEpe6IHpbvQI0Oqjput4aHOd9FGCO_1YKvjYD4=.3831d1cc-242a-4398-9110-6337b93795a0@github.com> On Mon, 13 Dec 2021 09:39:55 GMT, ?????? ??????? wrote: > Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor > > It looks like in the following code in `String(byte[], int, int, Charset)` > > while (offset < sl) { > int b1 = bytes[offset]; > if (b1 >= 0) { > dst[dp++] = (byte)b1; > offset++; // <--- > continue; > } > if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && > offset + 1 < sl) { > int b2 = bytes[offset + 1]; > if (!isNotContinuation(b2)) { > dst[dp++] = (byte)decode2(b1, b2); > offset += 2; > continue; > } > } > // anything not a latin1, including the repl > // we have to go with the utf16 > break; > } > > bounds check elimination is not executed when accessing byte array via `bytes[offset]. > > The reason, I guess, is that offset variable is modified within the loop (marked with arrow). > > Possible fix for this could be changing: > > `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)` > > However the best is to invest in C2 optimization to handle all such cases. > > The following benchmark demonstrates good improvement: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class StringConstructorBenchmark { > private byte[] array; > private String str; > > @Setup > public void setup() { > str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian > array = str.getBytes(StandardCharsets.UTF_8); > } > > @Benchmark > public String newString() { > return new String(array, 0, array.length, StandardCharsets.UTF_8); > } > > @Benchmark > public String translateEscapes() { > return str.translateEscapes(); > } > } > > Results: > > //baseline > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op > > //patched > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op > > The same is observed in String.translateEscapes() for the same String as in the benchmark above: > > //baseline > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op > > //patched > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op > > Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7. > > Here's the part of baseline assembly responsible for `while` loop: > > 3.62% ?? ? 0x00007fed70eb4c1c: mov %ebx,%ecx > 2.29% ?? ? 0x00007fed70eb4c1e: mov %edx,%r9d > 2.22% ?? ? 0x00007fed70eb4c21: mov (%rsp),%r8 ;*iload_2 {reexecute=0 rethrow=0 return_oop=0} > ?? ? ; - java.lang.String::<init>@107 (line 537) > 2.32% ?? ? 0x00007fed70eb4c25: cmp %r13d,%ecx > ? ? 0x00007fed70eb4c28: jge 0x00007fed70eb5388 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} > ? ? ; - java.lang.String::<init>@110 (line 537) > 3.05% ? ? 0x00007fed70eb4c2e: cmp 0x8(%rsp),%ecx > ? ? 0x00007fed70eb4c32: jae 0x00007fed70eb5319 > 2.38% ? ? 0x00007fed70eb4c38: mov %r8,(%rsp) > 2.64% ? ? 0x00007fed70eb4c3c: movslq %ecx,%r8 > 2.46% ? ? 0x00007fed70eb4c3f: mov %rax,%rbx > 3.44% ? ? 0x00007fed70eb4c42: sub %r8,%rbx > 2.62% ? ? 0x00007fed70eb4c45: add $0x1,%rbx > 2.64% ? ? 0x00007fed70eb4c49: and $0xfffffffffffffffe,%rbx > 2.30% ? ? 0x00007fed70eb4c4d: mov %ebx,%r8d > 3.08% ? ? 0x00007fed70eb4c50: add %ecx,%r8d > 2.55% ? ? 0x00007fed70eb4c53: movslq %r8d,%r8 > 2.45% ? ? 0x00007fed70eb4c56: add $0xfffffffffffffffe,%r8 > 2.13% ? ? 0x00007fed70eb4c5a: cmp (%rsp),%r8 > ? ? 0x00007fed70eb4c5e: jae 0x00007fed70eb5319 > 3.36% ? ? 0x00007fed70eb4c64: mov %ecx,%edi ;*aload_1 {reexecute=0 rethrow=0 return_oop=0} > ? ? ; - java.lang.String::<init>@113 (line 538) > 2.86% ? ?? 0x00007fed70eb4c66: movsbl 0x10(%r14,%rdi,1),%r8d ;*baload {reexecute=0 rethrow=0 return_oop=0} > ? ?? ; - java.lang.String::<init>@115 (line 538) > 2.48% ? ?? 0x00007fed70eb4c6c: mov %r9d,%edx > 2.26% ? ?? 0x00007fed70eb4c6f: inc %edx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ?? ; - java.lang.String::<init>@127 (line 540) > 3.28% ? ?? 0x00007fed70eb4c71: mov %edi,%ebx > 2.44% ? ?? 0x00007fed70eb4c73: inc %ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ?? ; - java.lang.String::<init>@134 (line 541) > 2.35% ? ?? 0x00007fed70eb4c75: test %r8d,%r8d > ? ?? 0x00007fed70eb4c78: jge 0x00007fed70eb4c04 ;*iflt {reexecute=0 rethrow=0 return_oop=0} > ?? ; - java.lang.String::<init>@120 (line 539) > > and this one is for patched code: > > 17.28% ?? 0x00007f6b88eb6061: mov %edx,%r10d ;*iload_2 {reexecute=0 rethrow=0 return_oop=0} > ?? ; - java.lang.String::<init>@107 (line 537) > 0.11% ?? 0x00007f6b88eb6064: test %r10d,%r10d > ? 0x00007f6b88eb6067: jl 0x00007f6b88eb669c ;*iflt {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@108 (line 537) > 0.39% ? 0x00007f6b88eb606d: cmp %r13d,%r10d > ? 0x00007f6b88eb6070: jge 0x00007f6b88eb66d0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@114 (line 537) > 0.66% ? 0x00007f6b88eb6076: mov %ebx,%r9d > 13.70% ? 0x00007f6b88eb6079: cmp 0x8(%rsp),%r10d > 0.01% ? 0x00007f6b88eb607e: jae 0x00007f6b88eb6671 > 0.14% ? 0x00007f6b88eb6084: movsbl 0x10(%r14,%r10,1),%edi ;*baload {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@119 (line 538) > 0.37% ? 0x00007f6b88eb608a: mov %r9d,%ebx > 0.99% ? 0x00007f6b88eb608d: inc %ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@131 (line 540) > 12.88% ? 0x00007f6b88eb608f: movslq %r9d,%rsi ;*bastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@196 (line 548) > 0.17% ? 0x00007f6b88eb6092: mov %r10d,%edx > 0.39% ? 0x00007f6b88eb6095: inc %edx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@138 (line 541) > 0.96% ? 0x00007f6b88eb6097: test %edi,%edi > 0.02% ? 0x00007f6b88eb6099: jl 0x00007f6b88eb60dc ;*iflt {reexecute=0 rethrow=0 return_oop=0} > > Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code. As soon as the proper fix is provided in https://github.com/openjdk/jdk/pull/7034 I close this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6812 From duke at openjdk.java.net Wed Jan 12 12:14:28 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 12 Jan 2022 12:14:28 GMT Subject: Withdrawn: 8278518: String(byte[], int, int, Charset) constructor and String.translateEscapes() miss bounds check elimination In-Reply-To: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com> References: <2IcCYyqxBU_oi_i9n1LZzTivcLD7QWxAlZga6kiGOPg=.a09fd12b-d1aa-4124-9bb2-31f86da2f706@github.com> Message-ID: On Mon, 13 Dec 2021 09:39:55 GMT, ?????? ??????? wrote: > Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor > > It looks like in the following code in `String(byte[], int, int, Charset)` > > while (offset < sl) { > int b1 = bytes[offset]; > if (b1 >= 0) { > dst[dp++] = (byte)b1; > offset++; // <--- > continue; > } > if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && > offset + 1 < sl) { > int b2 = bytes[offset + 1]; > if (!isNotContinuation(b2)) { > dst[dp++] = (byte)decode2(b1, b2); > offset += 2; > continue; > } > } > // anything not a latin1, including the repl > // we have to go with the utf16 > break; > } > > bounds check elimination is not executed when accessing byte array via `bytes[offset]. > > The reason, I guess, is that offset variable is modified within the loop (marked with arrow). > > Possible fix for this could be changing: > > `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)` > > However the best is to invest in C2 optimization to handle all such cases. > > The following benchmark demonstrates good improvement: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class StringConstructorBenchmark { > private byte[] array; > private String str; > > @Setup > public void setup() { > str = "Quizdeltagerne spiste jordb?r med fl?de, mens cirkusklovnen. ?";//Latin1 ending with Russian > array = str.getBytes(StandardCharsets.UTF_8); > } > > @Benchmark > public String newString() { > return new String(array, 0, array.length, StandardCharsets.UTF_8); > } > > @Benchmark > public String translateEscapes() { > return str.translateEscapes(); > } > } > > Results: > > //baseline > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.newString avgt 50 173,092 ? 3,048 ns/op > > //patched > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.newString avgt 50 126,908 ? 2,355 ns/op > > The same is observed in String.translateEscapes() for the same String as in the benchmark above: > > //baseline > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.translateEscapes avgt 100 53,627 ? 0,850 ns/op > > //patched > Benchmark Mode Cnt Score Error Units > StringConstructorBenchmark.translateEscapes avgt 100 48,087 ? 1,129 ns/op > > Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7. > > Here's the part of baseline assembly responsible for `while` loop: > > 3.62% ?? ? 0x00007fed70eb4c1c: mov %ebx,%ecx > 2.29% ?? ? 0x00007fed70eb4c1e: mov %edx,%r9d > 2.22% ?? ? 0x00007fed70eb4c21: mov (%rsp),%r8 ;*iload_2 {reexecute=0 rethrow=0 return_oop=0} > ?? ? ; - java.lang.String::<init>@107 (line 537) > 2.32% ?? ? 0x00007fed70eb4c25: cmp %r13d,%ecx > ? ? 0x00007fed70eb4c28: jge 0x00007fed70eb5388 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} > ? ? ; - java.lang.String::<init>@110 (line 537) > 3.05% ? ? 0x00007fed70eb4c2e: cmp 0x8(%rsp),%ecx > ? ? 0x00007fed70eb4c32: jae 0x00007fed70eb5319 > 2.38% ? ? 0x00007fed70eb4c38: mov %r8,(%rsp) > 2.64% ? ? 0x00007fed70eb4c3c: movslq %ecx,%r8 > 2.46% ? ? 0x00007fed70eb4c3f: mov %rax,%rbx > 3.44% ? ? 0x00007fed70eb4c42: sub %r8,%rbx > 2.62% ? ? 0x00007fed70eb4c45: add $0x1,%rbx > 2.64% ? ? 0x00007fed70eb4c49: and $0xfffffffffffffffe,%rbx > 2.30% ? ? 0x00007fed70eb4c4d: mov %ebx,%r8d > 3.08% ? ? 0x00007fed70eb4c50: add %ecx,%r8d > 2.55% ? ? 0x00007fed70eb4c53: movslq %r8d,%r8 > 2.45% ? ? 0x00007fed70eb4c56: add $0xfffffffffffffffe,%r8 > 2.13% ? ? 0x00007fed70eb4c5a: cmp (%rsp),%r8 > ? ? 0x00007fed70eb4c5e: jae 0x00007fed70eb5319 > 3.36% ? ? 0x00007fed70eb4c64: mov %ecx,%edi ;*aload_1 {reexecute=0 rethrow=0 return_oop=0} > ? ? ; - java.lang.String::<init>@113 (line 538) > 2.86% ? ?? 0x00007fed70eb4c66: movsbl 0x10(%r14,%rdi,1),%r8d ;*baload {reexecute=0 rethrow=0 return_oop=0} > ? ?? ; - java.lang.String::<init>@115 (line 538) > 2.48% ? ?? 0x00007fed70eb4c6c: mov %r9d,%edx > 2.26% ? ?? 0x00007fed70eb4c6f: inc %edx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ?? ; - java.lang.String::<init>@127 (line 540) > 3.28% ? ?? 0x00007fed70eb4c71: mov %edi,%ebx > 2.44% ? ?? 0x00007fed70eb4c73: inc %ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ?? ; - java.lang.String::<init>@134 (line 541) > 2.35% ? ?? 0x00007fed70eb4c75: test %r8d,%r8d > ? ?? 0x00007fed70eb4c78: jge 0x00007fed70eb4c04 ;*iflt {reexecute=0 rethrow=0 return_oop=0} > ?? ; - java.lang.String::<init>@120 (line 539) > > and this one is for patched code: > > 17.28% ?? 0x00007f6b88eb6061: mov %edx,%r10d ;*iload_2 {reexecute=0 rethrow=0 return_oop=0} > ?? ; - java.lang.String::<init>@107 (line 537) > 0.11% ?? 0x00007f6b88eb6064: test %r10d,%r10d > ? 0x00007f6b88eb6067: jl 0x00007f6b88eb669c ;*iflt {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@108 (line 537) > 0.39% ? 0x00007f6b88eb606d: cmp %r13d,%r10d > ? 0x00007f6b88eb6070: jge 0x00007f6b88eb66d0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@114 (line 537) > 0.66% ? 0x00007f6b88eb6076: mov %ebx,%r9d > 13.70% ? 0x00007f6b88eb6079: cmp 0x8(%rsp),%r10d > 0.01% ? 0x00007f6b88eb607e: jae 0x00007f6b88eb6671 > 0.14% ? 0x00007f6b88eb6084: movsbl 0x10(%r14,%r10,1),%edi ;*baload {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@119 (line 538) > 0.37% ? 0x00007f6b88eb608a: mov %r9d,%ebx > 0.99% ? 0x00007f6b88eb608d: inc %ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@131 (line 540) > 12.88% ? 0x00007f6b88eb608f: movslq %r9d,%rsi ;*bastore {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@196 (line 548) > 0.17% ? 0x00007f6b88eb6092: mov %r10d,%edx > 0.39% ? 0x00007f6b88eb6095: inc %edx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ? ; - java.lang.String::<init>@138 (line 541) > 0.96% ? 0x00007f6b88eb6097: test %edi,%edi > 0.02% ? 0x00007f6b88eb6099: jl 0x00007f6b88eb60dc ;*iflt {reexecute=0 rethrow=0 return_oop=0} > > Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6812 From duke at openjdk.java.net Wed Jan 12 12:30:25 2022 From: duke at openjdk.java.net (kabutz) Date: Wed, 12 Jan 2022 12:30:25 GMT Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: <_wcoiWpZbCMIRim1gnlAPt74mpi55obfnqIE2zOKmyA=.c8c33816-1dc5-49de-a11f-419b4989d18e@github.com> On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. >> >> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Refactored empty stream implementations to reduce duplicate code and improved unordered() > Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream() Another comment ------------- PR: https://git.openjdk.java.net/jdk/pull/6275 From duke at openjdk.java.net Wed Jan 12 12:59:31 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 12 Jan 2022 12:59:31 GMT Subject: RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 [v4] In-Reply-To: References: <5KiieyL-qpnDSqC0pcKiLgTttXsFJlw3Tc-684XFyek=.48925dd8-7822-47d6-b451-4b68287f1a8e@github.com> Message-ID: On Tue, 11 Jan 2022 13:53:58 GMT, Claes Redestad wrote: >> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps the performance of the method by helping C2 optimize each individual loop better. >> >> Results on the updated micros: >> 19-b04: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ? 7.296 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ? 40.580 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ? 124.636 ns/op >> >> >> Patch: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ? 6.693 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ? 46.891 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ? 64.896 ns/op >> >> >> Going back this seem to have been an issue since this method was introduced with JEP 254 in JDK 9: >> >> 8u311: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ? 3.913 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ? 88.386 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ? 247.230 ns/op >> >> 9: >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ? 9.374 ns/op >> StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ? 263.372 ns/op >> StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ? 408.338 ns/op >> >> >> (Interestingly JDK 9 seem faster on some of the micros than later iterations, while slower on others. The main issue is the slow non-ASCII loop, where the patch speeds things up ~2x. With the patch we're significantly faster than both JDK 8 and 9 on all measures.) >> >> There's a JIT compiler bug hiding in plain sight here where the potentially uninitialized local `char c` appears to mess up optimization of the second loop. I'll file a separate bug for this (a standalone reproducer should be straightforward to produce). I think this patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this kind of condition. It might also be easier to backport, depending on whether the C2 fix is trivial or not. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Happy new year! Looks like there's one more similar case: https://github.com/openjdk/jdk/pull/7034 ------------- PR: https://git.openjdk.java.net/jdk/pull/7026 From aefimov at openjdk.java.net Wed Jan 12 13:25:30 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 12 Jan 2022 13:25:30 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna wrote: >> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. >> >> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. > > Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: > > Allow the test to pass on MacOSX The changes look good to me. Few minor comments: The last modification year in copyright headers can be updated. test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java line 29: > 27: * lib/ > 28: * @run testng/othervm LdapPoolTimeoutTest > 29: * @bug JDK-8277795 I believe the `JDK-` prefix is not needed in `@ bug` tag value. Tags can be also reordered to follow the recommendations [here](https://openjdk.java.net/jtreg/tag-spec.html#ORDER). ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From dfuchs at openjdk.java.net Wed Jan 12 13:28:25 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 12 Jan 2022 13:28:25 GMT Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5] In-Reply-To: References: Message-ID: On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing BufferedInputStream src/java.base/share/classes/java/io/BufferedInputStream.java line 501: > 499: return avail + getInIfOpen().transferTo(out); > 500: } > 501: Hi Markus, did you double check with all the existing subclasses of `BufferedInputStream` that the new implementation of `transferTo` will not cause trouble, if any of the subclasses is overriding `int read(byte[] b, int off, int len)`? If I'm not mistaken - with this new implementation of `transferTo` then `BufferedInputStream::read(byte[] b, int off, int len)` (a public method that can be overridden) will no longer be called by `transferTo`. This could be causing problems if `read` is overriden to do some special processing in the subclass. ------------- PR: https://git.openjdk.java.net/jdk/pull/6935 From rkennke at openjdk.java.net Wed Jan 12 13:50:27 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 12 Jan 2022 13:50:27 GMT Subject: Integrated: 8278065: Refactor subclassAudits to use ClassValue In-Reply-To: References: Message-ID: <2HtD-FCuQtZUGzm0hOeCgADHzqO7UUFz6uSuH7HyivU=.4c0ba27a-fdd7-49c3-b6e2-f23788a45df2@github.com> On Wed, 1 Dec 2021 14:45:23 GMT, Roman Kennke wrote: > As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey. > > Testing: > - [x] tier1 > - [x] tier2 > - [ ] tier3 This pull request has now been integrated. Changeset: 8fed8ab2 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/8fed8ab29cae4f189f44609c23f116967eef6bdf Stats: 105 lines in 3 files changed: 2 ins; 89 del; 14 mod 8278065: Refactor subclassAudits to use ClassValue Reviewed-by: rriggs, plevart ------------- PR: https://git.openjdk.java.net/jdk/pull/6637 From jpai at openjdk.java.net Wed Jan 12 13:52:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 12 Jan 2022 13:52:49 GMT Subject: RFR: 8279921: Dump the .class file in jlink debug mode for any failure during transform() of a plugin Message-ID: Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8279921? The change here builds upon the debugging enhancement that was done in https://github.com/openjdk/jdk/pull/6696 to try and narrow down the problem behind intermittent failures on macos ARM systems. The previous change caught only `IllegalArgumentException` to dump the class file, but as seen in a recent failure, the exception type itself isn't guaranteed to be the same due to the nature of the issue. So, this commit catches `Exception` to dump the class file. Additionally, the change here also prints out the underlying `ResourcePoolEntry` type to see if that provides any additional hints on why the class content could end being corrupt. ------------- Commit messages: - 8279921: Dump the .class file in jlink debug mode for any failure during transform() of a plugin Changes: https://git.openjdk.java.net/jdk/pull/7049/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7049&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279921 Stats: 21 lines in 2 files changed: 16 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7049.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7049/head:pull/7049 PR: https://git.openjdk.java.net/jdk/pull/7049 From duke at openjdk.java.net Wed Jan 12 14:22:03 2022 From: duke at openjdk.java.net (iaroslavski) Date: Wed, 12 Jan 2022 14:22:03 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski has updated the pull request incrementally with one additional commit since the last revision: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) * Updated javadoc * Improved mixed insertion * Optimized sort networking * Improved pivot partitioning ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/41b92f67..95f15386 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=09-10 Stats: 798 lines in 1 file changed: 230 ins; 226 del; 342 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From rriggs at openjdk.java.net Wed Jan 12 14:30:27 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 12 Jan 2022 14:30:27 GMT Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v4] In-Reply-To: <17YSTNkx8foJAsQoiMS-wpkWvuyEqmB0PWx8iwpl1So=.d02aa315-86cf-400b-99c2-65f248ef0dc1@github.com> References: <17YSTNkx8foJAsQoiMS-wpkWvuyEqmB0PWx8iwpl1So=.d02aa315-86cf-400b-99c2-65f248ef0dc1@github.com> Message-ID: <_mjk-VhVj_DBtYBTOVZryIW80l_hI5Y1MzH7F6GwgsQ=.b20c7ff7-0e1d-4e6f-9a24-1247c324eca7@github.com> On Wed, 12 Jan 2022 11:15:56 GMT, Roman Kennke wrote: >> As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [ ] tier3 > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/JDK-8278065' into JDK-8278065 > - Avoid assert on unboxing Boolean I would have appreciated a chance to review the latest changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/6637 From mcimadamore at openjdk.java.net Wed Jan 12 15:54:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 12 Jan 2022 15:54:49 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments Message-ID: When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. ------------- Commit messages: - Minor javadoc fix - Merge branch 'master' into remove_generics_heap_segments - Initial push Changes: https://git.openjdk.java.net/jdk18/pull/97/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=97&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279930 Stats: 199 lines in 3 files changed: 172 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk18/pull/97.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/97/head:pull/97 PR: https://git.openjdk.java.net/jdk18/pull/97 From rkennke at openjdk.java.net Wed Jan 12 16:04:33 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 12 Jan 2022 16:04:33 GMT Subject: RFR: 8278065: Refactor subclassAudits to use ClassValue [v4] In-Reply-To: <_mjk-VhVj_DBtYBTOVZryIW80l_hI5Y1MzH7F6GwgsQ=.b20c7ff7-0e1d-4e6f-9a24-1247c324eca7@github.com> References: <17YSTNkx8foJAsQoiMS-wpkWvuyEqmB0PWx8iwpl1So=.d02aa315-86cf-400b-99c2-65f248ef0dc1@github.com> <_mjk-VhVj_DBtYBTOVZryIW80l_hI5Y1MzH7F6GwgsQ=.b20c7ff7-0e1d-4e6f-9a24-1247c324eca7@github.com> Message-ID: On Wed, 12 Jan 2022 14:27:17 GMT, Roger Riggs wrote: > I would have appreciated a chance to review the latest changes. Oh, ok, I'm sorry. I will wait some more next time that I get into a similar situation. I hope you're ok with the changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/6637 From asemenyuk at openjdk.java.net Wed Jan 12 17:47:35 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 12 Jan 2022 17:47:35 GMT Subject: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 In-Reply-To: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> References: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Message-ID: On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote: > Seems like a missing include. C++ docs say `offsetof` is from ``, adding that include explicitly fixes the build. Seems to only happen with older GCCs, but it seems to be a happy accident it works on newer ones, probably through the transitive include somewhere. > > Additional testing: > - [x] Linux x86_64 fastdebug `tools/jpackage` tests > - [x] Linux x86_64 release `tools/jpackage` tests Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/74 From duke at openjdk.java.net Wed Jan 12 18:35:26 2022 From: duke at openjdk.java.net (iaroslavski) Date: Wed, 12 Jan 2022 18:35:26 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Wed, 12 Jan 2022 14:22:03 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Updated javadoc > * Improved mixed insertion > * Optimized sort networking > * Improved pivot partitioning Please review optimized sorting code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From psandoz at openjdk.java.net Wed Jan 12 18:48:39 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 12 Jan 2022 18:48:39 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 15:48:20 GMT, Maurizio Cimadamore wrote: > When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java line 89: > 87: public static class OfByte extends HeapMemorySegmentImpl { > 88: > 89: OfByte(long offset, Object base, long length, int mask) { Is it possible to retain the array type for the constructor? ------------- PR: https://git.openjdk.java.net/jdk18/pull/97 From kcr at openjdk.java.net Wed Jan 12 19:05:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 19:05:29 GMT Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. The CSR is now approved. This comment should be sufficient to wake up the bot. ------------- PR: https://git.openjdk.java.net/jdk/pull/6974 From mcimadamore at openjdk.java.net Wed Jan 12 19:10:39 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 12 Jan 2022 19:10:39 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 18:45:11 GMT, Paul Sandoz wrote: >> When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java line 89: > >> 87: public static class OfByte extends HeapMemorySegmentImpl { >> 88: >> 89: OfByte(long offset, Object base, long length, int mask) { > > Is it possible to retain the array type for the constructor? yes, that should be harmless ------------- PR: https://git.openjdk.java.net/jdk18/pull/97 From mcimadamore at openjdk.java.net Wed Jan 12 19:10:39 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 12 Jan 2022 19:10:39 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments In-Reply-To: References: Message-ID: <8eHO7cPNlW0d7YoYGnalQE7VXb6NlsbUXf7-FKuYD6Y=.2c19e744-ccc6-4a28-83b3-f182a08a86ac@github.com> On Wed, 12 Jan 2022 19:05:30 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java line 89: >> >>> 87: public static class OfByte extends HeapMemorySegmentImpl { >>> 88: >>> 89: OfByte(long offset, Object base, long length, int mask) { >> >> Is it possible to retain the array type for the constructor? > > yes, that should be harmless Actually, no, sorry. If I sharpen the type, then `dup` has to cast, so we go back to the original issue. ------------- PR: https://git.openjdk.java.net/jdk18/pull/97 From naoto at openjdk.java.net Wed Jan 12 19:21:32 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 12 Jan 2022 19:21:32 GMT Subject: Integrated: 8268081: Upgrade Unicode Data Files to 14.0.0 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. This pull request has now been integrated. Changeset: 0a094d7c Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/0a094d7c286ed0b5a35c517391e48c603cb43a68 Stats: 3443 lines in 41 files changed: 2353 ins; 101 del; 989 mod 8268081: Upgrade Unicode Data Files to 14.0.0 Reviewed-by: joehw, iris, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/6974 From rkennke at openjdk.java.net Wed Jan 12 19:46:39 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 12 Jan 2022 19:46:39 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue Message-ID: Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. Testing: - [x] tier1 - [x] tier2 - [x] tier3 ------------- Commit messages: - 8279917: Refactor subclassAudits in Thread to use ClassValue Changes: https://git.openjdk.java.net/jdk/pull/7054/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7054&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279917 Stats: 84 lines in 1 file changed: 1 ins; 76 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7054.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7054/head:pull/7054 PR: https://git.openjdk.java.net/jdk/pull/7054 From psandoz at openjdk.java.net Wed Jan 12 19:48:35 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 12 Jan 2022 19:48:35 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments In-Reply-To: <8eHO7cPNlW0d7YoYGnalQE7VXb6NlsbUXf7-FKuYD6Y=.2c19e744-ccc6-4a28-83b3-f182a08a86ac@github.com> References: <8eHO7cPNlW0d7YoYGnalQE7VXb6NlsbUXf7-FKuYD6Y=.2c19e744-ccc6-4a28-83b3-f182a08a86ac@github.com> Message-ID: On Wed, 12 Jan 2022 19:07:00 GMT, Maurizio Cimadamore wrote: >> yes, that should be harmless > > Actually, no, sorry. If I sharpen the type, then `dup` has to cast, so we go back to the original issue. Ah yes, i see. Maybe it's worth adding a general comment to the class doc of `HeapMemorySegmentImpl` briefly explaining the reasons for use of `Object`. ------------- PR: https://git.openjdk.java.net/jdk18/pull/97 From stevenschlansker at gmail.com Wed Jan 12 20:56:30 2022 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Wed, 12 Jan 2022 12:56:30 -0800 Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality Message-ID: Hi core-libs-dev, I am maintaining a module for the popular Jackson JSON library that attempts to simplify code-generation code without losing performance. Long ago, it was a huge win to code-generate custom getter / setter / field accessors rather than use core reflection. Now, the gap is closing a lot with MethodHandles, but there still seems to be some benefit. The previous approach used for code generation relied on the CGLib + ASM libraries, which as I am sure you know leads to horrible-to-maintain code since you essentially write bytecode directly. Feature development basically stopped because writing out long chains of `visitVarInsn(ASTORE, 3)` and the like scares off most contributors, myself included. As an experiment, I started to port the custom class generation logic to use LambdaMetafactory. The idea is to use the factory to generate `Function` getter and `BiConsumer` setter implementations. Then, use those during (de)serialization to access or set data. Eventually hopefully the JVM will inline, removing all (?) reflection overhead. The invocation looks like: var lookup = MethodHandles.privateLookupIn(targetClass, MethodHandles.lookup()); // allow non-public access var getter = lookup.unreflect(someGetterMethod); LambdaMetafactory.metafactory( lookup, "apply", methodType(Function.class), methodType(Object.class, Object.class), getter, getter.type()) This works well for classes from the same classloader. However, once you try to generate lambdas with implementations loaded from a different classloader, you run into a check in the AbstractValidatingLambdaMetafactory constructor: if (!caller.hasFullPrivilegeAccess()) { throw new LambdaConversionException(String.format( "Invalid caller: %s", caller.lookupClass().getName())); } The `privateLookupIn` call seems to drop MODULE privilege access when looking across ClassLoaders. This appears to be because the "unnamed module" differs between a ClassLoader and its child. This happens without the use of modulepath at all, only classpath, where I would not expect module restrictions to be in play. Through some experimentation, I discovered that while I cannot call the LambdaMetafactory with this less-privileged lookup, I am still allowed to call defineClass. So, I compile a simple class: package ; class AccessCracker { static final Lookup LOOKUP = MethodHandles.lookup(); } and inject it into the target class's existing package: lookup = lookup.defineClass(compiledBytes).getField("LOOKUP").get(null); and now I have a full privileged lookup into the target classloader, and the Metafactory then seems to generate lambdas without complaint. This workaround seems to work well, although it's a bummer to have to generate and inject these dynamic accessor classes. It feels inconsistent that on one hand my Lookup is not powerful enough to generate a simple call-site with the Metafactory, but at the same time it is so powerful that I can load arbitrary bytecode into the target classloader, and thus indirectly do what I wanted to do in the first place (with a fair bit more work) There's a bit of additional context here: https://github.com/FasterXML/jackson-modules-base/issues/138 https://github.com/FasterXML/jackson-modules-base/pull/162/files Any chance the Metafactory might become powerful enough to generate call sites even across such unnamed Modules in a future release? Or even more generally across arbitrary Modules, if relevant access checks pass? I'm also curious for any feedback on the overall approach of using the Metafactory, perhaps I am way off in the weeds, and should just trust MethodHandles to perform well if you use invokeExact :) JMH does seem to show some benefit though especially with Graal compiler. Thanks a bunch for any thoughts, Steven Schlansker From mullan at openjdk.java.net Wed Jan 12 22:04:55 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 12 Jan 2022 22:04:55 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs Message-ID: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. ------------- Commit messages: - Initial revision. Changes: https://git.openjdk.java.net/jdk/pull/7056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7056&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278851 Stats: 263 lines in 3 files changed: 213 ins; 20 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/7056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7056/head:pull/7056 PR: https://git.openjdk.java.net/jdk/pull/7056 From msheppar at openjdk.java.net Thu Jan 13 01:05:26 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 13 Jan 2022 01:05:26 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna wrote: >> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. >> >> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. > > Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: > > Allow the test to pass on MacOSX src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java line 54: > 52: * @param timeout the connection timeout > 53: */ > 54: public abstract PooledConnection createPooledConnection(PoolCallback pcb, long timeout) why not use int timeout to be consistent with existing code ? You've been required to "squash" it into an int in the factory ? ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From msheppar at openjdk.java.net Thu Jan 13 01:11:27 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 13 Jan 2022 01:11:27 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna wrote: >> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. >> >> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. > > Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: > > Allow the test to pass on MacOSX src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java line 70: > 68: public PooledConnection createPooledConnection(PoolCallback pcb, long timeout) > 69: throws NamingException { > 70: return new LdapClient(host, port, socketFactory, any need to perform sanity check against erroneous negative values on the timeout supplied here and in other parts of the solution ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From duke at openjdk.java.net Thu Jan 13 01:56:27 2022 From: duke at openjdk.java.net (duke) Date: Thu, 13 Jan 2022 01:56:27 GMT Subject: Withdrawn: 8277015: Use blessed modifier order in Panama code In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 14:50:43 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. > > In this case, while the script did into the "correct" thing, it turns out that the method signatures in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room for improvement... The files contains method headers which look like this: > > > final @Override > @ForceInline > long longToElementBits(... > > @ForceInline > static long toIntegralChecked(... > > @ForceInline > @Override final > ByteVector dummyVector(... > > > My personal opinion is that these should have been written like this: > > > @Override > @ForceInline > final long longToElementBits(... > > @ForceInline > static long toIntegralChecked(... > > @ForceInline > @Override > final ByteVector dummyVector(... > > > or possibly > > > > @Override @ForceInline > final long longToElementBits(... > > @ForceInline > static long toIntegralChecked(... > > @ForceInline @Override > final ByteVector dummyVector(... > > > If you want me to make that change as well as part of the fix, let me know. > > Furthermore, I don't know how much the code in mainline differs from the code in the Panama branches. If the discrepancy is large, you might want to run `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and `bash bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6355 From shade at openjdk.java.net Thu Jan 13 08:54:41 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 13 Jan 2022 08:54:41 GMT Subject: [jdk18] Integrated: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 In-Reply-To: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> References: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Message-ID: On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote: > Seems like a missing include. C++ docs say `offsetof` is from ``, adding that include explicitly fixes the build. Seems to only happen with older GCCs, but it seems to be a happy accident it works on newer ones, probably through the transitive include somewhere. > > Additional testing: > - [x] Linux x86_64 fastdebug `tools/jpackage` tests > - [x] Linux x86_64 release `tools/jpackage` tests This pull request has now been integrated. Changeset: 14a90e53 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk18/commit/14a90e536b86a8fb8d5f0272ec03359e44638da5 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 Reviewed-by: almatvee, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk18/pull/74 From shade at openjdk.java.net Thu Jan 13 08:54:41 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 13 Jan 2022 08:54:41 GMT Subject: [jdk18] RFR: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 In-Reply-To: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> References: <8WtsS6UNvKLHmYqEHHvy9tKVmZjZrsoTc6aiA4PvcA8=.c58268d9-2388-4fdb-ac77-af07accf9f25@github.com> Message-ID: On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote: > Seems like a missing include. C++ docs say `offsetof` is from ``, adding that include explicitly fixes the build. Seems to only happen with older GCCs, but it seems to be a happy accident it works on newer ones, probably through the transitive include somewhere. > > Additional testing: > - [x] Linux x86_64 fastdebug `tools/jpackage` tests > - [x] Linux x86_64 release `tools/jpackage` tests Thank you! ------------- PR: https://git.openjdk.java.net/jdk18/pull/74 From duke at openjdk.java.net Thu Jan 13 10:05:24 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Thu, 13 Jan 2022 10:05:24 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 19:39:29 GMT, Roman Kennke wrote: > Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 src/java.base/share/classes/java/lang/Thread.java line 1671: > 1669: /** cache of subclass security audit results */ > 1670: /* Replace with ConcurrentReferenceHashMap when/if it appears in a future > 1671: * release */ Is it still desirable to use `ConcurrentReferenceHashMap` as suggested in comment? Or ClassValue is better choice? ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From dfuchs at openjdk.java.net Thu Jan 13 10:12:27 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 13 Jan 2022 10:12:27 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 01:07:52 GMT, Mark Sheppard wrote: >> Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: >> >> Allow the test to pass on MacOSX > > src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java line 70: > >> 68: public PooledConnection createPooledConnection(PoolCallback pcb, long timeout) >> 69: throws NamingException { >> 70: return new LdapClient(host, port, socketFactory, > > any need to perform sanity check against erroneous negative values on the timeout supplied here and in other parts of the solution Hmmm... Good point. I had looked into this yesterday when I reviewed - and AFAIU a value <= 0 would be interpreted as no timeout (that is, infinite timeout) - and that seems consistent throughout. It's non obvious - but I convinced myself that passing a negative value here would not necessarily be an error, and would work as expected. However the narrowing down of a negative long to an int doesn't necessarily preserve the sign. @robm-openjdk the conversion from long to int probably needs to also take care of values that are < Integer.MIN_VALUE. jshell> long l = Integer.MIN_VALUE * 2L l ==> -4294967296 jshell> int x = (int)l x ==> 0 jshell> long l = Integer.MIN_VALUE * 2L + 1 l ==> -4294967295 jshell> int x = (int)l x ==> 1 ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From dfuchs at openjdk.java.net Thu Jan 13 10:15:34 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 13 Jan 2022 10:15:34 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 10:09:45 GMT, Daniel Fuchs wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java line 70: >> >>> 68: public PooledConnection createPooledConnection(PoolCallback pcb, long timeout) >>> 69: throws NamingException { >>> 70: return new LdapClient(host, port, socketFactory, >> >> any need to perform sanity check against erroneous negative values on the timeout supplied here and in other parts of the solution > > Hmmm... Good point. I had looked into this yesterday when I reviewed - and AFAIU a value <= 0 would be interpreted as no timeout (that is, infinite timeout) - and that seems consistent throughout. It's non obvious - but I convinced myself that passing a negative value here would not necessarily be an error, and would work as expected. However the narrowing down of a negative long to an int doesn't necessarily preserve the sign. > @robm-openjdk the conversion from long to int probably needs to also take care of values that are < Integer.MIN_VALUE. > > > jshell> long l = Integer.MIN_VALUE * 2L > l ==> -4294967296 > > jshell> int x = (int)l > x ==> 0 > > jshell> long l = Integer.MIN_VALUE * 2L + 1 > l ==> -4294967295 > > jshell> int x = (int)l > x ==> 1 (Though I don't think it can happen - but maybe I'm mistaken) In any case it's safer to sanitize the input. ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From prappo at openjdk.java.net Thu Jan 13 10:35:39 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 10:35:39 GMT Subject: RFR: 8279918: Fix various doc typos Message-ID: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> - Most of the typos are of a trivial kind: missing whitespace. - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. - ' is an apostrophe, which does not require to be encoded. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/7063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279918 Stats: 85 lines in 34 files changed: 0 ins; 0 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/7063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063 PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 10:49:28 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 10:49:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - ' is an apostrophe, which does not require to be encoded. src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: > 71: * will be transparent to the BreakIterator.  A sequence of characters will break the > 72: * same way it would if any ignore characters it contains are taken out.  Break > 73: * positions never occur before ignore characters.

"before ignored characters" ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 11:04:28 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 11:04:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com> On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - ' is an apostrophe, which does not require to be encoded. > > src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: > >> 71: * will be transparent to the BreakIterator.  A sequence of characters will break the >> 72: * same way it would if any ignore characters it contains are taken out.  Break >> 73: * positions never occur before ignore characters.

> > "before ignored characters" I believe it's the name of a concept, so I will leave it as is: > There is one special substitution. If the description defines a substitution called "", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:04:28 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:04:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - ' is an apostrophe, which does not require to be encoded. src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58: > 56: * A JDBC driver implementation should use > 57: * the constructor {@code BatchUpdateException(String reason, String SQLState, > 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type. Similarly at line 81, 118, 151, 247, 277, 318, 354. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 11:07:28 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 11:07:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - ' is an apostrophe, which does not require to be encoded. > > src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58: > >> 56: * A JDBC driver implementation should use >> 57: * the constructor {@code BatchUpdateException(String reason, String SQLState, >> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of > > While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type. > Similarly at line 81, 118, 151, 247, 277, 318, 354. I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:21:27 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:21:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. src/java.sql/share/classes/java/sql/Statement.java line 784: > 782: * statement returns a {@code ResultSet} object, the second argument > 783: * supplied to this method is not an > 784: * {@code int} array whose elements are valid column indexes, the method is called on a Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:33:27 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:33:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From kevinw at openjdk.java.net Thu Jan 13 11:33:27 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 13 Jan 2022 11:33:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:04:43 GMT, Pavel Rappo wrote: >> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58: >> >>> 56: * A JDBC driver implementation should use >>> 57: * the constructor {@code BatchUpdateException(String reason, String SQLState, >>> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of >> >> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type. >> Similarly at line 81, 118, 151, 247, 277, 318, 354. > > I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code. OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare. I'll leave it up to you. 8-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 11:33:28 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 11:33:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > src/java.sql/share/classes/java/sql/Statement.java line 784: > >> 782: * statement returns a {@code ResultSet} object, the second argument >> 783: * supplied to this method is not an >> 784: * {@code int} array whose elements are valid column indexes, the method is called on a > > Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course. You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 11:46:27 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 11:46:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. Overall this looks good, thanks for the clean up :-) A few comments below src/java.base/share/classes/java/io/DataInput.java line 496: > 494: * ceases. If the character {@code '\r'} > 495: * is encountered, it is discarded and, if > 496: * the following byte converts to the The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 11:46:27 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 11:46:27 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:28:34 GMT, Kevin Walls wrote: >> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code. > > OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare. > I'll leave it up to you. 8-) I think that can be a follow on clean up. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 11:46:28 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 11:46:28 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> Message-ID: On Thu, 13 Jan 2022 11:29:35 GMT, Pavel Rappo wrote: >> src/java.sql/share/classes/java/sql/Statement.java line 784: >> >>> 782: * statement returns a {@code ResultSet} object, the second argument >>> 783: * supplied to this method is not an >>> 784: * {@code int} array whose elements are valid column indexes, the method is called on a >> >> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course. > > You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory. Yes an "or" is probably worthwhile to add. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From rkennke at openjdk.java.net Thu Jan 13 12:19:03 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 13 Jan 2022 12:19:03 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: References: Message-ID: > Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Remove obsolete comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7054/files - new: https://git.openjdk.java.net/jdk/pull/7054/files/0e495c4f..958e4e84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7054&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7054&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7054.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7054/head:pull/7054 PR: https://git.openjdk.java.net/jdk/pull/7054 From mcimadamore at openjdk.java.net Thu Jan 13 12:26:17 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 13 Jan 2022 12:26:17 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments [v2] In-Reply-To: References: Message-ID: > When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add toplevel javadoc rationale in HeapMemorySegmentImpl ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/97/files - new: https://git.openjdk.java.net/jdk18/pull/97/files/9ef83f53..af8fb319 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=97&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=97&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk18/pull/97.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/97/head:pull/97 PR: https://git.openjdk.java.net/jdk18/pull/97 From rkennke at openjdk.java.net Thu Jan 13 12:27:31 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 13 Jan 2022 12:27:31 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 10:02:04 GMT, Andrey Turbanov wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove obsolete comment > > src/java.base/share/classes/java/lang/Thread.java line 1671: > >> 1669: /** cache of subclass security audit results */ >> 1670: /* Replace with ConcurrentReferenceHashMap when/if it appears in a future >> 1671: * release */ > > Is it still desirable to use `ConcurrentReferenceHashMap` as suggested in comment? Or ClassValue is better choice? Hmm, no. The use of Reference here is to avoid strong binding to the Class key. However, we have seen weird interferences in ObjectStreamClass (see JDK-8277072) between this mechanism and class-unloading which prevents unloading the class sometimes (or at least, absent memory pressure that would trigger the GC to reclaim soft references). This code here in Thread.java is probably not affected by this problem, but ClassValue is still the cleaner way to establish a mapping between a Class and some value. I have removed the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From prappo at openjdk.java.net Thu Jan 13 12:40:45 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 12:40:45 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen wrote: > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later. Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From coffeys at openjdk.java.net Thu Jan 13 12:47:27 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 13 Jan 2022 12:47:27 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. > > This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. > > An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 212: > 210: > 211: CodeSigner[] entrySigners = sigFileSigners.get(name); > 212: Map permittedAlgs = maybe permittedAlgsChecker as variable name ? the Map contains both permitted and non-permitted algs. src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 239: > 237: > 238: // A non-disabled algorithm was used. > 239: disabledAlgs = false; this usage doesn't seem right. I think it's always set to false no matter what algs are detected. ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From mullan at openjdk.java.net Thu Jan 13 13:45:30 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 13 Jan 2022 13:45:30 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. The change in the one security class (KeyStoreLoginModule) looks fine. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Thu Jan 13 13:51:34 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 13:51:34 GMT Subject: RFR: 8279918: Fix various doc typos In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> Message-ID: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com> On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen wrote: > Yes an "or" is probably worthwhile to add. I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql: * java/sql/Statement.java:59 * java/sql/Statement.java:85 * java/sql/Statement.java:346 * java/sql/Statement.java:524 * java/sql/Statement.java:745 * java/sql/Statement.java:814 * java/sql/Statement.java:860 * java/sql/Statement.java:913 * java/sql/Statement.java:962 * java/sql/Statement.java:1225 * java/sql/Statement.java:1269 * java/sql/Statement.java:1314 ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From redestad at openjdk.java.net Thu Jan 13 13:59:05 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 13 Jan 2022 13:59:05 GMT Subject: [jdk18] RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 Message-ID: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 ------------- Commit messages: - 8279833: Loop optimization issue in String.encodeUTF8_UTF16 Changes: https://git.openjdk.java.net/jdk18/pull/99/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=99&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279833 Stats: 88 lines in 2 files changed: 45 ins; 4 del; 39 mod Patch: https://git.openjdk.java.net/jdk18/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/99/head:pull/99 PR: https://git.openjdk.java.net/jdk18/pull/99 From mullan at openjdk.java.net Thu Jan 13 13:59:30 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 13 Jan 2022 13:59:30 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs In-Reply-To: References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: On Thu, 13 Jan 2022 12:33:53 GMT, Sean Coffey wrote: >> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. >> >> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. >> >> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. > > src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 212: > >> 210: >> 211: CodeSigner[] entrySigners = sigFileSigners.get(name); >> 212: Map permittedAlgs = > > maybe permittedAlgsChecker as variable name ? the Map contains both permitted and non-permitted algs. `Checker` sounds like it going to do something. But I agree the name could be better. I was mostly being consistent with the `permittedAlgs` variable in `SignatureFileVerifier`. Maybe `algsPermittedStatus`? > src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 239: > >> 237: >> 238: // A non-disabled algorithm was used. >> 239: disabledAlgs = false; > > this usage doesn't seem right. I think it's always set to false no matter what algs are detected. If all algs are disabled, it will never get here, because it will either continue on line 231 or 234. ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From prappo at openjdk.java.net Thu Jan 13 14:01:04 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 13 Jan 2022 14:01:04 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Additional typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7063/files - new: https://git.openjdk.java.net/jdk/pull/7063/files/fe81eeca..b256a13f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063 PR: https://git.openjdk.java.net/jdk/pull/7063 From rriggs at openjdk.java.net Thu Jan 13 14:45:26 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 13 Jan 2022 14:45:26 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: References: Message-ID: <8JiN0kBi4PrpRcQ6TvVun6_JwjfIjR1B1P78T-eSk78=.f44f3a5b-8e11-4d19-8703-7aaa021fc8d8@github.com> On Thu, 13 Jan 2022 12:19:03 GMT, Roman Kennke wrote: >> Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete comment @AlanBateman has been doing a lot of work with j.l.Thread and Loom but may not get to review this til next week. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From rriggs at openjdk.java.net Thu Jan 13 15:00:38 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 13 Jan 2022 15:00:38 GMT Subject: [jdk18] RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 13:46:53 GMT, Claes Redestad wrote: > 8279833: Loop optimization issue in String.encodeUTF8_UTF16 LGTM (This a backport but is using the mainline bug number; already resolved). ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/99 From forax at univ-mlv.fr Thu Jan 13 15:05:03 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Jan 2022 16:05:03 +0100 (CET) Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality In-Reply-To: References: Message-ID: <30441222.11446506.1642086303584.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Steven Schlansker" > To: "core-libs-dev" > Sent: Wednesday, January 12, 2022 9:56:30 PM > Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality > Hi core-libs-dev, > > I am maintaining a module for the popular Jackson JSON library that attempts to > simplify code-generation code without losing performance. > Long ago, it was a huge win to code-generate custom getter / setter / field > accessors rather than use core reflection. Now, the gap is closing a lot with > MethodHandles, but there still seems to be some benefit. > > The previous approach used for code generation relied on the CGLib + ASM > libraries, which as I am sure you know leads to horrible-to-maintain code since > you essentially write bytecode directly. I don't see the issue here, writing bytecodes in not that hard :) > Feature development basically stopped because writing out long chains of > `visitVarInsn(ASTORE, 3)` and the like scares off most contributors, myself > included. yes, sadly known issue, generating assembly code even a highlevel one like the Java byetcode by hands require a niche knowledge which sadly is rarely teached at university anymore (and let's not talked about bootcamp). > > As an experiment, I started to port the custom class generation logic to use > LambdaMetafactory. The idea is to use the factory to generate `Function T>` getter and `BiConsumer` setter implementations. If you want to make the serailization/deserialization to JSON fast you will mostly battle two things, - polymorphic call site, a call that can call some many different implementations that the VM will not try to inline, usually the trick is to just have one of such call to take care of the different kind of objects. - boxing, that kind of code tends to abstract over any values, but boxing means allocation if there is no inlining. For me, it means that you want two specialized codes, the decoder that switches over the keys and call the correct setter and the encoder that calls the getters in sequence. Trying to abstract over getters and setters is a step too far because you loose the benefit to write a code specific to a peculiar class. I suppose you try to use the method handles directly with invokeExact() if you are able to remove the boxing or with invoke() if not ? Because it's not clear to me why you want to use the LambdaMetafactory ? [...] > > I'm also curious for any feedback on the overall approach of using the > Metafactory, perhaps I am way off in the weeds, and should just trust > MethodHandles to perform well if you use invokeExact :) JMH does seem to show > some benefit though especially with Graal compiler. > > Thanks a bunch for any thoughts, > Steven Schlansker R?mi From redestad at openjdk.java.net Thu Jan 13 15:09:37 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 13 Jan 2022 15:09:37 GMT Subject: [jdk18] RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 In-Reply-To: References: Message-ID: <6Gd8LhYEGEemHq8UAR6uMo-O-sKDqZHajYMTTkOw3TI=.7afffa8b-4af9-4b21-9028-8071f9b32ebb@github.com> On Thu, 13 Jan 2022 14:56:50 GMT, Roger Riggs wrote: > LGTM Thanks! > (This a backport but is using the mainline bug number; already resolved). I think that's intentional? I entered "Backport COMMITHASH" as the PR subject as per instructions and the bots have taken things from there. ------------- PR: https://git.openjdk.java.net/jdk18/pull/99 From kcr at openjdk.java.net Thu Jan 13 15:18:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 15:18:34 GMT Subject: [jdk18] RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 In-Reply-To: <6Gd8LhYEGEemHq8UAR6uMo-O-sKDqZHajYMTTkOw3TI=.7afffa8b-4af9-4b21-9028-8071f9b32ebb@github.com> References: <6Gd8LhYEGEemHq8UAR6uMo-O-sKDqZHajYMTTkOw3TI=.7afffa8b-4af9-4b21-9028-8071f9b32ebb@github.com> Message-ID: On Thu, 13 Jan 2022 15:05:42 GMT, Claes Redestad wrote: > > (This a backport but is using the mainline bug number; already resolved). > > I think that's intentional? I entered "Backport COMMITHASH" as the PR subject as per instructions and the bots have taken things from there. Yes, it's both intentional and necessary. We only use the JBS bug ID of the main bug, and never the JBS ID of the backport record (presuming the latter is even created ahead of time, which it usually isn't) in pull requests, commit messages, etc. ------------- PR: https://git.openjdk.java.net/jdk18/pull/99 From redestad at openjdk.java.net Thu Jan 13 15:28:43 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 13 Jan 2022 15:28:43 GMT Subject: [jdk18] RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 In-Reply-To: References: <6Gd8LhYEGEemHq8UAR6uMo-O-sKDqZHajYMTTkOw3TI=.7afffa8b-4af9-4b21-9028-8071f9b32ebb@github.com> Message-ID: On Thu, 13 Jan 2022 15:14:05 GMT, Kevin Rushforth wrote: >>> LGTM >> >> Thanks! >> >>> (This a backport but is using the mainline bug number; already resolved). >> >> I think that's intentional? I entered "Backport COMMITHASH" as the PR subject as per instructions and the bots have taken things from there. > >> > (This a backport but is using the mainline bug number; already resolved). >> >> I think that's intentional? I entered "Backport COMMITHASH" as the PR subject as per instructions and the bots have taken things from there. > > Yes, it's both intentional and necessary. We only use the JBS bug ID of the main bug, and never the JBS ID of the backport record (presuming the latter is even created ahead of time, which it usually isn't) in pull requests, commit messages, etc. Thanks for confirming, @kevinrushforth ???? While creating the backport bug manually isn't strictly necessary, the bots seem to do the right thing if it exists, so I've taken up the (bad?) habit of creating it manually to keep a tab on my current tasks and intents. ------------- PR: https://git.openjdk.java.net/jdk18/pull/99 From redestad at openjdk.java.net Thu Jan 13 15:28:44 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 13 Jan 2022 15:28:44 GMT Subject: [jdk18] Integrated: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 13:46:53 GMT, Claes Redestad wrote: > 8279833: Loop optimization issue in String.encodeUTF8_UTF16 This pull request has now been integrated. Changeset: ff856593 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk18/commit/ff8565931115d581afff679ea85b1a2d80c03b99 Stats: 88 lines in 2 files changed: 45 ins; 4 del; 39 mod 8279833: Loop optimization issue in String.encodeUTF8_UTF16 Reviewed-by: rriggs Backport-of: c3d0a94040d9bd0f4b99da97b89fbfce252a41c0 ------------- PR: https://git.openjdk.java.net/jdk18/pull/99 From coffeys at openjdk.java.net Thu Jan 13 15:31:29 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 13 Jan 2022 15:31:29 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. > > This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. > > An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From coffeys at openjdk.java.net Thu Jan 13 15:31:29 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 13 Jan 2022 15:31:29 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs In-Reply-To: References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: On Thu, 13 Jan 2022 13:56:14 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 212: >> >>> 210: >>> 211: CodeSigner[] entrySigners = sigFileSigners.get(name); >>> 212: Map permittedAlgs = >> >> maybe permittedAlgsChecker as variable name ? the Map contains both permitted and non-permitted algs. > > `Checker` sounds like it going to do something. But I agree the name could be better. I was mostly being consistent with the `permittedAlgs` variable in `SignatureFileVerifier`. Maybe `algsPermittedStatus`? yes, algsPermittedStatus sounds better. Thanks. >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 239: >> >>> 237: >>> 238: // A non-disabled algorithm was used. >>> 239: disabledAlgs = false; >> >> this usage doesn't seem right. I think it's always set to false no matter what algs are detected. > > If all algs are disabled, it will never get here, because it will either continue on line 231 or 234. Ah yes - I was reading the scope of for loop incorrectly. Thanks for clarifying! ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From psandoz at openjdk.java.net Thu Jan 13 16:16:39 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 13 Jan 2022 16:16:39 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments [v2] In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 12:26:17 GMT, Maurizio Cimadamore wrote: >> When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add toplevel javadoc rationale in HeapMemorySegmentImpl Marked as reviewed by psandoz (Reviewer). test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverSlice.java line 71: > 69: scope = ResourceScope.newConfinedScope(); > 70: nativeSegment = MemorySegment.allocateNative(ALLOC_SIZE, scope); > 71: heapSegment = MemorySegment.ofArray(new float[ELEM_SIZE]); The heap `MemorySegment` wraps `float[]` but is accessed as if `int[]`, same bit size, but I suspect it was not intentional? ------------- PR: https://git.openjdk.java.net/jdk18/pull/97 From sspitsyn at openjdk.java.net Thu Jan 13 16:53:27 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 13 Jan 2022 16:53:27 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Hi Pavel, Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From weijun at openjdk.java.net Thu Jan 13 16:58:27 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 13 Jan 2022 16:58:27 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. > > This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. > > An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 211: > 209: } > 210: > 211: CodeSigner[] entrySigners = sigFileSigners.get(name); What if we return here if `entrySigners == null`? It seems the hash comparison will be skipped, but at the end there is no difference in `verifiedSigners`. src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 230: > 228: params = new JarConstraintsParameters(entrySigners); > 229: } > 230: if (!checkConstraints(digestAlg, permittedAlgs, params)) { Can we move the `permittedAlgs::put` call from inside the `checkConstraints` method to here? You can even call `computeIfAbsent` to make the intention clearer. src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 272: > 270: } > 271: > 272: // Gets the permitted algs for the signers of this entry. This can probably be another `computeIfAbsent`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From lancea at openjdk.java.net Thu Jan 13 17:18:23 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 17:18:23 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 12:37:46 GMT, Pavel Rappo wrote: > > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later. > > Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up. Yes I am. It just does not flow as well as it could IMHO ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From naoto at openjdk.java.net Thu Jan 13 17:25:31 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 Jan 2022 17:25:31 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com> Message-ID: <4-d5YVHaRmPcyMlFYm2fxtIaRq6Z5PVooC8yd0OIbag=.cbd015b1-b2bd-43ba-b12f-8727087364b5@github.com> On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73: >> >>> 71: * will be transparent to the BreakIterator.  A sequence of characters will break the >>> 72: * same way it would if any ignore characters it contains are taken out.  Break >>> 73: * positions never occur before ignore characters.

>> >> "before ignored characters" > > I believe it's the name of a concept, so I will leave it as is: > >> There is one special substitution. If the description defines a substitution called "", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator. Yes, that is correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From naoto at openjdk.java.net Thu Jan 13 17:25:30 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 Jan 2022 17:25:30 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 17:25:31 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 17:25:31 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com> <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com> Message-ID: <-4rLp_8_PwigKKpD1gGONCS8QMfDkNNNP4uZU1k9u9M=.9119e3bf-b879-42eb-a3a7-af6442a0551e@github.com> On Thu, 13 Jan 2022 13:48:02 GMT, Pavel Rappo wrote: > > Yes an "or" is probably worthwhile to add. > > I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql: > > * java/sql/Statement.java:59 > * java/sql/Statement.java:85 > * java/sql/Statement.java:346 > * java/sql/Statement.java:524 > * java/sql/Statement.java:745 > * java/sql/Statement.java:814 > * java/sql/Statement.java:860 > * java/sql/Statement.java:913 > * java/sql/Statement.java:962 > * java/sql/Statement.java:1225 > * java/sql/Statement.java:1269 > * java/sql/Statement.java:1314 I am fine with that. I guess a semi-colon could also be used vs. a comma to divide the Exception scenarios listed ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From lancea at openjdk.java.net Thu Jan 13 17:35:25 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 17:35:25 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From mcimadamore at openjdk.java.net Thu Jan 13 18:32:20 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 13 Jan 2022 18:32:20 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments [v3] In-Reply-To: References: Message-ID: <_rz9lGeB5Xafb9k-degUIaRE3-djbghXtCGiqK2XhnY=.ca6cfe5c-5ae8-4567-b79c-32095251bb6f@github.com> > When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix and enhance benchmark ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/97/files - new: https://git.openjdk.java.net/jdk18/pull/97/files/af8fb319..712f9fb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=97&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=97&range=01-02 Stats: 114 lines in 1 file changed: 96 ins; 9 del; 9 mod Patch: https://git.openjdk.java.net/jdk18/pull/97.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/97/head:pull/97 PR: https://git.openjdk.java.net/jdk18/pull/97 From psandoz at openjdk.java.net Thu Jan 13 18:39:28 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 13 Jan 2022 18:39:28 GMT Subject: [jdk18] RFR: 8279930: Synthetic cast causes generation of store barriers when using heap segments [v3] In-Reply-To: <_rz9lGeB5Xafb9k-degUIaRE3-djbghXtCGiqK2XhnY=.ca6cfe5c-5ae8-4567-b79c-32095251bb6f@github.com> References: <_rz9lGeB5Xafb9k-degUIaRE3-djbghXtCGiqK2XhnY=.ca6cfe5c-5ae8-4567-b79c-32095251bb6f@github.com> Message-ID: On Thu, 13 Jan 2022 18:32:20 GMT, Maurizio Cimadamore wrote: >> When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix and enhance benchmark Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/97 From mullan at openjdk.java.net Thu Jan 13 20:03:25 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 13 Jan 2022 20:03:25 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs In-Reply-To: References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: On Thu, 13 Jan 2022 16:55:08 GMT, Weijun Wang wrote: >> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. >> >> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. >> >> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. > > src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 211: > >> 209: } >> 210: >> 211: CodeSigner[] entrySigners = sigFileSigners.get(name); > > What if we return here if `entrySigners == null`? It seems the hash comparison will be skipped, but at the end there is no difference in `verifiedSigners`. The algorithm constraints check will be skipped (because `permittedAlgs` will be `null`) but the hash check will not be skipped. I don't think `null` would be returned in a normal case. The only case I can think of is if there was an entry in the Manifest, but no corresponding entry in the SF file. I suppose we could still do a constraints check as if there were no signers. However, it doesn't seem that useful since technically the entry is not protected by the signature and the hash check is still done, unless I am missing something. > src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 230: > >> 228: params = new JarConstraintsParameters(entrySigners); >> 229: } >> 230: if (!checkConstraints(digestAlg, permittedAlgs, params)) { > > Can we move the `permittedAlgs::put` call from inside the `checkConstraints` method to here? You can even call `computeIfAbsent` to make the intention clearer. Yes, I can do that. However, I'm a bit wary of using lambdas in this code which may get exercised early in app startup. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From duke at openjdk.java.net Thu Jan 13 21:06:31 2022 From: duke at openjdk.java.net (duke) Date: Thu, 13 Jan 2022 21:06:31 GMT Subject: Withdrawn: JDK-8276939: Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException In-Reply-To: References: Message-ID: On Sun, 24 Oct 2021 16:27:02 GMT, andrewluotechnologies wrote: > `AbstractLdapNamingEnumeration` `next` throws `NullPointerException` instead of `NoSuchElementException`, however the javadoc for `NamingEnumeration` says that next should throw `NoSuchElementException` when no elements are available (https://docs.oracle.com/en/java/javase/17/docs/api/java.naming/javax/naming/NamingEnumeration.html#next()) > > The bug is basically that `next()` calls `hasMore()` -> `hasMoreImpl()` which calls `cleanup()` when there are no more elements. `cleanup()` sets `homeCtx = null;` which causes NullPointerException to be thrown on this line in `getNextBatch()`: `res = homeCtx.getSearchReply(enumClnt, res);` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6095 From jwilhelm at openjdk.java.net Thu Jan 13 21:06:07 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 13 Jan 2022 21:06:07 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18 - 8279833: Loop optimization issue in String.encodeUTF8_UTF16 - 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 - 8274007: [REDO] VM Exit does not abort concurrent mark - 8279837: C2: assert(is_Loop()) failed: invalid node class: Region The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7068&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7068&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7068/files Stats: 124 lines in 6 files changed: 117 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7068/head:pull/7068 PR: https://git.openjdk.java.net/jdk/pull/7068 From mullan at openjdk.java.net Thu Jan 13 21:57:57 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 13 Jan 2022 21:57:57 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2] In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com> > If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. > > This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. > > An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Change permittedAlgs variable name. Move put methods out of checkConstraints(). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7056/files - new: https://git.openjdk.java.net/jdk/pull/7056/files/056bcff2..b551c2b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7056&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7056&range=00-01 Stats: 13 lines in 1 file changed: 3 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7056/head:pull/7056 PR: https://git.openjdk.java.net/jdk/pull/7056 From weijun at openjdk.java.net Thu Jan 13 21:57:59 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 13 Jan 2022 21:57:59 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2] In-Reply-To: References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: <2kBoENEx_JzUsnIL-f5vYIT6PpK11powOukSPBMWNYo=.8a576051-bd65-495f-bf98-10dbfc10e272@github.com> On Thu, 13 Jan 2022 19:54:44 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 211: >> >>> 209: } >>> 210: >>> 211: CodeSigner[] entrySigners = sigFileSigners.get(name); >> >> What if we return here if `entrySigners == null`? It seems the hash comparison will be skipped, but at the end there is no difference in `verifiedSigners`. > > The algorithm constraints check will be skipped (because `permittedAlgs` will be `null`) but the hash check will not be skipped. > > I don't think `null` would be returned in a normal case. The only case I can think of is if there was an entry in the Manifest, but no corresponding entry in the SF file. I suppose we could still do a constraints check as if there were no signers. However, it doesn't seem that useful since technically the entry is not protected by the signature and the hash check is still done, unless I am missing something. Or maybe the key/signature algorithm is weak and ignored. I was only thinking it's not worth calculating the hash anymore. Of course there will be a behavior change. If there's a hash mismatch, it used to be a security exception, but if ignored, it's just a plain unsigned entry. >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 230: >> >>> 228: params = new JarConstraintsParameters(entrySigners); >>> 229: } >>> 230: if (!checkConstraints(digestAlg, permittedAlgs, params)) { >> >> Can we move the `permittedAlgs::put` call from inside the `checkConstraints` method to here? You can even call `computeIfAbsent` to make the intention clearer. > > Yes, I can do that. However, I'm a bit wary of using lambdas in this code which may get exercised early in app startup. WDYT? Maybe, I don't know how problematic if lambda is used this early. Anyway, I still prefer moving the update of `permittedAlgs` here. Updating it inside the method seems too faraway. ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From naoto at openjdk.java.net Thu Jan 13 22:03:01 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 Jan 2022 22:03:01 GMT Subject: [jdk18] RFR: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java Message-ID: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java ------------- Commit messages: - Backport 8dc4437d002db5d025b47f48e7420e3bae55bdec Changes: https://git.openjdk.java.net/jdk18/pull/100/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278434 Stats: 73 lines in 3 files changed: 59 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk18/pull/100.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/100/head:pull/100 PR: https://git.openjdk.java.net/jdk18/pull/100 From naoto at openjdk.java.net Thu Jan 13 22:09:34 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 Jan 2022 22:09:34 GMT Subject: [jdk18] Integrated: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 21:52:59 GMT, Naoto Sato wrote: > 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java This pull request has now been integrated. Changeset: 064ee6ae Author: Naoto Sato URL: https://git.openjdk.java.net/jdk18/commit/064ee6ae135366d59e9485b449a41d2b55811bbe Stats: 73 lines in 3 files changed: 59 ins; 7 del; 7 mod 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java Backport-of: 8dc4437d002db5d025b47f48e7420e3bae55bdec ------------- PR: https://git.openjdk.java.net/jdk18/pull/100 From mullan at openjdk.java.net Thu Jan 13 22:18:29 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 13 Jan 2022 22:18:29 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2] In-Reply-To: <2kBoENEx_JzUsnIL-f5vYIT6PpK11powOukSPBMWNYo=.8a576051-bd65-495f-bf98-10dbfc10e272@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> <2kBoENEx_JzUsnIL-f5vYIT6PpK11powOukSPBMWNYo=.8a576051-bd65-495f-bf98-10dbfc10e272@github.com> Message-ID: On Thu, 13 Jan 2022 21:54:17 GMT, Weijun Wang wrote: >> The algorithm constraints check will be skipped (because `permittedAlgs` will be `null`) but the hash check will not be skipped. >> >> I don't think `null` would be returned in a normal case. The only case I can think of is if there was an entry in the Manifest, but no corresponding entry in the SF file. I suppose we could still do a constraints check as if there were no signers. However, it doesn't seem that useful since technically the entry is not protected by the signature and the hash check is still done, unless I am missing something. > > Or maybe the key/signature algorithm is weak and ignored. I was only thinking it's not worth calculating the hash anymore. Of course there will be a behavior change. If there's a hash mismatch, it used to be a security exception, but if ignored, it's just a plain unsigned entry. It will never get here if all of the signers are using disabled algorithms (or for some other reason cannot be parsed/verified) as `JarVerifier.nothingToVerify()` will return true. But I think it's possible if one of the signers is ok. But I'd prefer not to make that change because of the change in behavior. And I think in most cases, JARs will have a single signer. >> Yes, I can do that. However, I'm a bit wary of using lambdas in this code which may get exercised early in app startup. WDYT? > > Maybe, I don't know how problematic if lambda is used this early. > > Anyway, I still prefer moving the update of `permittedAlgs` here. Updating it inside the method seems too faraway. Changed as suggested in latest revision. ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From kcr at openjdk.java.net Thu Jan 13 22:30:32 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 22:30:32 GMT Subject: [jdk18] RFR: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 In-Reply-To: References: <6Gd8LhYEGEemHq8UAR6uMo-O-sKDqZHajYMTTkOw3TI=.7afffa8b-4af9-4b21-9028-8071f9b32ebb@github.com> Message-ID: On Thu, 13 Jan 2022 15:23:25 GMT, Claes Redestad wrote: > I've taken up the (bad?) habit of creating it manually to keep a tab on my current tasks and intents. I do that too in some cases, and for the same reason. The only potential downside is if you create a concrete version for a specific update release and it misses that one and hits the next one, but for that case you can use `NN-pool` as the fixversion on the backport (and Skara will do the right thing). ------------- PR: https://git.openjdk.java.net/jdk18/pull/99 From weijun at openjdk.java.net Thu Jan 13 22:56:26 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 13 Jan 2022 22:56:26 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2] In-Reply-To: <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com> Message-ID: On Thu, 13 Jan 2022 21:57:57 GMT, Sean Mullan wrote: >> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. >> >> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. >> >> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Change permittedAlgs variable name. > Move put methods out of checkConstraints(). No more comment. Approved. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7056 From jjg at openjdk.java.net Thu Jan 13 23:01:28 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 13 Jan 2022 23:01:28 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com> Message-ID: On Thu, 13 Jan 2022 11:40:20 GMT, Lance Andersen wrote: >> OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare. >> I'll leave it up to you. 8-) > > I think that can be a follow on clean up. The strange formatting of `long []updateCounts` looks very unusual and well worth a followup cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From duke at openjdk.java.net Fri Jan 14 05:45:29 2022 From: duke at openjdk.java.net (liach) Date: Fri, 14 Jan 2022 05:45:29 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v2] In-Reply-To: References: Message-ID: <0oqsPdEVzY8P6ORp1fx_UZdi5lw2jEfWXqcNoz9M1H4=.d93eaccc-466a-466a-9eae-ee0783f68c9a@github.com> On Thu, 16 Dec 2021 20:48:39 GMT, liach wrote: >> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. > > liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default > - update dates > - Also test cme for identity hash map > - Fix putIfAbsent > - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap Patch still active. ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From duke at openjdk.java.net Fri Jan 14 09:18:28 2022 From: duke at openjdk.java.net (kabutz) Date: Fri, 14 Jan 2022 09:18:28 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 21:54:43 GMT, Paul Sandoz wrote: >>> > embarrassingly parallelizable >>> >>> Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that. >> >> I ran fibonacci(100_000_000) with multiply() and parallelMultiply(). For multiply() we had: >> >> >> real 0m25.627s >> user 0m26.767s >> sys 0m1.197s >> >> >> and for parallelMultiply() we had >> >> >> real 0m10.030s >> user 1m2.205s >> sys 0m2.489s >> >> >> Thus we are 2.5 times faster on a 1-6-2 machine, but use more than 2x the user time. If it were perfectly parallel, shouldn't we expect to see the parallelMultiply() be close to user time of 26s and real time 4.3s? > >> > embarrassingly parallelizable >> >> Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that. > > Ok, fair point, to avoid possible confusion I have removed "embarrassingly". I don't think we need to refer to other algorithms. Hi @PaulSandoz is there anything else that we need to do? Or is this in the hopper for Java 19 already? ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From myano at openjdk.java.net Fri Jan 14 11:05:09 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 14 Jan 2022 11:05:09 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v2] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 16:09:59 GMT, Lance Andersen wrote: >> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > Thank you for your work here. Have you also run your test using Apache Commons? > > I have run this test over 2000 times via Mach5 on various hardware with some runs taking over 12 minutes for the test to complete. So unless you can refactor the test to be more efficient, we need to make the test a manual test as this is more of a corner case. > > Please see the additional comments below @LanceAndersen Thank you for your detailed comments. I converted the test to use TestNG as you pointed out. Could you please review it again? ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From myano at openjdk.java.net Fri Jan 14 11:05:06 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 14 Jan 2022 11:05:06 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v3] In-Reply-To: References: Message-ID: > Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. > In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8272746: ZipFile can't open big file (NegativeArraySizeException) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6927/files - new: https://git.openjdk.java.net/jdk/pull/6927/files/c54c50eb..621f1a68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=01-02 Stats: 33 lines in 1 file changed: 10 ins; 9 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927 From michaelm at openjdk.java.net Fri Jan 14 11:09:46 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 14 Jan 2022 11:09:46 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Message-ID: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Hi, This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. A test will be added separately to the implementation. Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 Thanks, Michael ------------- Commit messages: - cleanup but still no test. Will be added in closed repo - First version of fix. No test and feature enabled always. Changes: https://git.openjdk.java.net/jdk/pull/7065/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279842 Stats: 149 lines in 7 files changed: 143 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 14 11:09:46 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 11:09:46 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180: > 178: static String normalizeCBT(String s) { > 179: if (s == null || ! (s.equals("always") || > 180: s.equals("never") || s.startsWith("domain:"))) { I guess there's a `!` missing in front of `s.startsWith("domain:")` here? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 14 11:09:46 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 14 Jan 2022 11:09:46 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 18:18:24 GMT, Daniel Fuchs wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180: > >> 178: static String normalizeCBT(String s) { >> 179: if (s == null || ! (s.equals("always") || >> 180: s.equals("never") || s.startsWith("domain:"))) { > > I guess there's a `!` missing in front of `s.startsWith("domain:")` here? This is what was intended (equivalent) `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 14 11:09:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 11:09:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> On Fri, 14 Jan 2022 10:03:37 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 180: >> >>> 178: static String normalizeCBT(String s) { >>> 179: if (s == null || ! (s.equals("always") || >>> 180: s.equals("never") || s.startsWith("domain:"))) { >> >> I guess there's a `!` missing in front of `s.startsWith("domain:")` here? > > This is what was intended (equivalent) > > `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as ! (s.equals("always")) || ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From mcimadamore at openjdk.java.net Fri Jan 14 11:19:36 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 14 Jan 2022 11:19:36 GMT Subject: [jdk18] Integrated: 8279930: Synthetic cast causes generation of store barriers when using heap segments In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 15:48:20 GMT, Maurizio Cimadamore wrote: > When looking at larger benchmarks, I noted a discrepancy between the performance of off-heap segments and on-heap segments. Looking at the assembly for the `MemorySegment::asSlice` method I could see some additional barriers in the off-heap case, but could not initially make sense of them. Vlad pointed me at G1 (in fact no such barrier was emitted when using a different GC, such as the serial GC, or ZGC), and later Erik narrowed the problem down to a failure in a C2 optimization to remove barriers around initializing stores. This problem was caused by a synthetic cast added by javac to a value (the base object) that initialized the newly created memory segment slice. Because of that case, C2 missed the store as an "initializing" one, and inserted additional barriers. This patch should make performance of on-heap segments a lot more reliable, especially when slicing is involved. This pull request has now been integrated. Changeset: c6b02755 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk18/commit/c6b027559c6e055b1475ada4001ef483b1a12d24 Stats: 292 lines in 3 files changed: 263 ins; 0 del; 29 mod 8279930: Synthetic cast causes generation of store barriers when using heap segments Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk18/pull/97 From jlahoda at openjdk.java.net Fri Jan 14 11:22:36 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 14 Jan 2022 11:22:36 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos javac changes look good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From azvegint at openjdk.java.net Fri Jan 14 12:19:28 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 14 Jan 2022 12:19:28 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <2NHrJp-0YZuLsk1to7auM4-WbJ0BxxfUImHMBAYHxs8=.012a0e0c-a9e7-4bb9-b822-21334744d4ed@github.com> On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Client changes looks good to me. ------------- Marked as reviewed by azvegint (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From duke at openjdk.java.net Fri Jan 14 12:21:54 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 14 Jan 2022 12:21:54 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load Message-ID: `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. ------------- Commit messages: - [PATCH] Remove double buffering of InputStream for Properties.load - [PATCH] Remove double buffering of InputStream for Properties.load Changes: https://git.openjdk.java.net/jdk/pull/7021/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7021&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280010 Stats: 30 lines in 8 files changed: 0 ins; 11 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7021.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7021/head:pull/7021 PR: https://git.openjdk.java.net/jdk/pull/7021 From serb at openjdk.java.net Fri Jan 14 12:21:55 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 14 Jan 2022 12:21:55 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. The code change looks fine, but can you please check the actual performance impact, will the perf be the same after the change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From duke at openjdk.java.net Fri Jan 14 12:21:56 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 14 Jan 2022 12:21:56 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Checked. `BufferedInputStream` add a bit of overhead. Benchmark @BenchmarkMode(value = Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(iterations = 6, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Fork(1) @State(Scope.Benchmark) public class PropertiesLoad { Properties properties; private InputStream arrayInputStream; private InputStream fileInputStream; private Path filePath; @Setup public void setupStrings() throws IOException { properties = new Properties(); String content = """ currentVersion=IdealGraphVisualizer {0} LBL_splash_window_title=Starting IdealGraphVisualizer SPLASH_WIDTH=475 SplashProgressBarBounds=0,273,475,6 SplashProgressBarColor=0xFFFFFF SplashRunningTextBounds=10,283,460,12 SplashRunningTextColor=0xFFFFFF """; filePath = Files.createTempFile("benchmark", ".properties"); Files.writeString(filePath, content); arrayInputStream = new ByteArrayInputStream(content.getBytes(StandardCharsets.UTF_8)); fileInputStream = Files.newInputStream(filePath); } @TearDown public void tearDown() throws IOException { fileInputStream.close(); Files.delete(filePath); } @Benchmark public Properties plain_ByteStream() throws IOException { properties.load(arrayInputStream); return properties; } @Benchmark public Properties plain_fileStream() throws IOException { properties.load(fileInputStream); return properties; } @Benchmark public Properties buffered_ByteStream() throws IOException { properties.load(new BufferedInputStream(arrayInputStream)); return properties; } @Benchmark public Properties buffered_fileStream() throws IOException { properties.load(new BufferedInputStream(fileInputStream)); return properties; } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(PropertiesLoad.class.getSimpleName()) .build(); new Runner(opt).run(); } } Results: Benchmark Mode Cnt Score Error Units PropertiesLoad.buffered_ByteStream avgt 5 2416,364 ? 46,209 ns/op PropertiesLoad.buffered_fileStream avgt 5 4276,015 ? 139,094 ns/op PropertiesLoad.plain_ByteStream avgt 5 1445,864 ? 649,779 ns/op PropertiesLoad.plain_fileStream avgt 5 3183,012 ? 198,974 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From egahlin at openjdk.java.net Fri Jan 14 12:42:32 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 14 Jan 2022 12:42:32 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos Marked as reviewed by egahlin (Reviewer). The JFR related changes looks OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From amenkov at openjdk.java.net Fri Jan 14 13:15:22 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 14 Jan 2022 13:15:22 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From jlaskey at openjdk.java.net Fri Jan 14 14:39:52 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 14 Jan 2022 14:39:52 GMT Subject: RFR: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails Message-ID: Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. ------------- Commit messages: - Bump up memory requirements. Changes: https://git.openjdk.java.net/jdk/pull/7086/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7086&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279954 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7086/head:pull/7086 PR: https://git.openjdk.java.net/jdk/pull/7086 From dfuchs at openjdk.java.net Fri Jan 14 14:51:23 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 14:51:23 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Changes to `java.util.logging` look fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From dfuchs at openjdk.java.net Fri Jan 14 15:09:25 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 14 Jan 2022 15:09:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Have you been able to test this on a specific setup? Would be good to hear from @msheppar too. src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: > 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include > 151: * a channel binding token for the destination server. The default behavior and setting for the > 152: * property is "never" Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too? src/java.security.jgss/share/classes/module-info.java line 36: > 34: module java.security.jgss { > 35: requires java.naming; > 36: requires java.security.sasl; Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From mullan at openjdk.java.net Fri Jan 14 15:16:28 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 14 Jan 2022 15:16:28 GMT Subject: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2] In-Reply-To: <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> <4MWAIhFIKQSD6Agtm7Ogl8kMR0OqLtpQXOX_VwaUFxU=.84ba40da-be25-47eb-8396-22c6127921ce@github.com> Message-ID: <_XhQIwiudN6adFO68cMeG19Q7OaSVmtVOxzMgVMYg9I=.af5b5ba8-726a-4587-a991-6651b6265062@github.com> On Thu, 13 Jan 2022 21:57:57 GMT, Sean Mullan wrote: >> If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. >> >> This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. >> >> An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Change permittedAlgs variable name. > Move put methods out of checkConstraints(). Each `CodeSigner[]` reference uniquely represents the signers of an entry. Multiple entries can map to the same `CodeSigner[]` reference. We only need reference equality for the keys as each JAR entry is already mapped to an array of `CodeSigner`. It's basically an `IdentityHashMap` but we don't need to specifically use that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From shade at openjdk.java.net Fri Jan 14 15:19:28 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 14 Jan 2022 15:19:28 GMT Subject: RFR: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote: > Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7086 From mullan at openjdk.java.net Fri Jan 14 15:26:37 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 14 Jan 2022 15:26:37 GMT Subject: Integrated: 8278851: Correct signer logic for jars signed with multiple digestalgs In-Reply-To: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> References: <3dofmRSqyzZKO8J5hbr_plpierN92VoXTWTJK_X5TJk=.c51f78e0-9d09-4be5-89da-874806b2cfcd@github.com> Message-ID: <3FFvIAdVz8COQnCOuRrXPtCTqQnpZoHwM0Q7z6ctcCA=.34c42417-f567-47f5-9686-0bc6b6dd0fa5@github.com> On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly returning null indicating that the jar entry has no signers. > > This fixes the issue such that an entry is considered signed if at least one of the digest algorithms is not disabled and the digest match passes. This makes the fix consistent with how multiple digest algorithms are handled in the Signature File. This also fixes an issue in the `ManifestEntryVerifier.getParams()` method in which it was incorrectly checking the algorithm constraints against all signers of a JAR when it should check them only against the signers of the entry that is being verified. > > An additional cache has also been added to avoid checking if the digest algorithm is disabled more than once for entries signed by the same set of signers. This pull request has now been integrated. Changeset: 61b89443 Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/61b8944327e3d12cf58dc3f6bc45ecbeba4ef611 Stats: 264 lines in 3 files changed: 214 ins; 20 del; 30 mod 8278851: Correct signer logic for jars signed with multiple digestalgs Reviewed-by: coffeys, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/7056 From rriggs at openjdk.java.net Fri Jan 14 15:28:35 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 14 Jan 2022 15:28:35 GMT Subject: RFR: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote: > Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. If the error message: ```OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000001cfdf610000, 10485760, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455) ``` Correctly reflects the error, raising the requested heap size won't help. The size of the paging file isn't sufficient. Without knowing how the system configuration its hard to come to a conclusion. Perhaps one of the systems used to run GHA has an inconsistently sized page file. $.02 ------------- PR: https://git.openjdk.java.net/jdk/pull/7086 From rriggs at openjdk.java.net Fri Jan 14 15:47:31 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 14 Jan 2022 15:47:31 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v2] In-Reply-To: References: Message-ID: <1Itd1Th-S_ukQut5lYQGjrH8jYiEB9cjcpLaBekcqxw=.33222f0a-8841-4b10-8252-649a158f60e0@github.com> On Thu, 16 Dec 2021 20:48:39 GMT, liach wrote: >> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. > > liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default > - update dates > - Also test cme for identity hash map > - Fix putIfAbsent > - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap The PR description doesn't do the change request justice. At least the first paragraph from the bug report would be useful. The rationale seems ok but not compelling: "may save a few hash table lookups and moderately boost the performance of IdentityHashMap". Please quantify the improvement with JMH test results. There may be an existing test in `test/micro/org/openjdk/bench/java/util` to build on. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From jlaskey at openjdk.java.net Fri Jan 14 15:58:31 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 14 Jan 2022 15:58:31 GMT Subject: RFR: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote: > Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. "Perhaps one of the systems used to run GHA has an inconsistently sized page file" That has been my thought all along. I pinged the gc team and infra about this. Nothing from infra but DH thought that the @requires might work round the issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7086 From jjg at openjdk.java.net Fri Jan 14 16:08:31 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 14 Jan 2022 16:08:31 GMT Subject: RFR: 8279918: Fix various doc typos [v2] In-Reply-To: References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: <96bxwtnI-_Z67Udh4acEGwA2xzIy6dAV6CxOe9HLkRo=.dd8643aa-f3be-42e2-ad72-4a00d90363d9@github.com> On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote: >> - Most of the typos are of a trivial kind: missing whitespace. >> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. >> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. >> - `'` is an apostrophe, which does not require to be encoded. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Additional typos jdk.compiler and jdk.javadoc look good ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7063 From prappo at openjdk.java.net Fri Jan 14 16:13:34 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 14 Jan 2022 16:13:34 GMT Subject: Integrated: 8279918: Fix various doc typos In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com> Message-ID: On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote: > - Most of the typos are of a trivial kind: missing whitespace. > - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch. > - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed. > - `'` is an apostrophe, which does not require to be encoded. This pull request has now been integrated. Changeset: f1805309 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/f1805309352a22119ae2edf8bfbb596f00936224 Stats: 88 lines in 35 files changed: 0 ins; 0 del; 88 mod 8279918: Fix various doc typos Reviewed-by: kevinw, lancea, mullan, sspitsyn, naoto, jlahoda, azvegint, egahlin, jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/7063 From sspitsyn at openjdk.java.net Fri Jan 14 17:59:29 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 14 Jan 2022 17:59:29 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From duke at openjdk.java.net Fri Jan 14 18:00:59 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 14 Jan 2022 18:00:59 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable Message-ID: Method `Class.isAssignableFrom` is often used in form of: if (clazz.isAssignableFrom(obj.getClass())) { Such condition could be simplified to more shorter and performarnt code if (clazz.isInstance(obj)) { Replacement is equivalent if it's known that `obj != null`. In JDK codebase there are many such places. I tried to measure performance via JMH Class integerClass = Integer.class; Class numberClass = Number.class; Object integerObject = 45666; Object doubleObject = 8777d; @Benchmark public boolean integerInteger_isInstance() { return integerClass.isInstance(integerObject); } @Benchmark public boolean integerInteger_isAssignableFrom() { return integerClass.isAssignableFrom(integerObject.getClass()); } @Benchmark public boolean integerDouble_isInstance() { return integerClass.isInstance(doubleObject); } @Benchmark public boolean integerDouble_isAssignableFrom() { return integerClass.isAssignableFrom(doubleObject.getClass()); } @Benchmark public boolean numberDouble_isInstance() { return numberClass.isInstance(doubleObject); } @Benchmark public boolean numberDouble_isAssignableFrom() { return numberClass.isAssignableFrom(doubleObject.getClass()); } @Benchmark public boolean numberInteger_isInstance() { return numberClass.isInstance(integerObject); } @Benchmark public boolean numberInteger_isAssignableFrom() { return numberClass.isAssignableFrom(integerObject.getClass()); } @Benchmark public void numberIntegerDouble_isInstance(Blackhole bh) { bh.consume(numberClass.isInstance(integerObject)); bh.consume(numberClass.isInstance(doubleObject)); } @Benchmark public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); } `isInstance` is a bit faster than `isAssignableFrom` Benchmark Mode Cnt Score Error Units integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op ------------- Commit messages: - [PATCH] Use Class.isInstance instead of Class.isAssignableFrom where applicable Changes: https://git.openjdk.java.net/jdk/pull/7061/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7061&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280035 Stats: 25 lines in 10 files changed: 0 ins; 3 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/7061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7061/head:pull/7061 PR: https://git.openjdk.java.net/jdk/pull/7061 From duke at openjdk.java.net Fri Jan 14 18:01:01 2022 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 14 Jan 2022 18:01:01 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote: > Method `Class.isAssignableFrom` is often used in form of: > > if (clazz.isAssignableFrom(obj.getClass())) { > Such condition could be simplified to more shorter and performarnt code > > if (clazz.isInstance(obj)) { > > Replacement is equivalent if it's known that `obj != null`. > In JDK codebase there are many such places. > > I tried to measure performance via JMH > > Class integerClass = Integer.class; > Class numberClass = Number.class; > > Object integerObject = 45666; > Object doubleObject = 8777d; > > @Benchmark > public boolean integerInteger_isInstance() { > return integerClass.isInstance(integerObject); > } > > @Benchmark > public boolean integerInteger_isAssignableFrom() { > return integerClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public boolean integerDouble_isInstance() { > return integerClass.isInstance(doubleObject); > } > > @Benchmark > public boolean integerDouble_isAssignableFrom() { > return integerClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberDouble_isInstance() { > return numberClass.isInstance(doubleObject); > } > > @Benchmark > public boolean numberDouble_isAssignableFrom() { > return numberClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberInteger_isInstance() { > return numberClass.isInstance(integerObject); > } > > @Benchmark > public boolean numberInteger_isAssignableFrom() { > return numberClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public void numberIntegerDouble_isInstance(Blackhole bh) { > bh.consume(numberClass.isInstance(integerObject)); > bh.consume(numberClass.isInstance(doubleObject)); > } > > @Benchmark > public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { > bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); > bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); > } > > `isInstance` is a bit faster than `isAssignableFrom` > > Benchmark Mode Cnt Score Error Units > integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op > integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op > integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op > numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op > integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op > integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op > numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op > numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op > numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op > numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405: > 403: Object res = m.invoke(a, new Object[0]); > 404: if (res instanceof Annotation[]) { > 405: for (Annotation rep : (Annotation[]) m.invoke(a, new Object[0])) { BTW it looks suspicious to have `m.invoke(a, new Object[0])` called again here. Shouldn't it just reuse `res` variable instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From psandoz at openjdk.java.net Fri Jan 14 18:05:30 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 14 Jan 2022 18:05:30 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7] In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote: >>> > embarrassingly parallelizable >>> >>> Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that. >> >> Ok, fair point, to avoid possible confusion I have removed "embarrassingly". I don't think we need to refer to other algorithms. > > Hi @PaulSandoz is there anything else that we need to do? Or is this in the hopper for Java 19 already? @kabutz i just finalized the CSR (the new year break meant all this is taking longer than usual). Based on that review we may need to make some tweaks to the API doc, which should be quick to process. So it should be in the bag for 19. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From michaelm at openjdk.java.net Fri Jan 14 18:45:27 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 14 Jan 2022 18:45:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 14 Jan 2022 14:52:13 GMT, Daniel Fuchs wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: > >> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include >> 151: * a channel binding token for the destination server. The default behavior and setting for the >> 152: * property is "never" > > Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too? It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > src/java.security.jgss/share/classes/module-info.java line 36: > >> 34: module java.security.jgss { >> 35: requires java.naming; >> 36: requires java.security.sasl; > > Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK. Yes. I would like the security team to validate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From shade at openjdk.java.net Fri Jan 14 19:56:43 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 14 Jan 2022 19:56:43 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache Message-ID: JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; Attention @rkennke, @plevart. Additional testing: - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` - [x] Linux x86_64 fastdebug `tier1` - [ ] Linux x86_64 fastdebug `tier2` - [ ] Linux x86_64 fastdebug `tier3` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/7092/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280041 Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7092/head:pull/7092 PR: https://git.openjdk.java.net/jdk/pull/7092 From rkennke at openjdk.java.net Fri Jan 14 20:53:26 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 14 Jan 2022 20:53:26 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [ ] Linux x86_64 fastdebug `tier2` > - [ ] Linux x86_64 fastdebug `tier3` Right, good catches! It seems a bit weird that the constructors of Reference would accept null referents anyway, but it is like it is. *shrugs* One additional improvement would be to change r.get() == null to r.refersTo(null) to check for cleared reference, that avoids reviving the referent, e.g. in SATB GCs. I leave that up to you. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Fri Jan 14 22:29:52 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 14 Jan 2022 22:29:52 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 20:50:24 GMT, Roman Kennke wrote: > One additional improvement would be to change r.get() == null to r.refersTo(null) to check for cleared reference, that avoids reviving the referent, e.g. in SATB GCs. I leave that up to you. I think that does not work, because we want to strongly reference the `val` for eventual return. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From lancea at openjdk.java.net Fri Jan 14 23:59:39 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 14 Jan 2022 23:59:39 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v3] In-Reply-To: References: Message-ID: <49UK9L8EA2FEvjWH3lBqkljNJXYR6OauKAfHIEKxIsU=.a48ccca9-301e-486f-af58-71feba5a02aa@github.com> On Fri, 14 Jan 2022 11:05:06 GMT, Masanori Yano wrote: >> Could you please review the JDK-8272746 bug fixes? >> Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. >> It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. >> In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8272746: ZipFile can't open big file (NegativeArraySizeException) Thank you for making the changes. Overall it looks much better Please add comments describing your constants as well as a comment describing the intent of your setup and test methods ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From weijun at openjdk.java.net Sat Jan 15 00:30:28 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 15 Jan 2022 00:30:28 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 14 Jan 2022 18:42:08 GMT, Michael McMahon wrote: >> src/java.security.jgss/share/classes/module-info.java line 36: >> >>> 34: module java.security.jgss { >>> 35: requires java.naming; >>> 36: requires java.security.sasl; >> >> Someone from security-dev should probably review this and validate that this is OK. I'm also a bit uncomfortable that we require a class from `com.sun.jndi.ldap.sasl` even though `java.naming` is already required by `java.security.jgss` - so maybe this is OK. > > Yes. I would like the security team to validate this. I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. You might need to modify the types of exceptions thrown in the class and move the 2 final strings to some other class inside `java.security.sasl`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Sat Jan 15 00:47:27 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 15 Jan 2022 00:47:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> On Fri, 14 Jan 2022 18:40:41 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: >> >>> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include >>> 151: * a channel binding token for the destination server. The default behavior and setting for the >>> 152: * property is "never" >> >> Maybe this description should be added to `src/java.base//share/classes/java/net/doc-files/net-properties.html` too? > > It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". BTW, will you reuse this system property if we decide to support CBT in NTLM as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Sat Jan 15 00:52:27 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 15 Jan 2022 00:52:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> Message-ID: On Fri, 14 Jan 2022 10:18:50 GMT, Daniel Fuchs wrote: >> This is what was intended (equivalent) >> >> `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` > > Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as > > ! (s.equals("always")) || ... Shall we log a message if the value is not one of the 3 forms? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From jbhateja at openjdk.java.net Sat Jan 15 02:28:07 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sat, 15 Jan 2022 02:28:07 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API Message-ID: Summary of changes: - Intrinsify Math.round(float) and Math.round(double) APIs. - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. - Test creation using new IR testing framework. Following are the performance number of a JMH micro included with the patch Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) ? | ? | BASELINE AVX2 | WithOpt AVX2 | Gain (opt/baseline) | Baseline AVX3 | Withopt AVX3 | Gain (opt/baseline) -- | -- | -- | -- | -- | -- | -- | -- Benchmark | ARRAYLEN | Score (ops/ms) | Score (ops/ms) | ? | Score (ops/ms) | Score (ops/ms) | ? FpRoundingBenchmark.test_round_double | 1024 | 518.532 | 1364.066 | 2.630630318 | 512.908 | 4292.11 | 8.368186887 FpRoundingBenchmark.test_round_double | 2048 | 270.137 | 830.986 | 3.076165057 | 273.159 | 2459.116 | 9.002507697 FpRoundingBenchmark.test_round_float | 1024 | 752.436 | 7780.905 | 10.34095259 | 752.49 | 9506.694 | 12.63364829 FpRoundingBenchmark.test_round_float | 2048 | 389.499 | 4113.046 | 10.55983712 | 389.63 | 4863.673 | 12.48279907 Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - 8279508: Auto-vectorize Math.round API Changes: https://git.openjdk.java.net/jdk/pull/7094/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279508 Stats: 409 lines in 22 files changed: 342 ins; 1 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From serb at openjdk.java.net Sat Jan 15 02:32:32 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 15 Jan 2022 02:32:32 GMT Subject: RFR: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From duke at openjdk.java.net Sat Jan 15 09:35:32 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 15 Jan 2022 09:35:32 GMT Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5] In-Reply-To: References: Message-ID: On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing BufferedInputStream Good catches, I will look into your comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/6935 From duke at openjdk.java.net Sat Jan 15 09:36:27 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 15 Jan 2022 09:36:27 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual review? > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Please keep this PR open as I am working on several sub-issues currently. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From duke at openjdk.java.net Sat Jan 15 14:05:21 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Sat, 15 Jan 2022 14:05:21 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Sat, 15 Jan 2022 00:23:31 GMT, Weijun Wang wrote: >> Yes. I would like the security team to validate this. > > I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. It's even not restricted to GSS-API. According to https://www.rfc-editor.org/rfc/rfc5056, "Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS-API applications". > > If so, you might need to modify the types of exceptions thrown in the class, and move the 2 final strings to some other class inside `java.security.sasl`. Seems like `com.sun.jndi.ldap.sasl.TlsChannelBinding` is not misplaced.... ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From psandoz at openjdk.java.net Sat Jan 15 18:06:26 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Sat, 15 Jan 2022 18:06:26 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 06:07:29 GMT, kabutz wrote: >> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. >> >> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. >> >> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. >> >> Some benchmark results, run on my 1-6-2 server: >> >> >> Benchmark (n) Mode Cnt Score Error Units >> BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op >> BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op >> BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op >> BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op >> BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op >> BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op >> >> >> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Changed depth type to byte to save 8 bytes on each RecursiveSquare instance test/jdk/java/math/BigInteger/BigIntegerParallelMultiplyTest.java line 64: > 62: BigInteger fib = fibonacci(n, BigInteger::multiply); > 63: System.out.printf("fibonacci(%d) = %d%n", n, fib); > 64: } I think we can remove this and the loop block at #70-80, since we have the performance test. After that we are good. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Sun Jan 16 02:26:23 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 16 Jan 2022 02:26:23 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API In-Reply-To: References: Message-ID: <3jys7tQ93ojPrWjoGb8Z04Ed-pUiimIj1V2pSCvdLoo=.590b55fd-39af-459c-8add-37bb6cd34f6f@github.com> On Sat, 15 Jan 2022 02:21:38 GMT, Jatin Bhateja wrote: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > ? | ? | BASELINE AVX2 | WithOpt AVX2 | Gain (opt/baseline) | Baseline AVX3 | Withopt AVX3 | Gain (opt/baseline) > -- | -- | -- | -- | -- | -- | -- | -- > Benchmark | ARRAYLEN | Score (ops/ms) | Score (ops/ms) | ? | Score (ops/ms) | Score (ops/ms) | ? > FpRoundingBenchmark.test_round_double | 1024 | 518.532 | 1364.066 | 2.630630318 | 512.908 | 4292.11 | 8.368186887 > FpRoundingBenchmark.test_round_double | 2048 | 270.137 | 830.986 | 3.076165057 | 273.159 | 2459.116 | 9.002507697 > FpRoundingBenchmark.test_round_float | 1024 | 752.436 | 7780.905 | 10.34095259 | 752.49 | 9506.694 | 12.63364829 > FpRoundingBenchmark.test_round_float | 2048 | 389.499 | 4113.046 | 10.55983712 | 389.63 | 4863.673 | 12.48279907 > > Kindly review and share your feedback. > > Best Regards, > Jatin Hi, did we have tests for the scalar intrinsification already? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Jan 16 04:01:26 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 16 Jan 2022 04:01:26 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API In-Reply-To: <3jys7tQ93ojPrWjoGb8Z04Ed-pUiimIj1V2pSCvdLoo=.590b55fd-39af-459c-8add-37bb6cd34f6f@github.com> References: <3jys7tQ93ojPrWjoGb8Z04Ed-pUiimIj1V2pSCvdLoo=.590b55fd-39af-459c-8add-37bb6cd34f6f@github.com> Message-ID: <025PTTFCmBytUGceCiL86BhLqWIczWJvEQTF5pusmF8=.9ec9f398-83b2-41a2-8988-47aa466a9871@github.com> On Sun, 16 Jan 2022 02:23:15 GMT, Quan Anh Mai wrote: > Hi, did we have tests for the scalar intrinsification already? Thanks. Verification is done against scalar rounding operation. https://github.com/openjdk/jdk/pull/7094/files#diff-88b1bad16d68808e6c1224fff7773104924bfdabcb23958c2a3e4e6b06844701R369 Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sun Jan 16 08:13:25 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 16 Jan 2022 08:13:25 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 02:21:38 GMT, Jatin Bhateja wrote: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > ? | ? | BASELINE AVX2 | WithOpt AVX2 | Gain (opt/baseline) | Baseline AVX3 | Withopt AVX3 | Gain (opt/baseline) > -- | -- | -- | -- | -- | -- | -- | -- > Benchmark | ARRAYLEN | Score (ops/ms) | Score (ops/ms) | ? | Score (ops/ms) | Score (ops/ms) | ? > FpRoundingBenchmark.test_round_double | 1024 | 518.532 | 1364.066 | 2.630630318 | 512.908 | 4292.11 | 8.368186887 > FpRoundingBenchmark.test_round_double | 2048 | 270.137 | 830.986 | 3.076165057 | 273.159 | 2459.116 | 9.002507697 > FpRoundingBenchmark.test_round_float | 1024 | 752.436 | 7780.905 | 10.34095259 | 752.49 | 9506.694 | 12.63364829 > FpRoundingBenchmark.test_round_float | 2048 | 389.499 | 4113.046 | 10.55983712 | 389.63 | 4863.673 | 12.48279907 > > Kindly review and share your feedback. > > Best Regards, > Jatin Ah understood, you can also disable loop unrolling so that vectorisation does not take place. Regards. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Mon Jan 17 05:29:32 2022 From: duke at openjdk.java.net (prasad-bit) Date: Mon, 17 Jan 2022 05:29:32 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang wrote: >> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > > This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". > > BTW, will you reuse this system property if we decide to support CBT in NTLM as well? I vote for "jdk.https.tls.cbt" ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From pkoppula at openjdk.java.net Mon Jan 17 06:35:30 2022 From: pkoppula at openjdk.java.net (Prasadrao Koppula) Date: Mon, 17 Jan 2022 06:35:30 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Sat, 15 Jan 2022 00:44:08 GMT, Weijun Wang wrote: >> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > > This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". > > BTW, will you reuse this system property if we decide to support CBT in NTLM as well? I vote for "jdk.https.tls.cbt" ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From egahlin at openjdk.java.net Mon Jan 17 08:31:26 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 17 Jan 2022 08:31:26 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 08:39:04 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> >> if (clazz.isInstance(obj)) { >> >> Replacement is equivalent if it's known that `obj != null`. >> In JDK codebase there are many such places. >> >> I tried to measure performance via JMH >> >> Class integerClass = Integer.class; >> Class numberClass = Number.class; >> >> Object integerObject = 45666; >> Object doubleObject = 8777d; >> >> @Benchmark >> public boolean integerInteger_isInstance() { >> return integerClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean integerInteger_isAssignableFrom() { >> return integerClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public boolean integerDouble_isInstance() { >> return integerClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean integerDouble_isAssignableFrom() { >> return integerClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberDouble_isInstance() { >> return numberClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean numberDouble_isAssignableFrom() { >> return numberClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberInteger_isInstance() { >> return numberClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean numberInteger_isAssignableFrom() { >> return numberClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public void numberIntegerDouble_isInstance(Blackhole bh) { >> bh.consume(numberClass.isInstance(integerObject)); >> bh.consume(numberClass.isInstance(doubleObject)); >> } >> >> @Benchmark >> public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { >> bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); >> bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); >> } >> >> `isInstance` is a bit faster than `isAssignableFrom` >> >> Benchmark Mode Cnt Score Error Units >> integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op >> integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op >> integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op >> numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op >> integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op >> integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op >> numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op >> numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op >> numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op >> numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op > > src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405: > >> 403: Object res = m.invoke(a, new Object[0]); >> 404: if (res instanceof Annotation[]) { >> 405: for (Annotation rep : (Annotation[]) m.invoke(a, new Object[0])) { > > BTW it looks suspicious to have `m.invoke(a, new Object[0])` called again here. Shouldn't it just reuse `res` variable instead? It looks unnecessary. Please feel free to fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From turbanoff at gmail.com Mon Jan 17 09:37:04 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Mon, 17 Jan 2022 12:37:04 +0300 Subject: Thread.dispatchUncaughtException possible NPE? Message-ID: Hello. I see that Thread.dispatchUncaughtException calls getUncaughtExceptionHandler() which reads volatile field twice: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Thread.java#L1978 private volatile UncaughtExceptionHandler uncaughtExceptionHandler; public UncaughtExceptionHandler getUncaughtExceptionHandler() { return uncaughtExceptionHandler != null ? uncaughtExceptionHandler : group; } private void dispatchUncaughtException(Throwable e) { getUncaughtExceptionHandler().uncaughtException(this, e); } I wonder if it's possible to get a NPE here? Another thread could change uncaughtExceptionHandler between 2 volatile reads. Or JVM somehow forbid this? Andrey Turbanov From myano at openjdk.java.net Mon Jan 17 09:56:13 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Mon, 17 Jan 2022 09:56:13 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v4] In-Reply-To: References: Message-ID: > Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. > In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8272746: ZipFile can't open big file (NegativeArraySizeException) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6927/files - new: https://git.openjdk.java.net/jdk/pull/6927/files/621f1a68..9ebb2a7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=02-03 Stats: 14 lines in 1 file changed: 12 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927 From myano at openjdk.java.net Mon Jan 17 09:56:16 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Mon, 17 Jan 2022 09:56:16 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v3] In-Reply-To: <49UK9L8EA2FEvjWH3lBqkljNJXYR6OauKAfHIEKxIsU=.a48ccca9-301e-486f-af58-71feba5a02aa@github.com> References: <49UK9L8EA2FEvjWH3lBqkljNJXYR6OauKAfHIEKxIsU=.a48ccca9-301e-486f-af58-71feba5a02aa@github.com> Message-ID: On Fri, 14 Jan 2022 23:55:58 GMT, Lance Andersen wrote: >> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > Thank you for making the changes. Overall it looks much better > > Please add comments describing your constants as well as a comment describing the intent of your setup and test methods @LanceAndersen As you pointed out, I described the explanation of the test in the comment. Is there anything else I should fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From forax at univ-mlv.fr Mon Jan 17 09:59:14 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 17 Jan 2022 10:59:14 +0100 (CET) Subject: Thread.dispatchUncaughtException possible NPE? In-Reply-To: References: Message-ID: <1330036204.13255275.1642413554131.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Andrey Turbanov" > To: "core-libs-dev" > Sent: Monday, January 17, 2022 10:37:04 AM > Subject: Thread.dispatchUncaughtException possible NPE? > Hello. Hello Andrey, > I see that Thread.dispatchUncaughtException calls > getUncaughtExceptionHandler() which reads volatile field twice: > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Thread.java#L1978 > > private volatile UncaughtExceptionHandler uncaughtExceptionHandler; > > public UncaughtExceptionHandler getUncaughtExceptionHandler() { > return uncaughtExceptionHandler != null ? > uncaughtExceptionHandler : group; > } > > private void dispatchUncaughtException(Throwable e) { > getUncaughtExceptionHandler().uncaughtException(this, e); > } > > > I wonder if it's possible to get a NPE here? Another thread could > change uncaughtExceptionHandler between 2 volatile reads. > Or JVM somehow forbid this? yes, it's a bug, the field should be read only once. > > > > > Andrey Turbanov R?mi From myano at openjdk.java.net Mon Jan 17 10:08:21 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Mon, 17 Jan 2022 10:08:21 GMT Subject: RFR: 8278892: java.naming module description is missing @uses tags to document the services that it uses In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 05:48:26 GMT, Masanori Yano wrote: > I have fixed the javadoc comments as the definition. Could you review this fix? Could someone please review this pull request? ------------- PR: https://git.openjdk.java.net/jdk/pull/7041 From redestad at openjdk.java.net Mon Jan 17 11:05:29 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 17 Jan 2022 11:05:29 GMT Subject: Integrated: 8278831: Use table lookup for the last two bytes in Integer.getChars In-Reply-To: <1yeXykiACnNtNbcv8wIg4a-WURoc93Z6YUHODFhIlOA=.27d2030b-ff1a-46dc-8544-78cccad655d7@github.com> References: <1yeXykiACnNtNbcv8wIg4a-WURoc93Z6YUHODFhIlOA=.27d2030b-ff1a-46dc-8544-78cccad655d7@github.com> Message-ID: <6jgM7naAA1LwxdSIrcUN0pyrrr8tym0MVDq0PYdWwJ4=.c6e964bd-37b2-4908-a754-bdcd2f7e490a@github.com> On Wed, 15 Dec 2021 23:04:37 GMT, Claes Redestad wrote: > During TemplatedStrings work Jim has noticed that we could probably profit from reusing the lookup tables also for the 1 or 2 leftmost bytes: > > // We know there are at most two digits left at this point. > buf[--charPos] = DigitOnes[-i]; > if (i < -9) { > buf[--charPos] = DigitTens[-i]; > } > > This avoids some arithmetic, and on average achieves a small speed-up since the lookup tables are likely cached are likely to be in cache. Small improvements on a few affected microbenchmarks, including the new Integers.toStringTiny, can be observed. > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > Integers.toStringTiny 500 avgt 50 21.862 ? 0.211 us/op > > > Patch: > > Benchmark (size) Mode Cnt Score Error Units > Integers.toStringTiny 500 avgt 50 20.619 ? 0.330 us/op This pull request has now been integrated. Changeset: 71ca85f5 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/71ca85f5a6741a2db55a529192564f94b269fbd9 Stats: 42 lines in 4 files changed: 11 ins; 16 del; 15 mod 8278831: Use table lookup for the last two bytes in Integer.getChars Reviewed-by: jlaskey, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/6854 From pkoppula at openjdk.java.net Mon Jan 17 11:48:25 2022 From: pkoppula at openjdk.java.net (Prasadrao Koppula) Date: Mon, 17 Jan 2022 11:48:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Add Release note and Doc subtasks to the JBS ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Mon Jan 17 13:47:26 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 17 Jan 2022 13:47:26 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> Message-ID: On Sat, 15 Jan 2022 00:49:05 GMT, Weijun Wang wrote: >> Argh - you're right I missed the fact that the 3 expressions where included in parenthesis. I read it as >> >> ! (s.equals("always")) || ... > > Shall we log a message if the value is not one of the 3 forms? Usually malformed values are just ignored - and the property takes its default value. But yes - s.n.w.h.HttpClient has a logger so it wouldn't be much effort to log it as a DEBUG trace for better diagnostic. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Mon Jan 17 13:52:26 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 17 Jan 2022 13:52:26 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Mon, 17 Jan 2022 06:32:13 GMT, Prasadrao Koppula wrote: >> This system property should only be used for TLS, and the CBT can be used in both the SPNEGO mechanism and the Kerberos 5 mechanism. Therefore I suggest the name should probably contain "tls" (or maybe "https") and "negotiate". >> >> BTW, will you reuse this system property if we decide to support CBT in NTLM as well? > > I vote for "jdk.https.tls.cbt" > It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? AFAICS this file documents properties used by the networking task - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property) ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Mon Jan 17 16:29:29 2022 From: duke at openjdk.java.net (liach) Date: Mon, 17 Jan 2022 16:29:29 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v2] In-Reply-To: <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com> References: <5lHM93hicvGqb7ZF2zjtRlCo7UqvYQIYncP-FXb4ouY=.91a191c7-f7d4-4652-be36-93140e720298@github.com> Message-ID: On Sun, 19 Dec 2021 06:51:45 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Just use volatile directly to ensure read order I will check the hotspot assembly generated for both the volatile and the stable fields to see if the annotation is a valid replacement. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From lancea at openjdk.java.net Mon Jan 17 18:16:27 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 17 Jan 2022 18:16:27 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v4] In-Reply-To: References: Message-ID: <5twJcqHDwNQ-G_lVqFDC09JlnYcCEw4qoQZ1zkl1BbA=.d112abd2-344d-4062-b023-5ffa2454f67e@github.com> On Mon, 17 Jan 2022 09:56:13 GMT, Masanori Yano wrote: >> Could you please review the JDK-8272746 bug fixes? >> Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. >> It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. >> In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8272746: ZipFile can't open big file (NegativeArraySizeException) Looks fine. One minor comment update but you can integrate after making the change test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java line 82: > 80: > 81: /** > 82: * Validates that an appropriate exception is thrown when the ZipFile class Please change "appropriate" to "ZipException" ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6927 From coleenp at openjdk.java.net Mon Jan 17 19:25:26 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 17 Jan 2022 19:25:26 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3] In-Reply-To: References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: <7c6mh2-s3SkpfGG1WptyZsJjTfcDy1wX0Ll0713MLkU=.7df74a01-7ea5-49c1-9bda-f73798df3852@github.com> On Sat, 11 Dec 2021 01:55:50 GMT, Ioi Lam wrote: >> **Background:** >> >> In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: >> >> >> public enum Day { SUNDAY, MONDAY ... } >> >> >> to >> >> >> public class Day extends java.lang.Enum { >> public static final SUNDAY = new Day("SUNDAY"); >> public static final MONDAY = new Day("MONDAY"); ... >> } >> >> >> With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) >> >> **Fix:** >> >> During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. >> >> This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. >> >> **Verification:** >> >> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt >> >> **Testing:** >> >> Passed Oracle CI tiers 1-4. WIll run tier 5 as well. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8275731-heapshared-enum > - added exclusions needed by "java -Xshare:dump -ea -esa" > - Comments from @calvinccheung off-line > - 8275731: CDS archived enums objects are recreated at runtime I don't really know this code well enough to do a good code review. I had some comments though. src/hotspot/share/cds/cdsHeapVerifier.cpp line 165: > 163: > 164: ResourceMark rm; > 165: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) { Can this call instead void InstanceKlass::do_local_static_fields(void f(fieldDescriptor*, Handle, TRAPS), Handle mirror, TRAPS) { and have this next few lines in the function? src/hotspot/share/cds/cdsHeapVerifier.cpp line 254: > 252: InstanceKlass* ik = InstanceKlass::cast(k); > 253: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) { > 254: if (!fs.access_flags().is_static()) { same here. It only saves a couple of lines but then you can have the function outside this large function. src/hotspot/share/cds/cdsHeapVerifier.hpp line 52: > 50: mtClassShared, > 51: HeapShared::oop_hash> _table; > 52: Is this only used inside cdsHeapVerifier? if so it should be in the .cpp file. There's also an ArchiveableStaticFieldInfo. Not sure how they are related. src/hotspot/share/cds/heapShared.cpp line 433: > 431: oop mirror = k->java_mirror(); > 432: int i = 0; > 433: for (JavaFieldStream fs(k); !fs.done(); fs.next()) { This seems like it should also use InstanceKlass::do_local_static_fields. src/hotspot/share/cds/heapShared.cpp line 482: > 480: copy_open_objects(open_regions); > 481: > 482: CDSHeapVerifier::verify(); Should all this be DEBUG_ONLY ? src/hotspot/share/cds/heapShared.hpp line 236: > 234: oop _referrer; > 235: oop _obj; > 236: CachedOopInfo() :_subgraph_info(), _referrer(), _obj() {} Should these be initialized to nullptr? does this do this? ------------- PR: https://git.openjdk.java.net/jdk/pull/6653 From aefimov at openjdk.java.net Mon Jan 17 19:52:26 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Mon, 17 Jan 2022 19:52:26 GMT Subject: RFR: 8278892: java.naming module description is missing @uses tags to document the services that it uses In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 05:48:26 GMT, Masanori Yano wrote: > I have fixed the javadoc comments as the definition. Could you review this fix? Hi @masyano, Thanks for fixing `java.naming` module javadoc. The fix looks fine to me. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/7041 From jwilhelm at openjdk.java.net Tue Jan 18 01:13:35 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 18 Jan 2022 01:13:35 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: <2VZJKBdrdAX6ea6GEMABo4fmQA1ECrnfDSG-GVxyFNE=.0e2472af-e217-4b55-a1a1-093265dcec3f@github.com> On Thu, 13 Jan 2022 20:55:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 37143c09 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/37143c09ab56ff07767ab3ac392234e36ee82358 Stats: 124 lines in 6 files changed: 117 ins; 1 del; 6 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7068 From jwilhelm at openjdk.java.net Tue Jan 18 01:23:21 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 18 Jan 2022 01:23:21 GMT Subject: RFR: Merge jdk18 Message-ID: <8PYG3aNFWxaqHY3TBzCqtA9mdJedp5I3Sd7xp2ttgWo=.90a15cbc-0f8b-4c55-8df3-15838148f979@github.com> Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18 - 8279998: PPC64 debug builds fail with "untested: RangeCheckStub: predicate_failed_trap_id" - 8280034: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 - 8279924: [PPC64, s390] implement frame::is_interpreted_frame_valid checks - 8279702: [macosx] ignore xcodebuild warnings on M1 - 8279930: Synthetic cast causes generation of store barriers when using heap segments - 8279597: [TESTBUG] ReturnBlobToWrongHeapTest.java fails with -XX:TieredStopAtLevel=1 on machines with many cores - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7119&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7119&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7119/files Stats: 403 lines in 9 files changed: 361 ins; 4 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/7119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7119/head:pull/7119 PR: https://git.openjdk.java.net/jdk/pull/7119 From myano at openjdk.java.net Tue Jan 18 01:37:04 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 18 Jan 2022 01:37:04 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v5] In-Reply-To: References: Message-ID: > Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. > In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8272746: ZipFile can't open big file (NegativeArraySizeException) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6927/files - new: https://git.openjdk.java.net/jdk/pull/6927/files/9ebb2a7a..c6b53732 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927 From myano at openjdk.java.net Tue Jan 18 01:37:07 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 18 Jan 2022 01:37:07 GMT Subject: RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException) [v4] In-Reply-To: <5twJcqHDwNQ-G_lVqFDC09JlnYcCEw4qoQZ1zkl1BbA=.d112abd2-344d-4062-b023-5ffa2454f67e@github.com> References: <5twJcqHDwNQ-G_lVqFDC09JlnYcCEw4qoQZ1zkl1BbA=.d112abd2-344d-4062-b023-5ffa2454f67e@github.com> Message-ID: On Mon, 17 Jan 2022 18:10:02 GMT, Lance Andersen wrote: >> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272746: ZipFile can't open big file (NegativeArraySizeException) > > test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java line 82: > >> 80: >> 81: /** >> 82: * Validates that an appropriate exception is thrown when the ZipFile class > > Please change "appropriate" to "ZipException" Thank you very much. I fixed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From dholmes at openjdk.java.net Tue Jan 18 01:58:29 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 Jan 2022 01:58:29 GMT Subject: RFR: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote: > Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. I also pointed out that we see the same error message in our CI and the infra folk assured me that the paging file was not misconfigured in any way. That said, while I understand the addition of the `@requires >= 8G`, I don't under stand why the actual Xms/Xmx values were bumped from 5G to 6G - that seems to be increasing the chances of running out of memory. ?? David ------------- PR: https://git.openjdk.java.net/jdk/pull/7086 From jwilhelm at openjdk.java.net Tue Jan 18 02:00:29 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 18 Jan 2022 02:00:29 GMT Subject: Integrated: Merge jdk18 In-Reply-To: <8PYG3aNFWxaqHY3TBzCqtA9mdJedp5I3Sd7xp2ttgWo=.90a15cbc-0f8b-4c55-8df3-15838148f979@github.com> References: <8PYG3aNFWxaqHY3TBzCqtA9mdJedp5I3Sd7xp2ttgWo=.90a15cbc-0f8b-4c55-8df3-15838148f979@github.com> Message-ID: On Tue, 18 Jan 2022 01:13:45 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 39f140a2 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/39f140a20120300074167597580f9be34e812cad Stats: 403 lines in 9 files changed: 361 ins; 4 del; 38 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7119 From alanb at openjdk.java.net Tue Jan 18 07:36:29 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 Jan 2022 07:36:29 GMT Subject: RFR: 8278892: java.naming module description is missing @uses tags to document the services that it uses In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 05:48:26 GMT, Masanori Yano wrote: > I have fixed the javadoc comments as the definition. Could you review this fix? Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7041 From rkennke at openjdk.java.net Tue Jan 18 08:39:30 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 18 Jan 2022 08:39:30 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [ ] Linux x86_64 fastdebug `tier3` Marked as reviewed by rkennke (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From rkennke at openjdk.java.net Tue Jan 18 08:39:30 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 18 Jan 2022 08:39:30 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 22:26:31 GMT, Aleksey Shipilev wrote: > > One additional improvement would be to change r.get() == null to r.refersTo(null) to check for cleared reference, that avoids reviving the referent, e.g. in SATB GCs. I leave that up to you. > > I think that does not work, because we want to strongly reference the `val` for eventual return. Ah right. Looks ok then! ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From myano at openjdk.java.net Tue Jan 18 09:07:27 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 18 Jan 2022 09:07:27 GMT Subject: Integrated: 8278892: java.naming module description is missing @uses tags to document the services that it uses In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 05:48:26 GMT, Masanori Yano wrote: > I have fixed the javadoc comments as the definition. Could you review this fix? This pull request has now been integrated. Changeset: 94522626 Author: Masanori Yano Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/945226265234b790b175ea312f7af1126984db68 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8278892: java.naming module description is missing @uses tags to document the services that it uses Reviewed-by: aefimov, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7041 From redestad at openjdk.java.net Tue Jan 18 10:15:52 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 18 Jan 2022 10:15:52 GMT Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes Message-ID: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. The inefficiency is that this test is quite branchy: `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: `if ((b1 & 0xfe) == 0xc2 && ...` This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: Benchmark (charsetName) Mode Cnt Score Error Units StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op ------------- Commit messages: - 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes - Align StringDecode microbenchmark with StringEncode Changes: https://git.openjdk.java.net/jdk/pull/7122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280124 Stats: 139 lines in 2 files changed: 93 ins; 34 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7122/head:pull/7122 PR: https://git.openjdk.java.net/jdk/pull/7122 From redestad at openjdk.java.net Tue Jan 18 10:44:28 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 18 Jan 2022 10:44:28 GMT Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes In-Reply-To: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> Message-ID: <-GS9pKTbOX4ix8lLJG1EzqCnHFZ4UORUhDjWUWOx100=.710be725-bb5f-49f8-9dda-f2b6e4b21737@github.com> On Tue, 18 Jan 2022 10:08:35 GMT, Claes Redestad wrote: > This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. > > The inefficiency is that this test is quite branchy: > > `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` > > Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: > > `if ((b1 & 0xfe) == 0xc2 && ...` > > This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: > > > Benchmark (charsetName) Mode Cnt Score Error Units > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op > > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op On a microbenchmark that zooms in on the logical predicate the speed-up is closer to 2x. This seems like a transformation a JIT could do automatically. gcc and clang doesn't do it, but icc seem to pull it off (as tested via godbolt.org). It's unclear if this is common enough to motivate such enhancement work, but it might be of academic interest to attempt it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7122 From jlaskey at openjdk.java.net Tue Jan 18 13:13:28 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 18 Jan 2022 13:13:28 GMT Subject: RFR: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote: > Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. The first three tests allocate (3 x ) two 2G arrays. Thinking that 5G is cutting it close. ------------- PR: https://git.openjdk.java.net/jdk/pull/7086 From jdk at fiolino.de Tue Jan 18 14:43:33 2022 From: jdk at fiolino.de (Michael Kuhlmann) Date: Tue, 18 Jan 2022 15:43:33 +0100 Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality In-Reply-To: References: Message-ID: Hi Steven! Sorry for coming back so lately; the main reason is that I can't answer your question. The issue you are describing indeed is a bit weird, and I can only speculate that it's like this because LambdaMetaFactory was mainly designed to be used in bootstrap methods for invokedynamic calls. So the checks are probably more restrictive than it should be when being used in standard Java code. But I'm curious about your motivation on using Lambdas at all. Of course, I don't have detailed insights and may miss some important context. Maybe my idea is completely wrong and nonsense; in that case I apologize for being so intrusive. But I was already wondering in the past why Jackson is using bytecode generation when simple MethodHandle combinations would be much easier to use. Lambdas like Function and BiConsumer seem to be a bad choice for me. There are two main downsides to it: - LambdaMetaFactory only accepts DirectMethodHandles. At least it allows simple type conversions as autoboxing and hierarchical castings, but that's it. Even a simple conversion from a String input (what you probably have when parsing a JSON structure) to a numeric value is impossible to integrate. - I assume you plan to iterate over the generated lambdas. In this case, Hotspot won't be able to optimize much because each Function/BiConsumer has a different implementation. It's impossible to predict much or even inline much. I would expect the performance to be much lower than the current one. Why not just concatenating MethodHandles directly? The strategy could be as the following: - Use filterArguments to make the getter's return type and the setter's argument convertable - Use filterArguments again to directly inject the getter into the setter's argument; so getter and setter will merge into one "transfer" handle - Use foldArguments to consecutively perform the transfer handle for each attribute; the resulting handle will transfer all attributes from source to destination - Use foldArgument again with MethodHandles::identity to let this transfer handle return its argument - And again, use foldArguments with the constructor handle to convert the resulting handle into a simple one-argument-handle expecting the source as a parameter and the newly creation target element as the return value. - Use such a handle also for type conversion of nested Pojos (for to-many relations, you have to be creative). As a result, you will have only one simple MethodHandle to convert the whole structure at once. As a background, back in times I was writing a library to convert Solr result objects to standard Pojos. The main logic was to convert Maps to nested Pojos and vice versa. I used exactly that strategy. It as fun, much better than solving Sudoku ;), and it worked well even with Java 8 features. With the new loop and iterate handles introduced with Java 9, you have even more options. Really, I'm curious if this could be an approach for Jackson. Or if not, what could be the obstacles. On 1/12/22 9:56 PM, Steven Schlansker wrote: > Hi core-libs-dev, > > I am maintaining a module for the popular Jackson JSON library that attempts to simplify code-generation code without losing performance. > Long ago, it was a huge win to code-generate custom getter / setter / field accessors rather than use core reflection. Now, the gap is closing a lot with MethodHandles, but there still seems to be some benefit. > > The previous approach used for code generation relied on the CGLib + ASM libraries, which as I am sure you know leads to horrible-to-maintain code since you essentially write bytecode directly. > Feature development basically stopped because writing out long chains of `visitVarInsn(ASTORE, 3)` and the like scares off most contributors, myself included. > > As an experiment, I started to port the custom class generation logic to use LambdaMetafactory. The idea is to use the factory to generate `Function` getter and `BiConsumer` setter implementations. > Then, use those during (de)serialization to access or set data. Eventually hopefully the JVM will inline, removing all (?) reflection overhead. > > The invocation looks like: > var lookup = MethodHandles.privateLookupIn(targetClass, MethodHandles.lookup()); // allow non-public access > var getter = lookup.unreflect(someGetterMethod); > LambdaMetafactory.metafactory( > lookup, > "apply", > methodType(Function.class), > methodType(Object.class, Object.class), > getter, > getter.type()) > > This works well for classes from the same classloader. However, once you try to generate lambdas with implementations loaded from a different classloader, you run into a check in the AbstractValidatingLambdaMetafactory constructor: > > if (!caller.hasFullPrivilegeAccess()) { > throw new LambdaConversionException(String.format( > "Invalid caller: %s", > caller.lookupClass().getName())); > } > > The `privateLookupIn` call seems to drop MODULE privilege access when looking across ClassLoaders. This appears to be because the "unnamed module" differs between a ClassLoader and its child. > This happens without the use of modulepath at all, only classpath, where I would not expect module restrictions to be in play. > Through some experimentation, I discovered that while I cannot call the LambdaMetafactory with this less-privileged lookup, I am still allowed to call defineClass. > > So, I compile a simple class: > > package ; > class AccessCracker { static final Lookup LOOKUP = MethodHandles.lookup(); } > > and inject it into the target class's existing package: > > lookup = lookup.defineClass(compiledBytes).getField("LOOKUP").get(null); > > and now I have a full privileged lookup into the target classloader, and the Metafactory then seems to generate lambdas without complaint. > > This workaround seems to work well, although it's a bummer to have to generate and inject these dynamic accessor classes. > It feels inconsistent that on one hand my Lookup is not powerful enough to generate a simple call-site with the Metafactory, > but at the same time it is so powerful that I can load arbitrary bytecode into the target classloader, and thus indirectly do what I wanted to do in the first place (with a fair bit more work) > > There's a bit of additional context here: > https://github.com/FasterXML/jackson-modules-base/issues/138 > https://github.com/FasterXML/jackson-modules-base/pull/162/files > > Any chance the Metafactory might become powerful enough to generate call sites even across such unnamed Modules in a future release? Or even more generally across arbitrary Modules, if relevant access checks pass? > > I'm also curious for any feedback on the overall approach of using the Metafactory, perhaps I am way off in the weeds, and should just trust MethodHandles to perform well if you use invokeExact :) JMH does seem to show some benefit though especially with Graal compiler. > > Thanks a bunch for any thoughts, > Steven Schlansker > From rriggs at openjdk.java.net Tue Jan 18 15:39:31 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 18 Jan 2022 15:39:31 GMT Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes In-Reply-To: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> Message-ID: On Tue, 18 Jan 2022 10:08:35 GMT, Claes Redestad wrote: > This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. > > The inefficiency is that this test is quite branchy: > > `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` > > Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: > > `if ((b1 & 0xfe) == 0xc2 && ...` > > This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: > > > Benchmark (charsetName) Mode Cnt Score Error Units > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op > > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7122 From alanb at openjdk.java.net Tue Jan 18 15:44:29 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 Jan 2022 15:44:29 GMT Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes In-Reply-To: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> Message-ID: On Tue, 18 Jan 2022 10:08:35 GMT, Claes Redestad wrote: > This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. > > The inefficiency is that this test is quite branchy: > > `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` > > Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: > > `if ((b1 & 0xfe) == 0xc2 && ...` > > This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: > > > Benchmark (charsetName) Mode Cnt Score Error Units > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op > > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7122 From aturbanov at openjdk.java.net Tue Jan 18 15:52:31 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 18 Jan 2022 15:52:31 GMT Subject: Integrated: 8280010: Remove double buffering of InputStream for Properties.load In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote: > `Properties.load` uses `java.util.Properties.LineReader`. LineReader already buffers input stream. Hence wrapping InputStream in BufferedInputStream is redundant. This pull request has now been integrated. Changeset: 9eb50a5e Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/9eb50a5ee4a069fbb248748ebee09132e2450420 Stats: 30 lines in 8 files changed: 0 ins; 11 del; 19 mod 8280010: Remove double buffering of InputStream for Properties.load Reviewed-by: amenkov, sspitsyn, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/7021 From rriggs at openjdk.java.net Tue Jan 18 16:05:00 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 18 Jan 2022 16:05:00 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread Message-ID: The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. The result is retention of the class loader. The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. The test verifies that the process reaper threads have a null context classloader. ------------- Commit messages: - Remove unnecessary compilation option - 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread Changes: https://git.openjdk.java.net/jdk/pull/7131/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7131&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279488 Stats: 103 lines in 3 files changed: 85 ins; 6 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7131.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7131/head:pull/7131 PR: https://git.openjdk.java.net/jdk/pull/7131 From redestad at openjdk.java.net Tue Jan 18 16:27:11 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 18 Jan 2022 16:27:11 GMT Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes [v2] In-Reply-To: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> Message-ID: > This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. > > The inefficiency is that this test is quite branchy: > > `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` > > Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: > > `if ((b1 & 0xfe) == 0xc2 && ...` > > This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: > > > Benchmark (charsetName) Mode Cnt Score Error Units > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op > > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Rename and reorder latin1 micro ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7122/files - new: https://git.openjdk.java.net/jdk/pull/7122/files/926c32bf..e4b6c40a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7122&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7122&range=00-01 Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7122/head:pull/7122 PR: https://git.openjdk.java.net/jdk/pull/7122 From naoto at openjdk.java.net Tue Jan 18 17:23:26 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 Jan 2022 17:23:26 GMT Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes [v2] In-Reply-To: References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> Message-ID: On Tue, 18 Jan 2022 16:27:11 GMT, Claes Redestad wrote: >> This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. >> >> The inefficiency is that this test is quite branchy: >> >> `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` >> >> Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: >> >> `if ((b1 & 0xfe) == 0xc2 && ...` >> >> This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: >> >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op >> >> StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Rename and reorder latin1 micro Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7122 From myano at openjdk.java.net Tue Jan 18 18:24:40 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 18 Jan 2022 18:24:40 GMT Subject: Integrated: 8272746: ZipFile can't open big file (NegativeArraySizeException) In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 10:55:08 GMT, Masanori Yano wrote: > Could you please review the JDK-8272746 bug fixes? > Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. > It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. > In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. This pull request has now been integrated. Changeset: 848b16a3 Author: Masanori Yano Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/848b16a3f933c1cffbce93337a5d9b4e48ce4b45 Stats: 92 lines in 2 files changed: 92 ins; 0 del; 0 mod 8272746: ZipFile can't open big file (NegativeArraySizeException) Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/6927 From rriggs at openjdk.java.net Tue Jan 18 18:25:32 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 18 Jan 2022 18:25:32 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Can a test be written to verify the correct handling of nulls. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Tue Jan 18 18:39:41 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 Jan 2022 18:39:41 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases Message-ID: While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. Additional testing: - [x] Linux x86_64 fastdebug, affected test still passes - [x] Linux x86_32 fastdebug, affected test still passes - [ ] Linux AArch64 fastdebug, affected test still passes - [ ] Linux PPC64 fastdebug, affected test still passes ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/7132/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7132&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280166 Stats: 88 lines in 1 file changed: 62 ins; 0 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/7132.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7132/head:pull/7132 PR: https://git.openjdk.java.net/jdk/pull/7132 From shade at openjdk.java.net Tue Jan 18 19:03:33 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 Jan 2022 19:03:33 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 18:22:26 GMT, Roger Riggs wrote: > Can a test be written to verify the correct handling of nulls. `java.io.ClassCache` is not public (for a reason), I struggle to find a way to access it from a jtreg test... ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From redestad at openjdk.java.net Tue Jan 18 19:31:32 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 18 Jan 2022 19:31:32 GMT Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes [v2] In-Reply-To: References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> Message-ID: On Tue, 18 Jan 2022 16:27:11 GMT, Claes Redestad wrote: >> This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. >> >> The inefficiency is that this test is quite branchy: >> >> `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` >> >> Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: >> >> `if ((b1 & 0xfe) == 0xc2 && ...` >> >> This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: >> >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op >> >> StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Rename and reorder latin1 micro Thanks for reviewing, everyone! ------------- PR: https://git.openjdk.java.net/jdk/pull/7122 From redestad at openjdk.java.net Tue Jan 18 19:31:32 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 18 Jan 2022 19:31:32 GMT Subject: Integrated: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes In-Reply-To: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> Message-ID: On Tue, 18 Jan 2022 10:08:35 GMT, Claes Redestad wrote: > This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. > > The inefficiency is that this test is quite branchy: > > `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` > > Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: > > `if ((b1 & 0xfe) == 0xc2 && ...` > > This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: > > > Benchmark (charsetName) Mode Cnt Score Error Units > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op > > StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op This pull request has now been integrated. Changeset: e314a4cf Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/e314a4cfda30cc680b3f0aef8c62b75ff81bdbb1 Stats: 139 lines in 2 files changed: 93 ins; 34 del; 12 mod 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes Reviewed-by: rriggs, alanb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7122 From cjplummer at openjdk.java.net Tue Jan 18 19:41:26 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 18 Jan 2022 19:41:26 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote: > While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test still passes > - [ ] Linux AArch64 fastdebug, affected test still passes > - [ ] Linux PPC64 fastdebug, affected test still passes test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 326: > 324: > 325: public static void main(String[] args)throws Throwable { > 326: new GetObjectSizeIntrinsicsTest(args[0], (args.length >= 2 ? args[1] : "")).runTest(); Shouldn't this be `args.length == 2`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7132 From rriggs at openjdk.java.net Tue Jan 18 20:10:22 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 18 Jan 2022 20:10:22 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` It may not be worth it. If not, add the label "noreg-hard". It is possible for add to the test description the modules to be opened: * @modules java.base/java.io:open jtreg will add the appropriate command line args when it is compiled and run. There are various examples in existing test/jdk/java/io... tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From aturbanov at openjdk.java.net Tue Jan 18 21:02:40 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 18 Jan 2022 21:02:40 GMT Subject: RFR: 8280174: Possible NPE in Thread.dispatchUncaughtException Message-ID: <6ukocdm79dKe2debIMO2ScgE56c4rXK8kFM5wNG38E4=.128081a2-2758-4e53-b84b-4c10f1ac4aca@github.com> Method `Thread.dispatchUncaughtException` (called by VM) uses result of of `getUncaughtExceptionHandler`. Field `uncaughtExceptionHandler` is volatile and can be changed by another Thread. Which could lead to NPE. https://github.com/openjdk/jdk/blob/7b6738fa02023825ed9e602555bd5ed2b87a6ca6/src/java.base/share/classes/java/lang/Thread.java#L2007-L2009 Read field to local variable to avoid double volatile read. ------------- Commit messages: - [PATCH] Read volatile field uncaughtExceptionHandler only once to avoid race Changes: https://git.openjdk.java.net/jdk/pull/7117/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7117&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280174 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7117.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7117/head:pull/7117 PR: https://git.openjdk.java.net/jdk/pull/7117 From john.r.rose at oracle.com Tue Jan 18 21:28:29 2022 From: john.r.rose at oracle.com (John Rose) Date: Tue, 18 Jan 2022 13:28:29 -0800 Subject: RFR: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes In-Reply-To: <-GS9pKTbOX4ix8lLJG1EzqCnHFZ4UORUhDjWUWOx100=.710be725-bb5f-49f8-9dda-f2b6e4b21737@github.com> References: <95vGWqtffiOSMzHIZT64rsxrCCyQ1Q6VZqhJHC4fsFA=.7867b213-0e32-4c16-9c27-7624940ab786@github.com> <-GS9pKTbOX4ix8lLJG1EzqCnHFZ4UORUhDjWUWOx100=.710be725-bb5f-49f8-9dda-f2b6e4b21737@github.com> Message-ID: <9D9454AA-7517-4F34-86C7-A2ADBFDD1859@oracle.com> It?s kind of sad that you have to do this by hand. The JVM should recognize that those back-to-back if statements (in the bytecode) can be combined into a non-branching O(1) test. One item on my (very long) wish list for the JVM is giving more comprehensive attention to the task of testing membership in small finite sets. This one asks whether a given byte is one of two values, where they happen to be consecutive and also have almost the same bit pattern. A more general version of the problem would be any switch of this form: switch (x) { case 2: case 3: case 5: case 7: case 16: default: return false; } As you can see, this is again a test for membership in a small, statically determined set. As long as the static set is ?small enough? (a flexible definition) there is always a way that is ?very fast? (flexible again) to detect set membership, and in particular faster than a branch tree (unless you know which branch is very likely to be taken). The ?common bad? case is having to generate a small perfect hash function, based on a multiply. The best case is an ad hoc detection of an arithmetic or bitwise pattern, as you have done here by hand. If the JVM had such a set-test generator, it could (a) turn branch nests (from switches or from random user code) into O(1) set tests, and (b) also supply a method handle factory for them, which would be a very useful way to translate indy-mediated discrimination trees that underly pattern-matching switches. Also it could translate character class tests in the regex package. (I started thinking about this long ago when staring at hand-written switches in Java code that implement character classes.) ? John On 18 Jan 2022, at 2:44, Claes Redestad wrote: > On Tue, 18 Jan 2022 10:08:35 GMT, Claes Redestad wrote: > >> This resolves minor inefficiency in the fast-path for decoding latin-1 chars from UTF-8. I also took the opportunity to refactor the StringDecode microbenchmark to align with recent changes to the StringEncode micro. >> >> The inefficiency is that this test is quite branchy: >> >> `if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && ...` >> >> Since the two constant bytes differ only on the lowest bit this can be transformed to this, saving us a branch: >> >> `if ((b1 & 0xfe) == 0xc2 && ...` >> >> This provides a small speed-up on microbenchmarks where the input can be internally encoded as latin1: >> >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2283.591 ? 12.332 ns/op >> >> StringDecode.decodeLatin1LongStart UTF-8 avgt 50 2165.984 ? 13.136 ns/op > > On a microbenchmark that zooms in on the logical predicate the speed-up is closer to 2x. This seems like a transformation a JIT could do automatically. gcc and clang doesn't do it, but icc seem to pull it off (as tested via godbolt.org). It's unclear if this is common enough to motivate such enhancement work, but it might be of academic interest to attempt it. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7122 From asemenyuk at openjdk.java.net Tue Jan 18 22:10:09 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 18 Jan 2022 22:10:09 GMT Subject: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux Message-ID: Add missing quotes to `%if` expressions in spec template. Required by rpmbuild 4.16.0 ------------- Commit messages: - 8257434: jpackage fails to create rpm on Fedora Linux Changes: https://git.openjdk.java.net/jdk/pull/1551/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1551&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257434 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1551.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1551/head:pull/1551 PR: https://git.openjdk.java.net/jdk/pull/1551 From almatvee at openjdk.java.net Tue Jan 18 22:10:10 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 18 Jan 2022 22:10:10 GMT Subject: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk wrote: > Add missing quotes to `%if` expressions in spec template. Required by rpmbuild 4.16.0 Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1551 From herrick at openjdk.java.net Tue Jan 18 22:10:12 2022 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 18 Jan 2022 22:10:12 GMT Subject: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk wrote: > Add missing quotes to `%if` expressions in spec template. Required by rpmbuild 4.16.0 looks good ------------- Marked as reviewed by herrick (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1551 From asemenyuk at openjdk.java.net Tue Jan 18 22:10:12 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 18 Jan 2022 22:10:12 GMT Subject: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk wrote: > Add missing quotes to `%if` expressions in spec template. Required by rpmbuild 4.16.0 @sashamatveev @andyherrick please review ------------- PR: https://git.openjdk.java.net/jdk/pull/1551 From asemenyuk at openjdk.java.net Tue Jan 18 22:10:13 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 18 Jan 2022 22:10:13 GMT Subject: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk wrote: > Add missing quotes to `%if` expressions in spec template. Required by rpmbuild 4.16.0 This pull request has now been integrated. Changeset: 541c7f74 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/541c7f74bbe0ffbacfa802e9e0d6cb6c63d81b10 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8257434: jpackage fails to create rpm on Fedora Linux Reviewed-by: almatvee, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/1551 From darcy at openjdk.java.net Tue Jan 18 23:31:50 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 18 Jan 2022 23:31:50 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString Message-ID: While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 ------------- Commit messages: - JDK-8280168 Add Objects.toDefaultString Changes: https://git.openjdk.java.net/jdk/pull/7139/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280168 Stats: 35 lines in 2 files changed: 32 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From stevenschlansker at gmail.com Wed Jan 19 01:22:45 2022 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Tue, 18 Jan 2022 17:22:45 -0800 Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality In-Reply-To: <30441222.11446506.1642086303584.JavaMail.zimbra@u-pem.fr> References: <30441222.11446506.1642086303584.JavaMail.zimbra@u-pem.fr> Message-ID: <801F8A2E-A722-4A34-A284-7C1EC3F19F5C@gmail.com> > On Jan 13, 2022, at 7:05 AM, Remi Forax wrote: > > ----- Original Message ----- >> From: "Steven Schlansker" >> To: "core-libs-dev" >> Sent: Wednesday, January 12, 2022 9:56:30 PM >> Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality > >> Hi core-libs-dev, >> >> I am maintaining a module for the popular Jackson JSON library that attempts to >> simplify code-generation code without losing performance. >> Long ago, it was a huge win to code-generate custom getter / setter / field >> accessors rather than use core reflection. Now, the gap is closing a lot with >> MethodHandles, but there still seems to be some benefit. >> >> The previous approach used for code generation relied on the CGLib + ASM >> libraries, which as I am sure you know leads to horrible-to-maintain code since >> you essentially write bytecode directly. > > I don't see the issue here, writing bytecodes in not that hard :) Everything I write could be done in assembly, yet somehow I keep coming back to Java :) > >> Feature development basically stopped because writing out long chains of >> `visitVarInsn(ASTORE, 3)` and the like scares off most contributors, myself >> included. > > yes, sadly known issue, generating assembly code even a highlevel one like the Java byetcode by hands require a niche knowledge which sadly is rarely teached at university anymore (and let's not talked about bootcamp). > >> >> As an experiment, I started to port the custom class generation logic to use >> LambdaMetafactory. The idea is to use the factory to generate `Function> T>` getter and `BiConsumer` setter implementations. > > If you want to make the serailization/deserialization to JSON fast you will mostly battle two things, > - polymorphic call site, a call that can call some many different implementations that the VM will not try to inline, > usually the trick is to just have one of such call to take care of the different kind of objects. > - boxing, that kind of code tends to abstract over any values, but boxing means allocation if there is no inlining. > > For me, it means that you want two specialized codes, the decoder that switches over the keys and call the correct setter and the encoder that calls the getters in sequence. > > Trying to abstract over getters and setters is a step too far because you loose the benefit to write a code specific to a peculiar class. Yes, this is a good point. I mostly copied the existing code-gen approach which behaved this way. I should go back and see if I can generate the more full featured coders and decoders. We do avoid boxing by using primitive specializations for our generated interface types, at least for the common primitive types. > I suppose you try to use the method handles directly with invokeExact() if you are able to remove the boxing > or with invoke() if not ? > > Because it's not clear to me why you want to use the LambdaMetafactory ? At the time it seemed to be significantly faster than non-static MethodHandles, and also faster than old-school reflection. Ref: https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html I wrote some simple benchmarks that confirmed that it's almost as fast as Jackson's older direct code-gen support: https://github.com/FasterXML/jackson-modules-base/tree/2.14/blackbird/benchmarks The results were even better with Graal's compiler (for some benchmarks). I haven't verified that all of the above is still true as of Java 17+, so my next step is to re-run the performance experiments with a more modern JVM. I expect there's been many optimizations around MethodHandle.invoke and friends since I ran my benchmark. Maybe it's the case that there is no longer a performance benefit to using LambdaMetafactory over (non-static) MethodHandle invoke, or if we can convert our code to use invokeExact. > [...] > >> >> I'm also curious for any feedback on the overall approach of using the >> Metafactory, perhaps I am way off in the weeds, and should just trust >> MethodHandles to perform well if you use invokeExact :) JMH does seem to show >> some benefit though especially with Graal compiler. >> >> Thanks a bunch for any thoughts, >> Steven Schlansker > > R?mi From stevenschlansker at gmail.com Wed Jan 19 01:23:00 2022 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Tue, 18 Jan 2022 17:23:00 -0800 Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality In-Reply-To: References: Message-ID: <2B27D55C-2B75-4EB0-A50C-1CC467E403AF@gmail.com> > On Jan 18, 2022, at 6:43 AM, Michael Kuhlmann wrote: > > Hi Steven! > > Sorry for coming back so lately; the main reason is that I can't answer your question. The issue you are describing indeed is a bit weird, and I can only speculate that it's like this because LambdaMetaFactory was mainly designed to be used in bootstrap methods for invokedynamic calls. So the checks are probably more restrictive than it should be when being used in standard Java code. Thanks. I had a suspicion that this would be the answer :) > But I'm curious about your motivation on using Lambdas at all. Of course, I don't have detailed insights and may miss some important context. Maybe my idea is completely wrong and nonsense; in that case I apologize for being so intrusive. But I was already wondering in the past why Jackson is using bytecode generation when simple MethodHandle combinations would be much easier to use. > > Lambdas like Function and BiConsumer seem to be a bad choice for me. There are two main downsides to it: > - LambdaMetaFactory only accepts DirectMethodHandles. At least it allows simple type conversions as autoboxing and hierarchical castings, but that's it. Even a simple conversion from a String input (what you probably have when parsing a JSON structure) to a numeric value is impossible to integrate. Right, the optimization I have written is not so complete as to build the full conversion stack as MethodHandles. Essentially we are using it only to replace Method[Handle].invoke(), since at the time it was written both carried somewhat of a performance penalty: https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html Jackson's core implementation reads a stream of tokens, and given a Bean-like object, will react to properties by parsing values and calling a setter. The tokenizer already takes care of all conversions: there's a hand-rolled UTF8 parser that will emit primitives or String values from the token stream. This optimization only covers the "calling a setter" or "calling a getter" part of the process in response to tokens from the parser. We do have specializations for common primitives (int, long, double) to avoid boxing. So Jackson core will read a property name, deserialize e.g. a long or String or nested object, and then need to call a method on the object to store the (possibly primitive) value. > - I assume you plan to iterate over the generated lambdas. In this case, Hotspot won't be able to optimize much because each Function/BiConsumer has a different implementation. It's impossible to predict much or even inline much. I would expect the performance to be much lower than the current one. Interestingly, that wasn't what I found. At least as of Java 14, the Metafactory generation approach (as limited as my first pass was) was competitive with CGLib hand-generated code in many (but not all) cases, and significantly faster than Method.invoke: https://github.com/FasterXML/jackson-modules-base/tree/2.14/blackbird/benchmarks Unfortunately I don't have a MethodHandle.invokeExact comparison in that benchmark. I should go back and finish that work, and re-run it all on 17. If we can call non-static MethodHandles with little overhead, then any reason to use the Metafactory here goes away. I did try to explore how the inlining worked out using jitwatch but I ran into problems: https://github.com/AdoptOpenJDK/jitwatch/issues/282 > > Why not just concatenating MethodHandles directly? The strategy could be as the following: > - Use filterArguments to make the getter's return type and the setter's argument convertable > - Use filterArguments again to directly inject the getter into the setter's argument; so getter and setter will merge into one "transfer" handle > - Use foldArguments to consecutively perform the transfer handle for each attribute; the resulting handle will transfer all attributes from source to destination > - Use foldArgument again with MethodHandles::identity to let this transfer handle return its argument > - And again, use foldArguments with the constructor handle to convert the resulting handle into a simple one-argument-handle expecting the source as a parameter and the newly creation target element as the return value. > - Use such a handle also for type conversion of nested Pojos (for to-many relations, you have to be creative). > > As a result, you will have only one simple MethodHandle to convert the whole structure at once. > As a background, back in times I was writing a library to convert Solr result objects to standard Pojos. The main logic was to convert Maps to nested Pojos and vice versa. I used exactly that strategy. It as fun, much better than solving Sudoku ;), and it worked well even with Java 8 features. With the new loop and iterate handles introduced with Java 9, you have even more options. Cool! Yes, all the new MethodHandle factories are quite interesting. > Really, I'm curious if this could be an approach for Jackson. Or if not, what could be the obstacles. I think the problem here is just slightly different: your approach will copy from one Java object to another Java object, but what we are doing is reacting to a token stream and trying to bind it to Java objects with as little overhead as possible. > > > On 1/12/22 9:56 PM, Steven Schlansker wrote: >> Hi core-libs-dev, >> I am maintaining a module for the popular Jackson JSON library that attempts to simplify code-generation code without losing performance. >> Long ago, it was a huge win to code-generate custom getter / setter / field accessors rather than use core reflection. Now, the gap is closing a lot with MethodHandles, but there still seems to be some benefit. >> The previous approach used for code generation relied on the CGLib + ASM libraries, which as I am sure you know leads to horrible-to-maintain code since you essentially write bytecode directly. >> Feature development basically stopped because writing out long chains of `visitVarInsn(ASTORE, 3)` and the like scares off most contributors, myself included. >> As an experiment, I started to port the custom class generation logic to use LambdaMetafactory. The idea is to use the factory to generate `Function` getter and `BiConsumer` setter implementations. >> Then, use those during (de)serialization to access or set data. Eventually hopefully the JVM will inline, removing all (?) reflection overhead. >> The invocation looks like: >> var lookup = MethodHandles.privateLookupIn(targetClass, MethodHandles.lookup()); // allow non-public access >> var getter = lookup.unreflect(someGetterMethod); >> LambdaMetafactory.metafactory( >> lookup, >> "apply", >> methodType(Function.class), >> methodType(Object.class, Object.class), >> getter, >> getter.type()) >> This works well for classes from the same classloader. However, once you try to generate lambdas with implementations loaded from a different classloader, you run into a check in the AbstractValidatingLambdaMetafactory constructor: >> if (!caller.hasFullPrivilegeAccess()) { >> throw new LambdaConversionException(String.format( >> "Invalid caller: %s", >> caller.lookupClass().getName())); >> } >> The `privateLookupIn` call seems to drop MODULE privilege access when looking across ClassLoaders. This appears to be because the "unnamed module" differs between a ClassLoader and its child. >> This happens without the use of modulepath at all, only classpath, where I would not expect module restrictions to be in play. >> Through some experimentation, I discovered that while I cannot call the LambdaMetafactory with this less-privileged lookup, I am still allowed to call defineClass. >> So, I compile a simple class: >> package ; >> class AccessCracker { static final Lookup LOOKUP = MethodHandles.lookup(); } >> and inject it into the target class's existing package: >> lookup = lookup.defineClass(compiledBytes).getField("LOOKUP").get(null); >> and now I have a full privileged lookup into the target classloader, and the Metafactory then seems to generate lambdas without complaint. >> This workaround seems to work well, although it's a bummer to have to generate and inject these dynamic accessor classes. >> It feels inconsistent that on one hand my Lookup is not powerful enough to generate a simple call-site with the Metafactory, >> but at the same time it is so powerful that I can load arbitrary bytecode into the target classloader, and thus indirectly do what I wanted to do in the first place (with a fair bit more work) >> There's a bit of additional context here: >> https://github.com/FasterXML/jackson-modules-base/issues/138 >> https://github.com/FasterXML/jackson-modules-base/pull/162/files >> Any chance the Metafactory might become powerful enough to generate call sites even across such unnamed Modules in a future release? Or even more generally across arbitrary Modules, if relevant access checks pass? >> I'm also curious for any feedback on the overall approach of using the Metafactory, perhaps I am way off in the weeds, and should just trust MethodHandles to perform well if you use invokeExact :) JMH does seem to show some benefit though especially with Graal compiler. >> Thanks a bunch for any thoughts, >> Steven Schlansker From rriggs at openjdk.java.net Wed Jan 19 02:25:31 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 19 Jan 2022 02:25:31 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 23:15:20 GMT, Joe Darcy wrote: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 src/java.base/share/classes/java/util/Objects.java line 170: > 168: * {@return a string equivalent to the string returned by {@code > 169: * Object.toString} if that method is not overridden} > 170: * The original Object.toString() invokes the hashCode() method. Perhaps the spec should indicate that it calls IdentityhashCode() instead of hashCode(). Though not incorrect, in Valhalla, Not all objects have identity and will need to different implementation. Are there any use cases in the JDK that will use this method? ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Wed Jan 19 02:57:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 19 Jan 2022 02:57:10 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v2] In-Reply-To: References: Message-ID: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/d05c6ddd..6ea4de5a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Wed Jan 19 02:57:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 19 Jan 2022 02:57:12 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 02:22:33 GMT, Roger Riggs wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/java/util/Objects.java line 170: > >> 168: * {@return a string equivalent to the string returned by {@code >> 169: * Object.toString} if that method is not overridden} >> 170: * > > The original Object.toString() invokes the hashCode() method. > Perhaps the spec should indicate that it calls IdentityhashCode() instead of hashCode(). > > Though not incorrect, in Valhalla, Not all objects have identity and will need to different implementation. > > Are there any use cases in the JDK that will use this method? I updated the return statement to say if hashCode isn't overridden either. The implSpec tag does explicitly mention identityHashCode already. There are a few instances of this sort of code in the JDK src directory already; I may include a refactoring of at least one of them in a future revision of the PR. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From mchung at openjdk.java.net Wed Jan 19 03:18:32 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 19 Jan 2022 03:18:32 GMT Subject: RFR: 8279921: Dump the .class file in jlink debug mode for any failure during transform() of a plugin In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 13:45:00 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8279921? > > The change here builds upon the debugging enhancement that was done in https://github.com/openjdk/jdk/pull/6696 to try and narrow down the problem behind intermittent failures on macos ARM systems. The previous change caught only `IllegalArgumentException` to dump the class file, but as seen in a recent failure, the exception type itself isn't guaranteed to be the same due to the nature of the issue. So, this commit catches `Exception` to dump the class file. Additionally, the change here also prints out the underlying `ResourcePoolEntry` type to see if that provides any additional hints on why the class content could end being corrupt. Looks okay to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7049 From iklam at openjdk.java.net Wed Jan 19 05:47:57 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 19 Jan 2022 05:47:57 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v4] In-Reply-To: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: > **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { > public static final SUNDAY = new Day("SUNDAY"); > public static final MONDAY = new Day("MONDAY"); ... > } > > > With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) > > **Fix:** > > During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. > > This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. > > **Verification:** > > To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt > > **Testing:** > > Passed Oracle CI tiers 1-4. WIll run tier 5 as well. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Use InstanceKlass::do_local_static_fields for some field iterations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6653/files - new: https://git.openjdk.java.net/jdk/pull/6653/files/6e160057..e27d3523 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=02-03 Stats: 150 lines in 2 files changed: 82 ins; 59 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/6653.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653 PR: https://git.openjdk.java.net/jdk/pull/6653 From iklam at openjdk.java.net Wed Jan 19 05:48:08 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 19 Jan 2022 05:48:08 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3] In-Reply-To: <7c6mh2-s3SkpfGG1WptyZsJjTfcDy1wX0Ll0713MLkU=.7df74a01-7ea5-49c1-9bda-f73798df3852@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> <7c6mh2-s3SkpfGG1WptyZsJjTfcDy1wX0Ll0713MLkU=.7df74a01-7ea5-49c1-9bda-f73798df3852@github.com> Message-ID: <4CLwCQdc_haGT_ueBQGZKzJVasGK26B6iYcO7VtOfAs=.02f3deb9-7ac7-45fd-9a7c-37b0fe4a8ea2@github.com> On Mon, 17 Jan 2022 18:36:35 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into 8275731-heapshared-enum >> - added exclusions needed by "java -Xshare:dump -ea -esa" >> - Comments from @calvinccheung off-line >> - 8275731: CDS archived enums objects are recreated at runtime > > src/hotspot/share/cds/cdsHeapVerifier.cpp line 165: > >> 163: >> 164: ResourceMark rm; >> 165: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) { > > Can this call instead > void InstanceKlass::do_local_static_fields(void f(fieldDescriptor*, Handle, TRAPS), Handle mirror, TRAPS) { > and have this next few lines in the function? I moved the code inside a new class CDSHeapVerifier::CheckStaticFields so I can call InstanceKlass::do_local_static_fields > src/hotspot/share/cds/cdsHeapVerifier.cpp line 254: > >> 252: InstanceKlass* ik = InstanceKlass::cast(k); >> 253: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) { >> 254: if (!fs.access_flags().is_static()) { > > same here. It only saves a couple of lines but then you can have the function outside this large function. You actually found a bug here. I am iterating over non-static fields and should walk the inherited fields as well. I changed the code to call InstanceKlass::do_nonstatic_fields() > src/hotspot/share/cds/cdsHeapVerifier.hpp line 52: > >> 50: mtClassShared, >> 51: HeapShared::oop_hash> _table; >> 52: > > Is this only used inside cdsHeapVerifier? if so it should be in the .cpp file. There's also an ArchiveableStaticFieldInfo. Not sure how they are related. This `_table` is part of the CDSHeapVerifier instance, which is stack allocated. So I need to declare it as part of the CDSHeapVerifier class declaration in the hpp file. > src/hotspot/share/cds/heapShared.cpp line 433: > >> 431: oop mirror = k->java_mirror(); >> 432: int i = 0; >> 433: for (JavaFieldStream fs(k); !fs.done(); fs.next()) { > > This seems like it should also use InstanceKlass::do_local_static_fields. Converting this to InstanceKlass::do_nonstatic_fields() is difficult because the loop body references 7 different variables declared outside of the loop. One thing I tried is to add a new version of do_nonstatic_fields2() that supports C++ lambdas. You can see my experiment from here: https://github.com/openjdk/jdk/compare/master...iklam:lambda-for-instanceklass-do_local_static_fields2?expand=1 I changed all my new code to use the do_nonstatic_fields2() function with lambda. > src/hotspot/share/cds/heapShared.cpp line 482: > >> 480: copy_open_objects(open_regions); >> 481: >> 482: CDSHeapVerifier::verify(); > > Should all this be DEBUG_ONLY ? I changed CDSHeapVerifier::verify() to a NOT_DEBUG_RETURN function. > src/hotspot/share/cds/heapShared.hpp line 236: > >> 234: oop _referrer; >> 235: oop _obj; >> 236: CachedOopInfo() :_subgraph_info(), _referrer(), _obj() {} > > Should these be initialized to nullptr? does this do this? These three fields are initialized with the default initializer (empty parenthesis) so they will be initialized to the null pointer. ------------- PR: https://git.openjdk.java.net/jdk/pull/6653 From iklam at openjdk.java.net Wed Jan 19 05:54:30 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 19 Jan 2022 05:54:30 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3] In-Reply-To: <7c6mh2-s3SkpfGG1WptyZsJjTfcDy1wX0Ll0713MLkU=.7df74a01-7ea5-49c1-9bda-f73798df3852@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> <7c6mh2-s3SkpfGG1WptyZsJjTfcDy1wX0Ll0713MLkU=.7df74a01-7ea5-49c1-9bda-f73798df3852@github.com> Message-ID: On Mon, 17 Jan 2022 19:22:23 GMT, Coleen Phillimore wrote: > I don't really know this code well enough to do a good code review. I had some comments though. Hi Coleen, thanks for taking a look. This PR has two major parts: 1. Check for inappropriate reference to static fields. This is mainly done in cdsHeapVerifier.cpp. These checks don't affect the contents of the CDS archive. They just print out warnings if problems are found. 2. Special initialization of enum classes. Essentially if any instance of an enum class `X` is archived, then `X::` will not be executed, and we'll take this path instead (in instanceKlass.cpp): // This is needed to ensure the consistency of the archived heap objects. if (has_archived_enum_objs()) { assert(is_shared(), "must be"); bool initialized = HeapShared::initialize_enum_klass(this, CHECK); if (initialized) { return; } } Could you check if (2) is correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/6653 From shade at openjdk.java.net Wed Jan 19 07:51:26 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 Jan 2022 07:51:26 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote: >> While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, affected test still passes >> - [x] Linux x86_32 fastdebug, affected test still passes >> - [x] Linux AArch64 fastdebug, affected test still passes >> - [x] Linux PPC64 fastdebug, affected test still passes > > test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 326: > >> 324: >> 325: public static void main(String[] args)throws Throwable { >> 326: new GetObjectSizeIntrinsicsTest(args[0], (args.length >= 2 ? args[1] : "")).runTest(); > > Shouldn't this be `args.length == 2`? `>= 2` is more future-proof, I think, as it checks that _at least_ two arguments exists, which allows to read `args[1]`. Accidental addition of third argument would not silently break the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7132 From shade at openjdk.java.net Wed Jan 19 08:22:59 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 Jan 2022 08:22:59 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v2] In-Reply-To: References: Message-ID: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - GC sanity test - NullValueTest - Merge branch 'master' into JDK-8280041-classcache-problems - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7092/files - new: https://git.openjdk.java.net/jdk/pull/7092/files/14835de6..88d23af1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=00-01 Stats: 1925 lines in 92 files changed: 1467 ins; 230 del; 228 mod Patch: https://git.openjdk.java.net/jdk/pull/7092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7092/head:pull/7092 PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Wed Jan 19 08:23:00 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 Jan 2022 08:23:00 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 20:07:10 GMT, Roger Riggs wrote: > It may not be worth it. If not, add the label "noreg-hard". Added. > It is possible for add to the test description the modules to be opened: > ``` > * @modules java.base/java.io:open > ``` > > jtreg will add the appropriate command line args when it is compiled and run. There are various examples in existing test/jdk/java/io... tests. It is not about modules protection, it is about the plain Java rule: the class is package-private, you cannot subclass from it, unless you are in the same package, period. In older Java days you would "just" put the test in the same package, but we cannot do it now, because that would be a split package and test code would refuse to load. But there is a way to inject `java.io` classes, apparently! I added two tests in two new commits. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Wed Jan 19 08:25:55 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 Jan 2022 08:25:55 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: References: Message-ID: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Test summary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7092/files - new: https://git.openjdk.java.net/jdk/pull/7092/files/88d23af1..49b852de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=01-02 Stats: 47 lines in 2 files changed: 1 ins; 34 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7092/head:pull/7092 PR: https://git.openjdk.java.net/jdk/pull/7092 From alanb at openjdk.java.net Wed Jan 19 08:34:28 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 Jan 2022 08:34:28 GMT Subject: RFR: 8280174: Possible NPE in Thread.dispatchUncaughtException In-Reply-To: <6ukocdm79dKe2debIMO2ScgE56c4rXK8kFM5wNG38E4=.128081a2-2758-4e53-b84b-4c10f1ac4aca@github.com> References: <6ukocdm79dKe2debIMO2ScgE56c4rXK8kFM5wNG38E4=.128081a2-2758-4e53-b84b-4c10f1ac4aca@github.com> Message-ID: On Mon, 17 Jan 2022 20:56:56 GMT, Andrey Turbanov wrote: > Method `Thread.dispatchUncaughtException` (called by VM) uses result of of `getUncaughtExceptionHandler`. Field `uncaughtExceptionHandler` is volatile and can be changed by another Thread. Which could lead to NPE. > https://github.com/openjdk/jdk/blob/7b6738fa02023825ed9e602555bd5ed2b87a6ca6/src/java.base/share/classes/java/lang/Thread.java#L2007-L2009 > Read field to local variable to avoid double volatile read. This looks okay. It is arguably an API bug that the UHE can be changed after another Thread after it has been started but too late to change that now. Should be rare to change another Thread's UHE to null but a bug none the less. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7117 From alanb at openjdk.java.net Wed Jan 19 09:23:31 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 Jan 2022 09:23:31 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 02:57:10 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by alanb (Reviewer). test/jdk/java/util/Objects/BasicObjectsTest.java line 148: > 146: Object o = new Object(){}; > 147: errors += (Objects.toDefaultString(o).equals(o.toString()))? 0 : 1; > 148: return errors; Another potential test is on an instance of a class that overrides toString(), that would ensure that toDefaultString() doesn't invoke toString. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From mbaesken at openjdk.java.net Wed Jan 19 09:25:40 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 19 Jan 2022 09:25:40 GMT Subject: RFR: JDK-8280157: wrong texts Falied in a couple of tests Message-ID: Very small change fixing wrong strings "Falied" in a couple of tests. ------------- Commit messages: - JDK-8280157 Changes: https://git.openjdk.java.net/jdk/pull/7142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7142&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280157 Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7142/head:pull/7142 PR: https://git.openjdk.java.net/jdk/pull/7142 From rkennke at openjdk.java.net Wed Jan 19 10:20:27 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 19 Jan 2022 10:20:27 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; >> - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Test summary Still looks good (even better!) to me. Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7092 From plevart at openjdk.java.net Wed Jan 19 10:38:32 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 19 Jan 2022 10:38:32 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; >> - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Test summary Hi, Sorry for late join. I'm monitoring core-libs-dev mailing list and didn't see the message there. I stumbled on this PR accidentally... I just have one comment. ------------- Changes requested by plevart (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7092 From plevart at openjdk.java.net Wed Jan 19 10:48:28 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 19 Jan 2022 10:48:28 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; >> - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Test summary So, this patch is fine for making ClassCache more robust as a re-usable component inside JDK (checking for non-null return of computeValue). The 2nd change, that apparently shields against unbounded accumulation of garbage, might not be enough in the sense that when garbage accumulated without bounds, there would be not progress. So before the patch, we would at least get an OOME and the loop would end. Now the loop could spin indefinitely. So perhaps we must rather prevent this from happening in some other way... I have an idea. Stay tuned. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Wed Jan 19 10:48:28 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 Jan 2022 10:48:28 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 10:42:02 GMT, Peter Levart wrote: > So, this patch is fine for making ClassCache more robust as a re-usable component inside JDK (checking for non-null return of computeValue). The 2nd change, that apparently shields against unbounded accumulation of garbage, might not be enough in the sense that when garbage accumulated without bounds, there would be not progress. So before the patch, we would at least get an OOME and the loop would end. Now the loop could spin indefinitely. So perhaps we must rather prevent this from happening in some other way... I have an idea. Stay tuned. I think playing the catch-up race with GC (which we will eventually win, IMO) is better than obscure OOME. Note this matches other places we do the weak-reference loops, for example in `MethodType`: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401 ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From aturbanov at openjdk.java.net Wed Jan 19 11:03:34 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 19 Jan 2022 11:03:34 GMT Subject: Integrated: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote: > Usages of primitive types should be preferred and makes code easier to read. > Similar cleanups: > 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop > 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset This pull request has now been integrated. Changeset: 5af7f258 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/5af7f258144d9f753ebe6ebfada42f33aaed108b Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod 8274811: Remove superfluous use of boxing in java.base Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From egahlin at openjdk.java.net Wed Jan 19 11:07:26 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 19 Jan 2022 11:07:26 GMT Subject: RFR: JDK-8280157: wrong texts Falied in a couple of tests In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken wrote: > Very small change fixing wrong strings "Falied" in a couple of tests. Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7142 From aivanov at openjdk.java.net Wed Jan 19 11:28:23 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 19 Jan 2022 11:28:23 GMT Subject: RFR: JDK-8280157: wrong texts Falied in a couple of tests In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken wrote: > Very small change fixing wrong strings "Falied" in a couple of tests. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7142 From mbaesken at openjdk.java.net Wed Jan 19 12:04:36 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 19 Jan 2022 12:04:36 GMT Subject: Integrated: JDK-8280157: wrong texts Falied in a couple of tests In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken wrote: > Very small change fixing wrong strings "Falied" in a couple of tests. This pull request has now been integrated. Changeset: 8931c122 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/8931c12258a39cabda2cd1b92f54afcb216b882e Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod 8280157: wrong texts Falied in a couple of tests Reviewed-by: egahlin, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/7142 From plevart at openjdk.java.net Wed Jan 19 13:14:38 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 19 Jan 2022 13:14:38 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: References: Message-ID: <3dyG3wqOhJEoKdMfPXUfe5rTQHgTXtQqCMP3pjpe9ms=.ce707548-e752-4aa8-a494-de97ce320e83@github.com> On Wed, 19 Jan 2022 10:44:57 GMT, Aleksey Shipilev wrote: > > So, this patch is fine for making ClassCache more robust as a re-usable component inside JDK (checking for non-null return of computeValue). The 2nd change, that apparently shields against unbounded accumulation of garbage, might not be enough in the sense that when garbage accumulated without bounds, there would be not progress. So before the patch, we would at least get an OOME and the loop would end. Now the loop could spin indefinitely. So perhaps we must rather prevent this from happening in some other way... I have an idea. Stay tuned. > > I think playing the catch-up race with GC (which we will eventually win, IMO) is better than obscure OOME. Note this matches other places we do the weak-reference loops, for example in `MethodType`: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401 I do think that processing enqueued references more promptly is a correct move, so I don't oppose this patch. I'm merely saying that the concern about indefinite growing of reference queue is the same as concern about indefinite looping. In normal circumstances neither would be a problem. But if we are considering special circumstances, we could as well fix both potential problems. For example, if construction of `CacheRef` object that stays referenced by ClassCache is guaranteed to be followed by at least one `.get()` invocation, the following variant of CacheRef would guarantee progress: private static class CacheRef extends SoftReference { private Class type; private T referent; CacheRef(T referent, ReferenceQueue queue, Class type) { super(referent, queue); this.referent = referent; this.type = type; } @Override public T get() { T referent = this.referent; if (referent == null) { return super.get(); } else { this.referent = null; return referent; } } } WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From plevart at openjdk.java.net Wed Jan 19 13:44:22 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 19 Jan 2022 13:44:22 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: <3dyG3wqOhJEoKdMfPXUfe5rTQHgTXtQqCMP3pjpe9ms=.ce707548-e752-4aa8-a494-de97ce320e83@github.com> References: <3dyG3wqOhJEoKdMfPXUfe5rTQHgTXtQqCMP3pjpe9ms=.ce707548-e752-4aa8-a494-de97ce320e83@github.com> Message-ID: On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote: > Note this matches other places we do the weak-reference loops, for example in `MethodType`: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401 This one does not have the same problem. It does guarantee progress. But it has another problem. This variant busy-loops while waiting for cleared WeakRefefence to be eventually enqueued by GC / Reference enqueue-ing thread. It could, in addition, pro-actively remove the entry from the map as soon as it finds the WeakReference cleared (with Map.remove(key, value)). ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From robm at openjdk.java.net Wed Jan 19 15:17:43 2022 From: robm at openjdk.java.net (Rob McKenna) Date: Wed, 19 Jan 2022 15:17:43 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: Message-ID: <95CuJQqoVfJOEdYeRhgTJbLqdQwyyGvBlDR2WoyIsfg=.2230a07d-ad5f-457f-ac33-283e732cda25@github.com> On Thu, 13 Jan 2022 01:02:38 GMT, Mark Sheppard wrote: >> Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: >> >> Allow the test to pass on MacOSX > > src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java line 54: > >> 52: * @param timeout the connection timeout >> 53: */ >> 54: public abstract PooledConnection createPooledConnection(PoolCallback pcb, long timeout) > > why not use int timeout to be consistent with existing code ? > You've been required to "squash" it into an int in the factory ? IIRC this was a request from an earlier review. (long being the standard throughout other new public apis) I'm happy with either, but int does avoid the trouble of casting. ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From michaelm at openjdk.java.net Wed Jan 19 15:40:35 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 15:40:35 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: On Mon, 17 Jan 2022 13:49:35 GMT, Daniel Fuchs wrote: >> I vote for "jdk.https.tls.cbt" > >> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? > > AFAICS this file documents properties used by the networking task - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property) Okay, good idea to document it in the properties file. Also, I think "jdk.https.tls.cbt" is a reasonable name for the property. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Wed Jan 19 15:40:36 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 15:40:36 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_h8s8kO7yYet_L3fSRZtH_l-L7dqq12kWX-tFO6i7B4=.7d230b0c-8363-49d7-9f31-0d2c82fc56d9@github.com> Message-ID: <0_k-W6vPKT_r3U_Tgj9-S8Dn2RxBIiMFsZ8vZI4p23E=.15d85a8b-5ca5-4cc4-a413-9c8a87c138f4@github.com> On Mon, 17 Jan 2022 13:44:06 GMT, Daniel Fuchs wrote: >> Shall we log a message if the value is not one of the 3 forms? > > Usually malformed values are just ignored - and the property takes its default value. But yes - s.n.w.h.HttpClient has a logger so it wouldn't be much effort to log it as a DEBUG trace for better diagnostic. Yes, I will log it using the same debug/logging mechanism already in the same source file.. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Wed Jan 19 15:40:36 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 15:40:36 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <5zco_5V9sMUkWNWNVmjFyvHNVkR5iZicq_0DBQWtRp4=.55489b7e-8f53-4c83-acd8-66141b5021af@github.com> On Sat, 15 Jan 2022 14:02:15 GMT, Michael Osipov wrote: >> I suggest moving the `TlsChannelBinding` class into `java.base/sun.security.util` since it's not only used by LDAP anymore. It's even not restricted to GSS-API. According to https://www.rfc-editor.org/rfc/rfc5056, "Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS-API applications". >> >> If so, you might need to modify the types of exceptions thrown in the class, and move the 2 final strings to some other class inside `java.security.sasl`. > > Seems like `com.sun.jndi.ldap.sasl.TlsChannelBinding` is not misplaced.... Okay, I'll look at doing this refactoring. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Wed Jan 19 15:57:36 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 19 Jan 2022 15:57:36 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: <95CuJQqoVfJOEdYeRhgTJbLqdQwyyGvBlDR2WoyIsfg=.2230a07d-ad5f-457f-ac33-283e732cda25@github.com> References: <95CuJQqoVfJOEdYeRhgTJbLqdQwyyGvBlDR2WoyIsfg=.2230a07d-ad5f-457f-ac33-283e732cda25@github.com> Message-ID: On Wed, 19 Jan 2022 15:13:57 GMT, Rob McKenna wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java line 54: >> >>> 52: * @param timeout the connection timeout >>> 53: */ >>> 54: public abstract PooledConnection createPooledConnection(PoolCallback pcb, long timeout) >> >> why not use int timeout to be consistent with existing code ? >> You've been required to "squash" it into an int in the factory ? > > IIRC this was a request from an earlier review. (long being the standard throughout other new public apis) I'm happy with either, but int does avoid the trouble of casting. Well I guess the request was "why not use long everywhere to avoid casting to int" ;-) But I'm happy with either too - as long as the place where you have a long (e.g obtained by substracting two nano times) and call a method that takes an int has the proper guards in place, and either assert/throws/floor or ceil if the assumptions are not met - provided that a comment explains why that particular alternative is selected. ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From michaelm at openjdk.java.net Wed Jan 19 16:12:34 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 16:12:34 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8R5s3jbp0uTJJ544lCrvRQrwJLt9y49invp7MFDBcXY=.a7ac57d3-0ecc-41f9-8608-41b145ec4ee3@github.com> Message-ID: <0ebQZroTY3tTQW9cy5g6Y9yTK_nv6CBRtr-ne3tEF6k=.c4f10a2c-2ff8-452a-8cfb-cffedc5f0249@github.com> On Wed, 19 Jan 2022 15:36:16 GMT, Michael McMahon wrote: >>> It's actually a purely system property rather than a Net property at the moment (same as the other spnego ones). Maybe, I should convert them all to net properties, so they can be documented/set in that file? >> >> AFAICS this file documents properties used by the networking stack - not necessarily net properties (e.g. java.net.preferIPv6Addresses is documented there but AFAICT it is a plain system property) > > Okay, good idea to document it in the properties file. Also, I think "jdk.https.tls.cbt" is a reasonable name for the property. Sorry, on reflection, something like "jdk.https.negotiate.cbt" might be better. There's no need for tls and https in the name and "negotiate" or "spnego" should be in it, but "negotiate" is probably better ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Wed Jan 19 17:12:31 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 17:12:31 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <4Tld3QrBk91X9ZBtF4Ad7DCiIfGD203YePBmy7FIAHs=.9964426c-6244-4818-8479-18044a833db1@github.com> On Fri, 14 Jan 2022 15:06:12 GMT, Daniel Fuchs wrote: > Have you been able to test this on a specific setup? Would be good to hear from @msheppar too. I have tested it with the server setup by Prajwal. Security SQE are looking into configuring a server with a similar setup which can be tested with an infra test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From psandoz at openjdk.java.net Wed Jan 19 17:31:34 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 Jan 2022 17:31:34 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7] In-Reply-To: References: Message-ID: <7Z3OWtjmUKq8zOP8IjbIeSImqWljCH7XsEV5FK1FIKg=.1e278f53-5e4e-4cd5-ad7d-a8b9668a08c9@github.com> On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote: >>> > embarrassingly parallelizable >>> >>> Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that. >> >> Ok, fair point, to avoid possible confusion I have removed "embarrassingly". I don't think we need to refer to other algorithms. > > Hi @PaulSandoz is there anything else that we need to do? Or is this in the hopper for Java 19 already? @kabutz please see comments from Joe on the [CSR](https://bugs.openjdk.java.net/browse/JDK-8278886), which should be easy to address (i can update the CSR after you make changes). ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From jbhateja at openjdk.java.net Wed Jan 19 17:38:25 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 19 Jan 2022 17:38:25 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > ? | ? | BASELINE AVX2 | WithOpt AVX2 | Gain (opt/baseline) | Baseline AVX3 | Withopt AVX3 | Gain (opt/baseline) > -- | -- | -- | -- | -- | -- | -- | -- > Benchmark | ARRAYLEN | Score (ops/ms) | Score (ops/ms) | ? | Score (ops/ms) | Score (ops/ms) | ? > FpRoundingBenchmark.test_round_double | 1024 | 518.532 | 1364.066 | 2.630630318 | 512.908 | 4292.11 | 8.368186887 > FpRoundingBenchmark.test_round_double | 2048 | 270.137 | 830.986 | 3.076165057 | 273.159 | 2459.116 | 9.002507697 > FpRoundingBenchmark.test_round_float | 1024 | 752.436 | 7780.905 | 10.34095259 | 752.49 | 9506.694 | 12.63364829 > FpRoundingBenchmark.test_round_float | 2048 | 389.499 | 4113.046 | 10.55983712 | 389.63 | 4863.673 | 12.48279907 > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Adding a test for scalar intrinsification. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/0fe01504..575d2935 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=00-01 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From mchung at openjdk.java.net Wed Jan 19 18:02:40 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 19 Jan 2022 18:02:40 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v2] In-Reply-To: References: Message-ID: <4Ij3RLoWcNekBjvgrF8oOPToP3tbNeR6EDaPV9cneZQ=.966afcd7-cd62-44c0-94a4-0777ced57f56@github.com> On Wed, 19 Jan 2022 02:57:10 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Looks good. I reviewed the CSR but please update the CSR with the updated spec. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Wed Jan 19 18:48:48 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 19 Jan 2022 18:48:48 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v3] In-Reply-To: References: Message-ID: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback to augment test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/6ea4de5a..a854766b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=01-02 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From vlivanov at openjdk.java.net Wed Jan 19 21:37:50 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 19 Jan 2022 21:37:50 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:38:25 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> ? | ? | BASELINE AVX2 | WithOpt AVX2 | Gain (opt/baseline) | Baseline AVX3 | Withopt AVX3 | Gain (opt/baseline) >> -- | -- | -- | -- | -- | -- | -- | -- >> Benchmark | ARRAYLEN | Score (ops/ms) | Score (ops/ms) | ? | Score (ops/ms) | Score (ops/ms) | ? >> FpRoundingBenchmark.test_round_double | 1024 | 518.532 | 1364.066 | 2.630630318 | 512.908 | 4292.11 | 8.368186887 >> FpRoundingBenchmark.test_round_double | 2048 | 270.137 | 830.986 | 3.076165057 | 273.159 | 2459.116 | 9.002507697 >> FpRoundingBenchmark.test_round_float | 1024 | 752.436 | 7780.905 | 10.34095259 | 752.49 | 9506.694 | 12.63364829 >> FpRoundingBenchmark.test_round_float | 2048 | 389.499 | 4113.046 | 10.55983712 | 389.63 | 4863.673 | 12.48279907 >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Adding a test for scalar intrinsification. There are already `RoundFloat`, `RoundDouble`, and `RoundDoubleMode` nodes defined. Though `RoundFloat` and `RoundDouble` are legacy nodes used only on x86-32, `RoundDoubleMode` supports multiple rounding modes and is amenable to auto-vectorization. What do you think about the following alternative? Reuse `RoundDoubleMode` (with a new rounding mode) and introduce `RoundFloatMode`. Special rounding rules is not the only peculiarity of `Math.round()`. It also converts the result to an integral type. It can be represented as `ConvF2I (RoundFloatMode f #rmode)` / `ConvD2L (RoundDoubleMode d #rmode)`. In scalar case, it can be matched as a single AD instruction. Auto-vectorizer can then convert it to `VectorCastF2X (RoundFloatModeV vf #rmode)` / `VectorCastD2X (RoundDoubleModeV vd #rmode)` and match it in a similar manner. test/hotspot/jtreg/compiler/c2/cr6340864/TestFloatVect.java line 33: > 31: * @run main/othervm -Xbatch -XX:CompileCommand=exclude,*::test() -Xmx128m -XX:MaxVectorSize=16 compiler.c2.cr6340864.TestFloatVect > 32: * @run main/othervm -Xbatch -XX:CompileCommand=exclude,*::test() -Xmx128m -XX:MaxVectorSize=32 compiler.c2.cr6340864.TestFloatVect > 33: * @run main/othervm -Xbatch -XX:CompileCommand=exclude,*::test() -XX:TieredStopAtLevel=2 -Xmx128m -XX:MaxVectorSize=32 compiler.c2.cr6340864.TestFloatVect What's the purpose of `-XX:TieredStopAtLevel=2` from testing perspective? ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From dholmes at openjdk.java.net Wed Jan 19 22:01:50 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 19 Jan 2022 22:01:50 GMT Subject: RFR: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote: > Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. Okay - lets see how it goes. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7086 From darcy at openjdk.java.net Wed Jan 19 22:12:51 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 19 Jan 2022 22:12:51 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:38:25 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> ? | ? | BASELINE AVX2 | WithOpt AVX2 | Gain (opt/baseline) | Baseline AVX3 | Withopt AVX3 | Gain (opt/baseline) >> -- | -- | -- | -- | -- | -- | -- | -- >> Benchmark | ARRAYLEN | Score (ops/ms) | Score (ops/ms) | ? | Score (ops/ms) | Score (ops/ms) | ? >> FpRoundingBenchmark.test_round_double | 1024 | 518.532 | 1364.066 | 2.630630318 | 512.908 | 4292.11 | 8.368186887 >> FpRoundingBenchmark.test_round_double | 2048 | 270.137 | 830.986 | 3.076165057 | 273.159 | 2459.116 | 9.002507697 >> FpRoundingBenchmark.test_round_float | 1024 | 752.436 | 7780.905 | 10.34095259 | 752.49 | 9506.694 | 12.63364829 >> FpRoundingBenchmark.test_round_float | 2048 | 389.499 | 4113.046 | 10.55983712 | 389.63 | 4863.673 | 12.48279907 >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Adding a test for scalar intrinsification. The testing for this PR doesn't look adequate to me. I don't see any testing for the values where the behavior of round has been redefined at points in the last decade. See JDK-8010430 and JDK-6430675, both of which have regression tests in the core libs area. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From michaelm at openjdk.java.net Wed Jan 19 22:20:47 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 22:20:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: changes after first review round ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/853ed4db..f2ee58ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=00-01 Stats: 111 lines in 7 files changed: 88 ins; 5 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Wed Jan 19 22:29:53 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 Jan 2022 22:29:53 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> Message-ID: <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com> On Wed, 19 Jan 2022 22:20:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > changes after first review round src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); > 132: } catch (ChannelBindingException e) { > 133: throw new SaslException(e.getMessage()); How about setting `e` as cause of new exception? In `TlsChannelBinding.java` the when the original exception was thrown (the 2nd throws) there was a cause. src/java.security.jgss/share/classes/module-info.java line 36: > 34: module java.security.jgss { > 35: requires java.naming; > 36: requires java.security.sasl; Can this be removed now? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From rriggs at openjdk.java.net Wed Jan 19 22:31:48 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 19 Jan 2022 22:31:48 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 18:48:48 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback to augment test. LGTM, thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7139 From jwilhelm at openjdk.java.net Thu Jan 20 00:40:42 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 00:40:42 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling - 8272058: 25 Null pointer dereference defect groups in 4 files - 8280234: AArch64 "core" variant does not build after JDK-8270947 - 8280155: [PPC64, s390] frame size checks are not yet correct - 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS - 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE - 8278417: Closed test fails after JDK-8276108 on aarch64 - 8274096: Improve decoding of image files - ... and 30 more: https://git.openjdk.java.net/jdk/compare/98d96a77...e0d83a07 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7151/files Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/7151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7151/head:pull/7151 PR: https://git.openjdk.java.net/jdk/pull/7151 From jwilhelm at openjdk.java.net Thu Jan 20 01:21:56 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 01:21:56 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 4616c13c Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5 Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7151 From prr at openjdk.java.net Thu Jan 20 01:37:48 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 Jan 2022 01:37:48 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote: > Method `Class.isAssignableFrom` is often used in form of: > > if (clazz.isAssignableFrom(obj.getClass())) { > Such condition could be simplified to more shorter and performarnt code > > if (clazz.isInstance(obj)) { > > Replacement is equivalent if it's known that `obj != null`. > In JDK codebase there are many such places. > > I tried to measure performance via JMH > > Class integerClass = Integer.class; > Class numberClass = Number.class; > > Object integerObject = 45666; > Object doubleObject = 8777d; > > @Benchmark > public boolean integerInteger_isInstance() { > return integerClass.isInstance(integerObject); > } > > @Benchmark > public boolean integerInteger_isAssignableFrom() { > return integerClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public boolean integerDouble_isInstance() { > return integerClass.isInstance(doubleObject); > } > > @Benchmark > public boolean integerDouble_isAssignableFrom() { > return integerClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberDouble_isInstance() { > return numberClass.isInstance(doubleObject); > } > > @Benchmark > public boolean numberDouble_isAssignableFrom() { > return numberClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberInteger_isInstance() { > return numberClass.isInstance(integerObject); > } > > @Benchmark > public boolean numberInteger_isAssignableFrom() { > return numberClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public void numberIntegerDouble_isInstance(Blackhole bh) { > bh.consume(numberClass.isInstance(integerObject)); > bh.consume(numberClass.isInstance(doubleObject)); > } > > @Benchmark > public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { > bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); > bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); > } > > `isInstance` is a bit faster than `isAssignableFrom` > > Benchmark Mode Cnt Score Error Units > integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op > integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op > integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op > numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op > integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op > integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op > numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op > numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op > numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op > numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op I've stared at the javadoc for Class.isAssignableFrom and Class.isInstance and if a non-null instance is used to get a non-null class they are PROBABLY the same but it is far from clear. The implementations of both are at least native and may be instrinsicified. The doc for Class.isAssignableFrom cites JLS 5.1.4 which in what I found is about primitives so I suspect it is woefully out of date https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.4 What client tests have you run that touch the code you are changing ? In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From jpai at openjdk.java.net Thu Jan 20 04:53:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 20 Jan 2022 04:53:50 GMT Subject: RFR: 8279921: Dump the .class file in jlink debug mode for any failure during transform() of a plugin In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 13:45:00 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8279921? > > The change here builds upon the debugging enhancement that was done in https://github.com/openjdk/jdk/pull/6696 to try and narrow down the problem behind intermittent failures on macos ARM systems. The previous change caught only `IllegalArgumentException` to dump the class file, but as seen in a recent failure, the exception type itself isn't guaranteed to be the same due to the nature of the issue. So, this commit catches `Exception` to dump the class file. Additionally, the change here also prints out the underlying `ResourcePoolEntry` type to see if that provides any additional hints on why the class content could end being corrupt. Thank you for the review Mandy. I ran the jdk:tier3 locally to make sure nothing regressed and it went fine: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/jdk:tier3 1284 1284 0 0 ============================== TEST SUCCESS ------------- PR: https://git.openjdk.java.net/jdk/pull/7049 From jpai at openjdk.java.net Thu Jan 20 04:53:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 20 Jan 2022 04:53:50 GMT Subject: Integrated: 8279921: Dump the .class file in jlink debug mode for any failure during transform() of a plugin In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 13:45:00 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which addresses https://bugs.openjdk.java.net/browse/JDK-8279921? > > The change here builds upon the debugging enhancement that was done in https://github.com/openjdk/jdk/pull/6696 to try and narrow down the problem behind intermittent failures on macos ARM systems. The previous change caught only `IllegalArgumentException` to dump the class file, but as seen in a recent failure, the exception type itself isn't guaranteed to be the same due to the nature of the issue. So, this commit catches `Exception` to dump the class file. Additionally, the change here also prints out the underlying `ResourcePoolEntry` type to see if that provides any additional hints on why the class content could end being corrupt. This pull request has now been integrated. Changeset: e683d4ac Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/e683d4ac8d9ee3b0078c5e87a2b3e7d36d7344fc Stats: 21 lines in 2 files changed: 16 ins; 0 del; 5 mod 8279921: Dump the .class file in jlink debug mode for any failure during transform() of a plugin Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7049 From duke at openjdk.java.net Thu Jan 20 10:05:43 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 20 Jan 2022 10:05:43 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v8] In-Reply-To: References: Message-ID: > BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. > > The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. > > We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. > > Some benchmark results, run on my 1-6-2 server: > > > Benchmark (n) Mode Cnt Score Error Units > BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op > BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op > BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op > BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op > BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op > BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op > > > We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. kabutz has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary output from the test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6409/files - new: https://git.openjdk.java.net/jdk/pull/6409/files/94c2d665..25e8c082 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=06-07 Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6409/head:pull/6409 PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Thu Jan 20 10:10:52 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 20 Jan 2022 10:10:52 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7] In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 18:03:33 GMT, Paul Sandoz wrote: >> kabutz has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed depth type to byte to save 8 bytes on each RecursiveSquare instance > > test/jdk/java/math/BigInteger/BigIntegerParallelMultiplyTest.java line 64: > >> 62: BigInteger fib = fibonacci(n, BigInteger::multiply); >> 63: System.out.printf("fibonacci(%d) = %d%n", n, fib); >> 64: } > > I think we can remove this and the loop block at #70-80, since we have the performance test. After that we are good. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From michaelm at openjdk.java.net Thu Jan 20 10:58:27 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 20 Jan 2022 10:58:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: removed sasl module dependency and added SaslException cause ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/f2ee58ec..fd56b5e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Thu Jan 20 10:58:32 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 20 Jan 2022 10:58:32 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <-m3WvmRetFCaWdw6yqWV_6SegzWeIRnkvdPjk0OP-pI=.3493c567-d2e1-41ca-b38f-15f1adc26ca9@github.com> <10PgAvehD50eY3I9oZjSfNA1IMSrWMxLhSgxsSDxuA0=.dd8c7df6-e352-446b-ba0c-a4d29cd7647d@github.com> Message-ID: On Wed, 19 Jan 2022 22:25:43 GMT, Weijun Wang wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> changes after first review round > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > >> 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); >> 132: } catch (ChannelBindingException e) { >> 133: throw new SaslException(e.getMessage()); > > How about setting `e` as cause of new exception? In `TlsChannelBinding.java` the when the original exception was thrown (the 2nd throws) there was a cause. Agreed. > src/java.security.jgss/share/classes/module-info.java line 36: > >> 34: module java.security.jgss { >> 35: requires java.naming; >> 36: requires java.security.sasl; > > Can this be removed now? Yes, well spotted! ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From mbaesken at openjdk.java.net Thu Jan 20 11:02:03 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 20 Jan 2022 11:02:03 GMT Subject: RFR: JDK-8280373: adjust other SystemIDResolver.java after 8270492 Message-ID: After 8270492 https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java ------------- Commit messages: - JDK-8280373 Changes: https://git.openjdk.java.net/jdk/pull/7155/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280373 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7155/head:pull/7155 PR: https://git.openjdk.java.net/jdk/pull/7155 From yan at openjdk.java.net Thu Jan 20 11:13:49 2022 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Thu, 20 Jan 2022 11:13:49 GMT Subject: RFR: JDK-8280373: adjust other SystemIDResolver.java after 8270492 In-Reply-To: References: Message-ID: <_oFPjEiNyLvvTRvywKYTp94bzKcAY8adp3YKWml1HoE=.0facb50d-b711-4348-a9d7-78d88953bd9b@github.com> On Thu, 20 Jan 2022 10:55:59 GMT, Matthias Baesken wrote: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java LGTM! ------------- Marked as reviewed by yan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7155 From duke at openjdk.java.net Thu Jan 20 11:17:49 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Thu, 20 Jan 2022 11:17:49 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> On Thu, 20 Jan 2022 10:58:27 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > removed sasl module dependency and added SaslException cause src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); > 132: } catch (ChannelBindingException e) { > 133: throw new SaslException(e.getMessage(), e); Why not ust pass the exception if the API allows? This looks like message duplication. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Thu Jan 20 11:21:52 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 20 Jan 2022 11:21:52 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 20 Jan 2022 10:58:27 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > removed sasl module dependency and added SaslException cause src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos > 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with > 220: {@code HttpURLConnection}. There are three possible settings:

Should it be `{@code HttpsURLConnection}`? (BTW - can we use {@code } here ? Would be worth checking the generated doc) src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189: > 187: } else { > 188: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); > 189: return s; Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here. src/java.base/share/classes/sun/security/util/ChannelBindingException.java line 31: > 29: * Thrown by TlsChannelBinding if an error occurs > 30: */ > 31: public class ChannelBindingException extends Exception { Should this extend `GeneralSecurityException` instead? Or should we just remove this class and throw plain `GeneralSecurityException` in `TlsChannelBinding` ? src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 143: > 141: tlsCB = TlsChannelBinding.create(cert); > 142: } catch (ChannelBindingException e) { > 143: throw new SaslException(e.getMessage()); Why is there a difference compared to line 133? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From alanb at openjdk.java.net Thu Jan 20 11:26:51 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 20 Jan 2022 11:26:51 GMT Subject: RFR: JDK-8280373: adjust other SystemIDResolver.java after 8270492 In-Reply-To: References: Message-ID: <2HKoM7ZxTLnMbH1AydR9Oa7E455QMNxYnNeyi6tFiY4=.81f1a228-6b6d-40bf-9496-13618f76684a@github.com> On Thu, 20 Jan 2022 10:55:59 GMT, Matthias Baesken wrote: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java It would be useful if Joe Wang can review this, just in case the security changes did not touch this code for some reason. ------------- PR: https://git.openjdk.java.net/jdk/pull/7155 From roger.riggs at oracle.com Thu Jan 20 18:05:13 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 20 Jan 2022 13:05:13 -0500 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec Message-ID: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> A JEP to Improve safety of process launch by ProcessBuilder and Runtime.exec on Windows[1]. Argument encoding errors have been problematic on Windows systems due to improperly quoted command arguments. The idea is to tighten up quoting and encoding of command line arguments. Comments appreciated,? Roger [1] https://bugs.openjdk.java.net/browse/JDK-8263697 From aturbanov at openjdk.java.net Thu Jan 20 18:15:55 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 20 Jan 2022 18:15:55 GMT Subject: Integrated: 8277535: Remove redundant Stream.distinct()/sorted() steps In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 11:20:53 GMT, Andrey Turbanov wrote: > 1. Stream.distinct() is redundant before toSet() collector. Duplicates will be collapsed by Collector. > 2. Stream.sorted() is redundant before toMap() collector. Keys will be shuffled by Collector (it's a HashMap in current implementation) This pull request has now been integrated. Changeset: 3419ff7b Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/3419ff7ba70b778906249dd5ab3a91998ca5a864 Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod 8277535: Remove redundant Stream.distinct()/sorted() steps Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/5714 From sspitsyn at openjdk.java.net Thu Jan 20 19:04:55 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 20 Jan 2022 19:04:55 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote: > While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test still passes > - [x] Linux AArch64 fastdebug, affected test still passes > - [x] Linux PPC64 fastdebug, affected test still passes Looks okay to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7132 From jdk at fiolino.de Thu Jan 20 20:37:16 2022 From: jdk at fiolino.de (Michael Kuhlmann) Date: Thu, 20 Jan 2022 21:37:16 +0100 Subject: LambdaMetafactory requires full privilege access, but doesn't seem to actually restrict functionality In-Reply-To: <2B27D55C-2B75-4EB0-A50C-1CC467E403AF@gmail.com> References: <2B27D55C-2B75-4EB0-A50C-1CC467E403AF@gmail.com> Message-ID: <57d4b1cb-efde-35c1-5d45-ba1688a3003f@fiolino.de> Hi Steven! On 1/19/22 2:23 AM, Steven Schlansker wrote: > Interestingly, that wasn't what I found. At least as of Java 14, the Metafactory generation approach (as limited as my first pass was) was competitive with CGLib hand-generated code in many (but not all) cases, and significantly faster than Method.invoke: > https://github.com/FasterXML/jackson-modules-base/tree/2.14/blackbird/benchmarks > Unfortunately I don't have a MethodHandle.invokeExact comparison in that benchmark. I should go back and finish that work, and re-run it all on 17. If we can call non-static MethodHandles with little overhead, then any reason to use the Metafactory here goes away. Very interesting! Thank you for sharing it. It's true that for non-static MethodHandles it's a similar problem as for generic lambdas: Hotspot can't easily inline the call. I wouldn't have expected that MethodHandles are even slower than lambas, but honestly I never measured it. > >> Really, I'm curious if this could be an approach for Jackson. Or if not, what could be the obstacles. > > I think the problem here is just slightly different: your approach will copy from one Java object to another Java object, but what we are doing is reacting to a token stream and trying to bind it to Java objects with as little overhead as possible. So I assume your token handler is getting the caller (be it a handle, a lambda or whatever) from some key-value store (maybe a Map) and injecting the value into it. What you can try is using MethodHandles::exactInvoker combined with foldArguments, where the token-to-handle mapper is already injected. The handle would just expect the token key and the value as arguments. Maybe this would perform better then the non-static setter handles. I did this for another use case where the target handle was the dynamicInvoker of a MutableCallSite. The handle then lazily generated its own final handle on the first call and set it into its CallSite, so that all subsequent calls ran directly into the generated handle. It was working great and a lot of fun to code, but again, I never measured the performance in detail. I wish you good luck! Michael From aturbanov at openjdk.java.net Thu Jan 20 21:18:13 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 20 Jan 2022 21:18:13 GMT Subject: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. Message-ID: Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: ----------System.out:(12/489)---------- --- Testing df C:/Programs/cygwin64 292848636 49695320 243153316 17% / D: 59672 59672 0 100% /cygdrive/d SecurityManager = null C:/Programs/cygwin64: df total= 299877003264 free = 0 usable = 248988995584 getX total= 299877003264 free = 248988995584 usable = 248988995584 :: df total= 61104128 free = 0 usable = 0 getX total= 0 free = 0 usable = 0 ----------System.err:(23/1617)---------- java.nio.file.InvalidPathException: Illegal char <:> at index 0: : at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) at java.base/java.io.File.toPath(File.java:2396) at GetXSpace.compare(GetXSpace.java:223) at GetXSpace.testDF(GetXSpace.java:403) at GetXSpace.main(GetXSpace.java:437) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) Parsing of df output is incorrect. It skips first symbols after matching of line. https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L160 It means that after matching first line: C:/Programs/cygwin64 292848636 49695320 243153316 17% / It skips first symbols of next line - symbol `D` and then proceeds to match _corrupted_ line: : 59672 59672 0 100% /cygdrive/d Problems affects only Windows, because only in Windows case first group of matcher is used: https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L155-L156 Testing: * Windows x64 - always failed before. No errors after fix * Linux x64 ------------- Commit messages: - 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. Changes: https://git.openjdk.java.net/jdk/pull/7170/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7170&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251466 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7170/head:pull/7170 PR: https://git.openjdk.java.net/jdk/pull/7170 From naoto.sato at oracle.com Thu Jan 20 21:46:49 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 20 Jan 2022 13:46:49 -0800 Subject: Additional Date-Time Formats Message-ID: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> Hello, I am proposing a couple of new factory methods in java.time.format.DateTimeFormatter that produce flexible localized date/time formats, other than the existing pre-defined (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year and month only string, such as the title for the calendar, currently they would have to use DateTimeFormatter.ofPattern() with explicit pattern argument, such as "MMM y". This is problematic because it is correct in locales such as US, but not correct in other locales. So, I propose methods that are parallel to ofPattern(), which take pattern template. This is based on the CLDR's skeleton: https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems Detailed design can be found in the draft CSR: https://bugs.openjdk.java.net/browse/JDK-8243445 Comments are welcome. Naoto From psandoz at openjdk.java.net Thu Jan 20 22:20:53 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 20 Jan 2022 22:20:53 GMT Subject: RFR: 8277155: Compress and expand vector operations In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 19:20:08 GMT, Paul Sandoz wrote: > Add two new cross-lane vector operations, `compress` and `expand`. > > An example of such usage might be code that selects elements from array `a` and stores those selected elements in array `z`: > > > int[] a = ...; > > int[] z = ...; > int ai = 0, zi = 0; > while (ai < a.length) { > IntVector av = IntVector.fromArray(SPECIES, a, ai); > // query over elements of vector av > // returning a mask marking elements of interest > VectorMask m = interestingBits(av, ...); > IntVector zv = av.compress(m); > zv.intoArray(z, zi, m.compress()); > ai += SPECIES.length(); > zi += m.trueCount(); > } > > > (There's also a more sophisticated version using `unslice` to coalesce matching elements with non-masked stores.) > > Given RDP 1 for 18 is getting close, 2021/12/09, we may not get this reviewed in time and included in [JEP 417](https://openjdk.java.net/jeps/417). Still I think I think it worth starting the review now (the CSR is marked provisional). Withdrawing and will create a new PR corresponding to a new incubating JEP. ------------- PR: https://git.openjdk.java.net/jdk/pull/6545 From psandoz at openjdk.java.net Thu Jan 20 22:20:53 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 20 Jan 2022 22:20:53 GMT Subject: Withdrawn: 8277155: Compress and expand vector operations In-Reply-To: References: Message-ID: <2F6yBpkaX7fN2nCCxN5z28qFdG-awS9F-CXa1mGysQg=.3a5e1c30-2812-47e3-a7da-1e3d084ca096@github.com> On Wed, 24 Nov 2021 19:20:08 GMT, Paul Sandoz wrote: > Add two new cross-lane vector operations, `compress` and `expand`. > > An example of such usage might be code that selects elements from array `a` and stores those selected elements in array `z`: > > > int[] a = ...; > > int[] z = ...; > int ai = 0, zi = 0; > while (ai < a.length) { > IntVector av = IntVector.fromArray(SPECIES, a, ai); > // query over elements of vector av > // returning a mask marking elements of interest > VectorMask m = interestingBits(av, ...); > IntVector zv = av.compress(m); > zv.intoArray(z, zi, m.compress()); > ai += SPECIES.length(); > zi += m.trueCount(); > } > > > (There's also a more sophisticated version using `unslice` to coalesce matching elements with non-masked stores.) > > Given RDP 1 for 18 is getting close, 2021/12/09, we may not get this reviewed in time and included in [JEP 417](https://openjdk.java.net/jeps/417). Still I think I think it worth starting the review now (the CSR is marked provisional). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6545 From darcy at openjdk.java.net Thu Jan 20 23:14:18 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 20 Jan 2022 23:14:18 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v4] In-Reply-To: References: Message-ID: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add toIdentityString ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/a854766b..48b596e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=02-03 Stats: 66 lines in 4 files changed: 62 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Thu Jan 20 23:20:37 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 20 Jan 2022 23:20:37 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v5] In-Reply-To: References: Message-ID: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Appease jcheck. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/48b596e9..0f6f0786 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Thu Jan 20 23:27:48 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 20 Jan 2022 23:27:48 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v5] In-Reply-To: References: Message-ID: <9ZivGmmq2hrIS-sIqc3qsoLFC76ksVPlHfeqcUKVisM=.830841ca-84b9-40f8-9d41-5726714a8d04@github.com> On Thu, 20 Jan 2022 23:20:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Appease jcheck. Expanding the scope of the proposed change, perhaps outside of a good cost/benefit ratio, there are now two new methods: toDefaultString(Object o) // uses o.hashCode toIdentityString(Object o) // uses System.identityHashCode(o) The revision refactors two occurrences of the logic of toDefaultString with calls to the new method. The toIdentityString method has the sometimes helpful property that no overridden methods of the object are called in constructing the string. I'll revise the CSR once the final set of methods and their spec for this fix is determined. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From joehw at openjdk.java.net Thu Jan 20 23:35:49 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 20 Jan 2022 23:35:49 GMT Subject: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 In-Reply-To: References: Message-ID: <78xJzEH4j6WTkfNljXgN2XhzY3UYepaK2FuQaExZ9Bs=.93995dce-5521-4122-9787-7e5779e0db2b@github.com> On Thu, 20 Jan 2022 10:55:59 GMT, Matthias Baesken wrote: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Thanks Alan for the reminder. The change looks good. Please add a copyright header and the LastModified tag as the other class did. ------------- PR: https://git.openjdk.java.net/jdk/pull/7155 From sviswanathan at openjdk.java.net Fri Jan 21 00:51:48 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 21 Jan 2022 00:51:48 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: References: Message-ID: <2TVKx_BFFyAK2ooOWKpdsEIMFzJngYxlWjbgeZ2y4Mc=.5deb2173-8107-476d-92ca-1835d69ce336@github.com> On Wed, 19 Jan 2022 17:38:25 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> ? | ? | BASELINE AVX2 | WithOpt AVX2 | Gain (opt/baseline) | Baseline AVX3 | Withopt AVX3 | Gain (opt/baseline) >> -- | -- | -- | -- | -- | -- | -- | -- >> Benchmark | ARRAYLEN | Score (ops/ms) | Score (ops/ms) | ? | Score (ops/ms) | Score (ops/ms) | ? >> FpRoundingBenchmark.test_round_double | 1024 | 518.532 | 1364.066 | 2.630630318 | 512.908 | 4292.11 | 8.368186887 >> FpRoundingBenchmark.test_round_double | 2048 | 270.137 | 830.986 | 3.076165057 | 273.159 | 2459.116 | 9.002507697 >> FpRoundingBenchmark.test_round_float | 1024 | 752.436 | 7780.905 | 10.34095259 | 752.49 | 9506.694 | 12.63364829 >> FpRoundingBenchmark.test_round_float | 2048 | 389.499 | 4113.046 | 10.55983712 | 389.63 | 4863.673 | 12.48279907 >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Adding a test for scalar intrinsification. The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for Math.rint which is specified to be round to nearest even. Please see: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html : section 4.8.4 The rounding mode needed for Math.round is round to positive infinity which needs a different x86 mxcsr initialization(0x5F80). ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From huizhe.wang at oracle.com Fri Jan 21 05:52:57 2022 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 20 Jan 2022 21:52:57 -0800 Subject: Additional Date-Time Formats In-Reply-To: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> Message-ID: <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> Hi Naoto, The javadoc points to LDML, it seems to me though it might be useful to add more information similar to that for the ofPattern methods, what's under the "Patterns for Formatting and Parsing" section, so that for at least the common use cases we could rely on the javadoc without having to consult the LDML specification. Some comparison with the ofPattern methods might also be helpful. Just my 2 cents. Thanks, Joe On 1/20/22 1:46 PM, Naoto Sato wrote: > Hello, > > I am proposing a couple of new factory methods in > java.time.format.DateTimeFormatter that produce flexible localized > date/time formats, other than the existing pre-defined > (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year > and month only string, such as the title for the calendar, currently > they would have to use DateTimeFormatter.ofPattern() with explicit > pattern argument, such as "MMM y". This is problematic because it is > correct in locales such as US, but not correct in other locales. > > So, I propose methods that are parallel to ofPattern(), which take > pattern template. This is based on the CLDR's skeleton: > https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems > > Detailed design can be found in the draft CSR: > https://bugs.openjdk.java.net/browse/JDK-8243445 > > Comments are welcome. > > Naoto > From shade at openjdk.java.net Fri Jan 21 09:58:41 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 21 Jan 2022 09:58:41 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote: >> While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, affected test still passes >> - [x] Linux x86_32 fastdebug, affected test still passes >> - [x] Linux AArch64 fastdebug, affected test still passes >> - [x] Linux PPC64 fastdebug, affected test still passes > > test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 326: > >> 324: >> 325: public static void main(String[] args)throws Throwable { >> 326: new GetObjectSizeIntrinsicsTest(args[0], (args.length >= 2 ? args[1] : "")).runTest(); > > Shouldn't this be `args.length == 2`? @plummercj, are you good with this explanation? ------------- PR: https://git.openjdk.java.net/jdk/pull/7132 From shade at openjdk.java.net Fri Jan 21 11:04:22 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 21 Jan 2022 11:04:22 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v4] In-Reply-To: References: Message-ID: <3D6SSMiDJOz_WS2uaENCZn8VYnnCJrFXVaKgTalADiE=.5fde3e99-6fae-4ad7-8128-6159ffe4601f@github.com> > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Guarantee progress for at least one thread - Merge branch 'master' into JDK-8280041-classcache-problems - Test summary - GC sanity test - NullValueTest - Merge branch 'master' into JDK-8280041-classcache-problems - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7092/files - new: https://git.openjdk.java.net/jdk/pull/7092/files/49b852de..0f2dcd0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=02-03 Stats: 6687 lines in 233 files changed: 4438 ins; 1559 del; 690 mod Patch: https://git.openjdk.java.net/jdk/pull/7092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7092/head:pull/7092 PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Fri Jan 21 11:04:24 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 21 Jan 2022 11:04:24 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v3] In-Reply-To: <3dyG3wqOhJEoKdMfPXUfe5rTQHgTXtQqCMP3pjpe9ms=.ce707548-e752-4aa8-a494-de97ce320e83@github.com> References: <3dyG3wqOhJEoKdMfPXUfe5rTQHgTXtQqCMP3pjpe9ms=.ce707548-e752-4aa8-a494-de97ce320e83@github.com> Message-ID: On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote: > WDYT? I like the idea of holding to a value strongly for a brief period of time, in order to guarantee progress! The sample code was a bit hard to follow, so I rewrote the loop a bit with comments, see new commit. This still passes tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Fri Jan 21 11:04:26 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 21 Jan 2022 11:04:26 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases [v2] In-Reply-To: References: Message-ID: > While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test still passes > - [x] Linux AArch64 fastdebug, affected test still passes > - [x] Linux PPC64 fastdebug, affected test still passes Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8280166-getobjectsize - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7132/files - new: https://git.openjdk.java.net/jdk/pull/7132/files/29e6fd24..dd9ce049 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7132&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7132&range=00-01 Stats: 7693 lines in 284 files changed: 5179 ins; 1672 del; 842 mod Patch: https://git.openjdk.java.net/jdk/pull/7132.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7132/head:pull/7132 PR: https://git.openjdk.java.net/jdk/pull/7132 From jlahoda at openjdk.java.net Fri Jan 21 12:44:48 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 21 Jan 2022 12:44:48 GMT Subject: RFR: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero wrote: > Hi, > > Please review this change that is fixing a bug in reflection in particular in `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current code is assuming that for inner class constructors, there are only type annotations on parameters, but it is also invoked to extract type annotations applied to exception types for example. This bug affects the behavior of method: `java.lang.reflect.Executable::getAnnotatedExceptionTypes` which is not behaving according to its specification. Given that this fix affects the behavior of a method belonging to our API a CSR has been filed too. Please review it at [JDK-8278926](https://bugs.openjdk.java.net/browse/JDK-8278926). > > TIA To me, looks good. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6869 From robm at openjdk.java.net Fri Jan 21 13:06:40 2022 From: robm at openjdk.java.net (Rob McKenna) Date: Fri, 21 Jan 2022 13:06:40 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v4] In-Reply-To: References: Message-ID: > This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. > > Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. Rob McKenna has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Add method to guard long to int cast - Allow the test to pass on MacOSX - JDK-8277795: whitespace - Add test - JDK-8277795: formatting - JDK-8277795: whitespace cleanup - JDK-8277795: ldap connection timeout not honoured under contention ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6568/files - new: https://git.openjdk.java.net/jdk/pull/6568/files/7c277622..6af94f37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6568&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6568&range=02-03 Stats: 73668 lines in 2120 files changed: 50786 ins; 12701 del; 10181 mod Patch: https://git.openjdk.java.net/jdk/pull/6568.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6568/head:pull/6568 PR: https://git.openjdk.java.net/jdk/pull/6568 From robm at openjdk.java.net Fri Jan 21 13:06:40 2022 From: robm at openjdk.java.net (Rob McKenna) Date: Fri, 21 Jan 2022 13:06:40 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: <95CuJQqoVfJOEdYeRhgTJbLqdQwyyGvBlDR2WoyIsfg=.2230a07d-ad5f-457f-ac33-283e732cda25@github.com> Message-ID: On Wed, 19 Jan 2022 15:53:57 GMT, Daniel Fuchs wrote: >> IIRC this was a request from an earlier review. (long being the standard throughout other new public apis) I'm happy with either, but int does avoid the trouble of casting. > > Well I guess the request was "why not use long everywhere to avoid casting to int" ;-) > But I'm happy with either too - as long as the place where you have a long (e.g obtained by substracting two nano times) and call a method that takes an int has the proper guards in place, and either assert/throws/floor or ceil if the assumptions are not met - provided that a comment explains why that particular alternative is selected. Good point. I think its better to deal with the casts at the edges since the timeout handling will use long by default. ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From vromero at openjdk.java.net Fri Jan 21 13:16:45 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 21 Jan 2022 13:16:45 GMT Subject: RFR: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor In-Reply-To: References: Message-ID: <9JDFa1gXb2e6Pm7d5iRhJPYDIiwdeCvuKHpjY1lhfBs=.7279f738-b5fd-42ad-bdd8-094ae1cad8a6@github.com> On Fri, 21 Jan 2022 12:41:37 GMT, Jan Lahoda wrote: > To me, looks good. thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/6869 From michaelm at openjdk.java.net Fri Jan 21 13:41:54 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 13:41:54 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 20 Jan 2022 11:04:18 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed sasl module dependency and added SaslException cause > > src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > >> 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos >> 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with >> 220: {@code HttpURLConnection}. There are three possible settings:

> > Should it be `{@code HttpsURLConnection}`? > (BTW - can we use {@code } here ? Would be worth checking the generated doc) Right HttpsURLConnection is better. {@code} works here. > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189: > >> 187: } else { >> 188: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); >> 189: return s; > > Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here. It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 13:41:55 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 13:41:55 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> Message-ID: <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> On Thu, 20 Jan 2022 11:14:40 GMT, Michael Osipov wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed sasl module dependency and added SaslException cause > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: > >> 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); >> 132: } catch (ChannelBindingException e) { >> 133: throw new SaslException(e.getMessage(), e); > > Why not ust pass the exception if the API allows? This looks like message duplication. Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 14:14:33 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 14:14:33 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 20 Jan 2022 11:16:16 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed sasl module dependency and added SaslException cause > > src/java.base/share/classes/sun/security/util/ChannelBindingException.java line 31: > >> 29: * Thrown by TlsChannelBinding if an error occurs >> 30: */ >> 31: public class ChannelBindingException extends Exception { > > Should this extend `GeneralSecurityException` instead? Or should we just remove this class and throw plain `GeneralSecurityException` in `TlsChannelBinding` ? I think a distinct exception is necessary. I don't have a strong opinion on whether it should extend GeneralSecurityException. > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 143: > >> 141: tlsCB = TlsChannelBinding.create(cert); >> 142: } catch (ChannelBindingException e) { >> 143: throw new SaslException(e.getMessage()); > > Why is there a difference compared to line 133? Right, that was a mistake. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Fri Jan 21 14:14:45 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Fri, 21 Jan 2022 14:14:45 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> Message-ID: <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> On Fri, 21 Jan 2022 13:35:53 GMT, Michael McMahon wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 133: >> >>> 131: (String)env.get(TlsChannelBinding.CHANNEL_BINDING_TYPE)); >>> 132: } catch (ChannelBindingException e) { >>> 133: throw new SaslException(e.getMessage(), e); >> >> Why not ust pass the exception if the API allows? This looks like message duplication. > > Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception. `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 15:11:42 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 15:11:42 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 13:38:08 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 189: >> >>> 187: } else { >>> 188: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); >>> 189: return s; >> >> Should this return either "always" or "never" instead? It seems that junk values will be treated as "always". It would be better to make it clear here. > > It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here. Sorry, I should have checked back to the source rather than the snippet quoted. The problem is that the logError call is in the wrong place. It should be before line 186. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 15:26:33 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 15:26:33 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: more tidy-up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/fd56b5e3..c9975fd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=02-03 Stats: 12 lines in 4 files changed: 5 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From shade at openjdk.java.net Fri Jan 21 15:28:18 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 21 Jan 2022 15:28:18 GMT Subject: RFR: 8280459: Suspicious integer division in Hashtable.readHashtable Message-ID: Found by Sonar. See details in the bug. Additional testing: - [x] Linux x86_64 fastdebug `tier1` - [x] Linux x86_64 fastdebug `java/util/Hashtable` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/7178/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7178&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280459 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7178.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7178/head:pull/7178 PR: https://git.openjdk.java.net/jdk/pull/7178 From dfuchs at openjdk.java.net Fri Jan 21 15:35:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 15:35:43 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 15:08:58 GMT, Michael McMahon wrote: >> It was being handled elsewhere as "never". But, I agree it would be clearer to normalise it to "never" here. > > Sorry, I should have checked back to the source rather than the snippet quoted. The problem is that the logError call is in the wrong place. It should be before line 186. Though some other adjustments are also required Ah! Yes - I was also bitten again by the negation in the `if` too. The presence of `logError` in the body of the `if` will make it clearer :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 15:35:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 15:35:44 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <7Zv8iD7zLtr7WSXkcyMCSnG6aHOLuEH7GOWsrmNTvTs=.f88978ea-ddb9-4c78-8634-f762071e4ec9@github.com> On Fri, 21 Jan 2022 15:26:33 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > more tidy-up src/java.base/share/classes/sun/net/www/http/HttpClient.java line 191: > 189: } else { > 190: logError("Unexpected value for \"jdk.https.negotiate.cbt\" system property"); > 191: return "never"; Much easier to review now :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 15:43:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 15:43:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 15:26:33 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > more tidy-up Marked as reviewed by dfuchs (Reviewer). src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144: > 142: } catch (ChannelBindingException e) { > 143: throw new NamingException(e.getMessage()); > 144: } Should we call initCause here and above? I see that we do call initCause in NegotiatorImpl.java. On the one hand it's better for diagnostic. On the other hand it exposes a module-internal exception class which is not great. Or maybe we should set the cause of the CBE as the cause of NamingException. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From amenkov at openjdk.java.net Fri Jan 21 15:48:11 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 21 Jan 2022 15:48:11 GMT Subject: RFR: 8240908: RetransformClass does not know about MethodParameters attribute Message-ID: Changes: - ClassFileReconstituter is updated to restore "MethodParameters" attribute; - handling of the attribute in VM_RedefineClasses is moved to be consistent with other code (like local variable table); - copied ClassTransformer class (from test/jdk/com/sun/jdi/lib/jdb) to /test/lib as it's used by tests from hotspot and jdk (and also by test from Valhalla repo); Will file a follow up issues to updates tests and remove the class from test/jdk/com/sun/jdi/lib/jdb ------------- Commit messages: - JDK-8240908 Changes: https://git.openjdk.java.net/jdk/pull/7180/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7180&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240908 Stats: 431 lines in 5 files changed: 411 ins; 15 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7180.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7180/head:pull/7180 PR: https://git.openjdk.java.net/jdk/pull/7180 From michaelm at openjdk.java.net Fri Jan 21 15:54:59 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 15:54:59 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> Message-ID: <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com> On Fri, 21 Jan 2022 13:39:06 GMT, Michael Osipov wrote: >> Actually, it turns out I should be throwing `NamingException` here. That is what was being thrown by `TlsChannelBinding.parseType` before and an existing test was expecting that. NamingException only takes a String message. So, there won't be a root cause exception. > > `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained. Yes, I can do that. Though it will cause the existing LDAP channel binding test to fail which is checking for an empty root cause. That is checking unspecified behavior and I can change it to check for a `ChannelBindingException` as root cause. So long as we are okay having a non public exception type as the root cause, it's probably helpful to have the full stack there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Fri Jan 21 16:02:29 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 21 Jan 2022 16:02:29 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: added root cause to NamingException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/c9975fd1..058c3830 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=03-04 Stats: 16 lines in 2 files changed: 8 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Fri Jan 21 16:02:31 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Fri, 21 Jan 2022 16:02:31 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v3] In-Reply-To: <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <8pzpi2IkmzgCVXfqXGCBDN3ntpIAb-FbDmwk2hlsU-U=.0d725cec-d973-4de0-a4bb-baf041ad3c5e@github.com> <2e7W1DSR3tN4Hk58kH300rQw_iN4T_NvBZHt3Id0TD8=.b7026e4d-b4aa-49be-98b6-1b1f31c0fa99@github.com> <_R8tIWDfwjzw911coj4H8i1kRg2XpVRnv6ki9vYwujI=.243d92d2-a06a-4706-b1cb-4c2e5e060c7b@github.com> <0MMPGqWCdM0pqrasOTbA3IKbrzbzE6g3elnI-Weov1A=.14c3b784-d7b4-4168-8b3f-089b75b0899f@github.com> Message-ID: On Fri, 21 Jan 2022 15:51:10 GMT, Michael McMahon wrote: >> `NamingException` has `setRootCause()`. Why not use that? I use that one too and full stack is retained. > > Yes, I can do that. Though it will cause the existing LDAP channel binding test to fail which is checking for an empty root cause. That is checking unspecified behavior and I can change it to check for a `ChannelBindingException` as root cause. So long as we are okay having a non public exception type as the root cause, it's probably helpful to have the full stack there. Yes please retain as much information as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From lmesnik at openjdk.java.net Fri Jan 21 16:21:53 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 21 Jan 2022 16:21:53 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 11:04:26 GMT, Aleksey Shipilev wrote: >> While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, affected test still passes >> - [x] Linux x86_32 fastdebug, affected test still passes >> - [x] Linux AArch64 fastdebug, affected test still passes >> - [x] Linux PPC64 fastdebug, affected test still passes > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8280166-getobjectsize > - Fix Please update copyright years. ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7132 From rriggs at openjdk.java.net Fri Jan 21 16:27:41 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 21 Jan 2022 16:27:41 GMT Subject: RFR: 8280459: Suspicious integer division in Hashtable.readHashtable In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 15:19:38 GMT, Aleksey Shipilev wrote: > Found by Sonar. See details in the bug. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `java/util/Hashtable` LGTM. Seems reasonable though it might increase heap allocation of the array slightly. In the example, the 28 would be reduced to 27 to make it odd. With the new computation, its 29 or 2 additional refs. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7178 From aturbanov at openjdk.java.net Fri Jan 21 17:04:58 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 21 Jan 2022 17:04:58 GMT Subject: RFR: 8280470: Confusing instanceof check in HijrahChronology.range Message-ID: Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`. But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`. ------------- Commit messages: - [PATCH] Remove confusing instanceof check in HijrahChronology.range - [PATCH] Remove confusing instanceof check in HijrahChronology.range Changes: https://git.openjdk.java.net/jdk/pull/7118/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7118&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280470 Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7118.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7118/head:pull/7118 PR: https://git.openjdk.java.net/jdk/pull/7118 From msheppar at openjdk.java.net Fri Jan 21 17:10:42 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Fri, 21 Jan 2022 17:10:42 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: <95CuJQqoVfJOEdYeRhgTJbLqdQwyyGvBlDR2WoyIsfg=.2230a07d-ad5f-457f-ac33-283e732cda25@github.com> Message-ID: On Fri, 21 Jan 2022 13:02:36 GMT, Rob McKenna wrote: >> Well I guess the request was "why not use long everywhere to avoid casting to int" ;-) >> But I'm happy with either too - as long as the place where you have a long (e.g obtained by substracting two nano times) and call a method that takes an int has the proper guards in place, and either assert/throws/floor or ceil if the assumptions are not met - provided that a comment explains why that particular alternative is selected. > > Good point. I think its better to deal with the casts at the edges since the timeout handling will use long by default. yes a redeclaration of timeout with a type long across the component would be a consistent approach, also ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From rriggs at openjdk.java.net Fri Jan 21 17:19:41 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 21 Jan 2022 17:19:41 GMT Subject: RFR: 8280470: Confusing instanceof check in HijrahChronology.range In-Reply-To: References: Message-ID: On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote: > Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`. > But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`. Looks fine; I have no idea how that came to be; there was a lot of copy paste in the initial check-in of java.time. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7118 From dfuchs at openjdk.java.net Fri Jan 21 17:22:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 17:22:43 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v4] In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 13:06:40 GMT, Rob McKenna wrote: >> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. >> >> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. > > Rob McKenna has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Add method to guard long to int cast > - Allow the test to pass on MacOSX > - JDK-8277795: whitespace > - Add test > - JDK-8277795: formatting > - JDK-8277795: whitespace cleanup > - JDK-8277795: ldap connection timeout not honoured under contention Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From naoto at openjdk.java.net Fri Jan 21 17:29:43 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 21 Jan 2022 17:29:43 GMT Subject: RFR: 8280470: Confusing instanceof check in HijrahChronology.range In-Reply-To: References: Message-ID: On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote: > Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`. > But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7118 From dfuchs at openjdk.java.net Fri Jan 21 17:53:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 17:53:44 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > added root cause to NamingException Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 21 18:05:41 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 Jan 2022 18:05:41 GMT Subject: RFR: 8280470: Confusing instanceof check in HijrahChronology.range In-Reply-To: References: Message-ID: On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote: > Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`. > But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7118 From iris at openjdk.java.net Fri Jan 21 18:17:42 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 21 Jan 2022 18:17:42 GMT Subject: RFR: 8280470: Confusing instanceof check in HijrahChronology.range In-Reply-To: References: Message-ID: <4cS4uzlig3bPC1NNM7jfbtldFeae_UJNKIAASc8RXAk=.b780126d-71e5-4192-afce-1195a00b327e@github.com> On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote: > Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`. > But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7118 From jjg at openjdk.java.net Fri Jan 21 18:45:58 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 21 Jan 2022 18:45:58 GMT Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC Message-ID: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Please review this semi-automated update to the nroff man pages from the upstream repo. ------------- Commit messages: - JDK-8279179: Update nroff pages in JDK 18 before RC Changes: https://git.openjdk.java.net/jdk18/pull/112/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=112&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279179 Stats: 34 lines in 3 files changed: 32 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk18/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk18/pull/112 From bpb at openjdk.java.net Fri Jan 21 19:34:15 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 21 Jan 2022 19:34:15 GMT Subject: RFR: 8280459: Suspicious integer division in Hashtable.readHashtable In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 15:19:38 GMT, Aleksey Shipilev wrote: > Found by Sonar. See details in the bug. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `java/util/Hashtable` Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7178 From djelinski at openjdk.java.net Fri Jan 21 19:47:37 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 21 Jan 2022 19:47:37 GMT Subject: RFR: 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md Message-ID: Reported by clang-tidy. Verified manually by running Calendar c = Calendar.getInstance(); System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault())); with `-Djava.locale.providers=HOST` Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array. No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works. ------------- Commit messages: - Update copyright year - make sure isGenitive is initialized before use Changes: https://git.openjdk.java.net/jdk/pull/7184/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7184&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280474 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7184.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7184/head:pull/7184 PR: https://git.openjdk.java.net/jdk/pull/7184 From weijun at openjdk.java.net Fri Jan 21 19:51:12 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 Jan 2022 19:51:12 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com> On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > added root cause to NamingException src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos > 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with > 220: {@code HttpsURLConnection}. There are three possible settings:

You can probably mention here that the 'tls-server-end-point' Channel Binding Type defined in RFC 5929 is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Fri Jan 21 19:59:25 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 Jan 2022 19:59:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <7hhc0sEj6x1SvXw2uNKpTvyM4Ye65jpUdYTF1IV8dz8=.65223e7a-defb-4737-be99-f3d14bf153af@github.com> On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > added root cause to NamingException Please move // TLS channel binding type property public static final String CHANNEL_BINDING_TYPE = "com.sun.jndi.ldap.tls.cbtype"; // internal TLS channel binding property public static final String CHANNEL_BINDING = "jdk.internal.sasl.tlschannelbinding"; outside of the `TlsChannelBinding` class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From iris at openjdk.java.net Fri Jan 21 21:09:09 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 21 Jan 2022 21:09:09 GMT Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Message-ID: On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons wrote: > Please review this semi-automated update to the nroff man pages from the upstream repo. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/112 From naoto at openjdk.java.net Fri Jan 21 21:12:10 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 21 Jan 2022 21:12:10 GMT Subject: RFR: 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeli?ski wrote: > Reported by clang-tidy. Verified manually by running > > Calendar c = Calendar.getInstance(); > System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault())); > > with `-Djava.locale.providers=HOST` > > Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array. > > No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works. Looks good. The difference would be observable for locales that have different month names for standalone/format, such as Polish ?? I'd add `noreg-hard` label to the JBS issue, as it would require Windows to be set to those locales. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7184 From mchung at openjdk.java.net Fri Jan 21 21:30:14 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 21 Jan 2022 21:30:14 GMT Subject: [jdk18] RFR: JDK-8279179: Update nroff pages in JDK 18 before RC In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Message-ID: On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons wrote: > Please review this semi-automated update to the nroff man pages from the upstream repo. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/112 From naoto.sato at oracle.com Fri Jan 21 22:39:21 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 21 Jan 2022 14:39:21 -0800 Subject: Additional Date-Time Formats In-Reply-To: <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> Message-ID: Thanks, Joe. Good point. I will elaborate the pattern template part more, less depending on the LDML spec. Would have been better if we could introduce our own, such as ofLocalizedPattern(Set template), but not exactly suffices the need. Naoto On 1/20/22 9:52 PM, Joe Wang wrote: > Hi Naoto, > > The javadoc points to LDML, it seems to me though it might be useful to > add more information similar to that for the ofPattern methods, what's > under the "Patterns for Formatting and Parsing" section, so that for at > least the common use cases we could rely on the javadoc without having > to consult the LDML specification. Some comparison with the ofPattern > methods might also be helpful. > > Just my 2 cents. > > Thanks, > Joe > > On 1/20/22 1:46 PM, Naoto Sato wrote: >> Hello, >> >> I am proposing a couple of new factory methods in >> java.time.format.DateTimeFormatter that produce flexible localized >> date/time formats, other than the existing pre-defined >> (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year >> and month only string, such as the title for the calendar, currently >> they would have to use DateTimeFormatter.ofPattern() with explicit >> pattern argument, such as "MMM y". This is problematic because it is >> correct in locales such as US, but not correct in other locales. >> >> So, I propose methods that are parallel to ofPattern(), which take >> pattern template. This is based on the CLDR's skeleton: >> https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems >> >> >> Detailed design can be found in the draft CSR: >> https://bugs.openjdk.java.net/browse/JDK-8243445 >> >> Comments are welcome. >> >> Naoto >> > From mchung at openjdk.java.net Fri Jan 21 22:56:42 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 21 Jan 2022 22:56:42 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags Message-ID: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. ------------- Commit messages: - 8280377: MethodHandleProxies does not correctly invoke default methods with varags Changes: https://git.openjdk.java.net/jdk/pull/7185/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280377 Stats: 49 lines in 2 files changed: 8 ins; 37 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7185/head:pull/7185 PR: https://git.openjdk.java.net/jdk/pull/7185 From duke at openjdk.java.net Fri Jan 21 23:20:08 2022 From: duke at openjdk.java.net (liach) Date: Fri, 21 Jan 2022 23:20:08 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags In-Reply-To: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Fri, 21 Jan 2022 22:49:38 GMT, Mandy Chung wrote: > The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. Will older versions up to Java 8 get an alternative fix (changing the accessed handle to non-vararg) too? This API is currently the most backward-compatible way to create a proper (as in calling default methods as desired) interface proxy in Java 8 or 11. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From jjg at openjdk.java.net Fri Jan 21 23:22:13 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 21 Jan 2022 23:22:13 GMT Subject: [jdk18] Integrated: JDK-8279179: Update nroff pages in JDK 18 before RC In-Reply-To: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> References: <1nrbA42viloBlDxMIjy9Qb_fcgwUNb_6sAcG2sPTaCY=.2ea6a544-03b6-4a49-88bd-77db90f426fb@github.com> Message-ID: On Fri, 21 Jan 2022 18:37:50 GMT, Jonathan Gibbons wrote: > Please review this semi-automated update to the nroff man pages from the upstream repo. This pull request has now been integrated. Changeset: 7d2ef9d9 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk18/commit/7d2ef9d984f96cd260dc233c4acf58669615227f Stats: 34 lines in 3 files changed: 32 ins; 0 del; 2 mod 8279179: Update nroff pages in JDK 18 before RC Reviewed-by: iris, mchung ------------- PR: https://git.openjdk.java.net/jdk18/pull/112 From mchung at openjdk.java.net Fri Jan 21 23:43:09 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 21 Jan 2022 23:43:09 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Fri, 21 Jan 2022 23:16:50 GMT, liach wrote: > Will older versions up to Java 8 get an alternative fix (changing the accessed handle to non-vararg) too? This is up to the update release maintainers to decide. The backport fix is straight-forward. I include that in the JBS report. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From duke at openjdk.java.net Fri Jan 21 23:51:02 2022 From: duke at openjdk.java.net (liach) Date: Fri, 21 Jan 2022 23:51:02 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v3] In-Reply-To: References: Message-ID: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8261407-reflectionfactory - Merge branch '8261407-reflectionfactory' - Just use volatile directly to ensure read order - 8261407: ReflectionFactory.checkInitted() is not thread-safe ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6889/files - new: https://git.openjdk.java.net/jdk/pull/6889/files/1deb5207..0afb76d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=01-02 Stats: 32523 lines in 992 files changed: 22689 ins; 5684 del; 4150 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889 From duke at openjdk.java.net Sat Jan 22 00:05:49 2022 From: duke at openjdk.java.net (liach) Date: Sat, 22 Jan 2022 00:05:49 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v4] In-Reply-To: References: Message-ID: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) liach has updated the pull request incrementally with one additional commit since the last revision: Include the stable annotation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6889/files - new: https://git.openjdk.java.net/jdk/pull/6889/files/0afb76d1..f237cf50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889 From duke at openjdk.java.net Sat Jan 22 00:05:54 2022 From: duke at openjdk.java.net (liach) Date: Sat, 22 Jan 2022 00:05:54 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v3] In-Reply-To: References: Message-ID: <0OkhkBgQ-Z47cSwsYJ2dRWR6ubLQcG6gEydgthQJQdg=.bdc36237-2bcc-489d-bc84-a0b275f3491b@github.com> On Fri, 21 Jan 2022 23:51:02 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8261407-reflectionfactory > - Merge branch '8261407-reflectionfactory' > - Just use volatile directly to ensure read order > - 8261407: ReflectionFactory.checkInitted() is not thread-safe The addition of `@Stable` seems safe. Here's a comparison for the `checkInitted` method under current patch (volatile) and the stable annotation (stable): https://gist.github.com/b6a1090872e686f31595bcd778893e82 Under this test setup: https://gist.github.com/96018d7dcaa07763d1c205017a9bd99f Can any professional review the comparison above, as I am not as acquainted to C assembly and VM internals to confirm there is indeed no unintended side effects? ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From aefimov at openjdk.java.net Sat Jan 22 01:12:13 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Sat, 22 Jan 2022 01:12:13 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v4] In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 13:06:40 GMT, Rob McKenna wrote: >> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. >> >> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. > > Rob McKenna has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Add method to guard long to int cast > - Allow the test to pass on MacOSX > - JDK-8277795: whitespace > - Add test > - JDK-8277795: formatting > - JDK-8277795: whitespace cleanup > - JDK-8277795: ldap connection timeout not honoured under contention Marked as reviewed by aefimov (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From thomas.stuefe at gmail.com Sat Jan 22 08:40:41 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 22 Jan 2022 09:40:41 +0100 Subject: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected In-Reply-To: References: Message-ID: Hi Micheal, welcome, and thank you for your contribution! I opened a bug id for you to track this: https://bugs.openjdk.java.net/browse/JDK-8280498 . I can sponsor this patch for you. You need one reviewer, I think. I don't have the cycles right now to think this through. I cc core-libs dev since this is a networking issue and one of their tests. Cheers, Thomas On Thu, Jan 20, 2022 at 2:50 PM Michael Felt wrote: > Hello all, > > This is a test that fails in some environments - enough so that has been > added to the ignore-list at AdoptOpenJDK (now Adoptium). And it will stay > there until it gets fixed upstream. > > I researched this and came up with differences that are behave differently > depending on the environment, e.g., my server, and partitions hosted at IBM > garage respond - at CLI - > > ``` > > aixtools at x064:[/data/prj/aixtools/tests]ping 0.0.0.0 > PING 0.0.0.0: (0.0.0.0): 56 data bytes > > --- 0.0.0.0 ping statistics --- > 5 packets transmitted, 0 packets received, 100% packet loss > ``` > > While at OSUOSL environment: > ``` > > aixtools at nim.bak:[/home/aixtools]ping 0.0.0.0 > PING 0.0.0.0: (0.0.0.0): 56 data bytes > 64 bytes from 140.211.9.1: icmp_seq=0 ttl=255 time=0 ms > 64 bytes from 140.211.9.1: icmp_seq=1 ttl=255 time=0 ms > 64 bytes from 140.211.9.1: icmp_seq=2 ttl=255 time=0 ms > > --- 0.0.0.0 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss > round-trip min/avg/max = 0/0/0 ms > ``` > > The patch is to make this test work in both environments - without any > need to change the `java.net.InetAddress` or > `java.net.Inet6Address` definitions. > > Regards, > > Michael > From Alan.Bateman at oracle.com Sat Jan 22 09:59:45 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Jan 2022 09:59:45 +0000 Subject: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected In-Reply-To: References: Message-ID: <4cd329f0-766b-3f50-da29-c1908a0f1bd1@oracle.com> On 22/01/2022 08:40, Thomas St?fe wrote: > Hi Micheal, > > welcome, and thank you for your contribution! > > I opened a bug id for you to track this: > https://bugs.openjdk.java.net/browse/JDK-8280498 . I can sponsor this patch > for you. > > You need one reviewer, I think. I don't have the cycles right now to think > this through. I cc core-libs dev since this is a networking issue and one > of their tests. > The networking tests are maintained on net-dev so if there is a PR then it should go to that list. -Alan From alanb at openjdk.java.net Sat Jan 22 12:17:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 22 Jan 2022 12:17:07 GMT Subject: RFR: 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeli?ski wrote: > Reported by clang-tidy. Verified manually by running > > Calendar c = Calendar.getInstance(); > System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault())); > > with `-Djava.locale.providers=HOST` > > Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array. > > No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works. Good find. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7184 From alanb at openjdk.java.net Sat Jan 22 12:41:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 22 Jan 2022 12:41:07 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags In-Reply-To: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Fri, 21 Jan 2022 22:49:38 GMT, Mandy Chung wrote: > The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From darcy at openjdk.java.net Sat Jan 22 19:29:45 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 22 Jan 2022 19:29:45 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v6] In-Reply-To: References: Message-ID: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8280168 - Appease jcheck. - Add toIdentityString - Respond to review feedback to augment test. - Respond to review feedback. - JDK-8280168 Add Objects.toDefaultString ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/0f6f0786..0a4d8a4f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=04-05 Stats: 6376 lines in 249 files changed: 4107 ins; 1549 del; 720 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Sat Jan 22 21:15:29 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 22 Jan 2022 21:15:29 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build Message-ID: Use presumed syntax that will be introduced by JDK-8280488. ------------- Commit messages: - JDK-8280492: Address remaining doclint issues in JDK build Changes: https://git.openjdk.java.net/jdk/pull/7189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280492 Stats: 57 lines in 17 files changed: 0 ins; 0 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/7189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7189/head:pull/7189 PR: https://git.openjdk.java.net/jdk/pull/7189 From darcy at openjdk.java.net Sat Jan 22 21:38:04 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 22 Jan 2022 21:38:04 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. This should be the (near) final step to fully enable all doclint checks during the javac portion of the build. The "reference" doclint check is currently disabled in the build command for several modules. The problematic references are cross-module @see and @link tags. This PR changes those tags to use a to a new proposed syntax for cross-module references. Before this PR is pushed, the javadoc changes need to be made and I'll update the make files to enable the "reference" warning category. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From jkuhn at openjdk.java.net Sat Jan 22 21:53:02 2022 From: jkuhn at openjdk.java.net (Johannes Kuhn) Date: Sat, 22 Jan 2022 21:53:02 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags In-Reply-To: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Fri, 21 Jan 2022 22:49:38 GMT, Mandy Chung wrote: > The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. When testing this patch from a named module and not-exported package, I get the following exception: Exception in thread "main" java.lang.reflect.UndeclaredThrowableException at jdk.proxy1/com.sun.proxy.jdk.proxy1.$Proxy0.toString(Unknown Source) at test.openjdk/test.openjdk.ProxyTest.main(ProxyTest.java:22) Caused by: java.lang.IllegalAccessException: class java.lang.invoke.MethodHandleProxies$1 (in module java.base) cannot access interface test.openjdk.ProxyTest$Test (in module test.openjdk) because module test.openjdk does not export test.openjdk to module java.base at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:394) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.InvocationHandler.invokeDefault(InvocationHandler.java:278) at java.base/java.lang.invoke.MethodHandleProxies$1.invoke(MethodHandleProxies.java:202) ... 2 more [My test code](https://gist.github.com/DasBrain/60dbc1c9075b15635d9c87e8295f1c1a). Running without the patch results in the wrong output for default varargs methods, so this is a regression. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From iris at openjdk.java.net Sun Jan 23 04:20:09 2022 From: iris at openjdk.java.net (Iris Clark) Date: Sun, 23 Jan 2022 04:20:09 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From serb at openjdk.java.net Sun Jan 23 08:09:08 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 23 Jan 2022 08:09:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From lancea at openjdk.java.net Sun Jan 23 11:48:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 23 Jan 2022 11:48:06 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: <2G0jVnCjP0i0VZhKN-fy0jDFtkT3BbBVcBiOJdxT56c=.870ed070-ad3c-4c88-bced-9ccb6155867b@github.com> On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From djelinski at openjdk.java.net Mon Jan 24 08:09:04 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 24 Jan 2022 08:09:04 GMT Subject: RFR: 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md In-Reply-To: References: Message-ID: <6H7ByIE0exrvC76VNJncAIeXIno7GvxJeztKwFw-dFM=.0b40544c-ea07-4bd7-a67b-6af9799ab4e8@github.com> On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeli?ski wrote: > Reported by clang-tidy. Verified manually by running > > Calendar c = Calendar.getInstance(); > System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault())); > > with `-Djava.locale.providers=HOST` > > Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array. > > No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7184 From shade at openjdk.java.net Mon Jan 24 09:21:13 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 24 Jan 2022 09:21:13 GMT Subject: RFR: 8280459: Suspicious integer division in Hashtable.readHashtable In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 15:19:38 GMT, Aleksey Shipilev wrote: > Found by Sonar. See details in the bug. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `java/util/Hashtable` Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7178 From shade at openjdk.java.net Mon Jan 24 09:21:14 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 24 Jan 2022 09:21:14 GMT Subject: Integrated: 8280459: Suspicious integer division in Hashtable.readHashtable In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 15:19:38 GMT, Aleksey Shipilev wrote: > Found by Sonar. See details in the bug. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `java/util/Hashtable` This pull request has now been integrated. Changeset: d1569111 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/d1569111d7077dd95b95aea6c42616f85d85e781 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8280459: Suspicious integer division in Hashtable.readHashtable Reviewed-by: rriggs, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7178 From shade at openjdk.java.net Mon Jan 24 09:46:45 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 24 Jan 2022 09:46:45 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases [v3] In-Reply-To: References: Message-ID: > While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test still passes > - [x] Linux AArch64 fastdebug, affected test still passes > - [x] Linux PPC64 fastdebug, affected test still passes Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Update copyright dates - Merge branch 'master' into JDK-8280166-getobjectsize - Merge branch 'master' into JDK-8280166-getobjectsize - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7132/files - new: https://git.openjdk.java.net/jdk/pull/7132/files/dd9ce049..98653011 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7132&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7132&range=01-02 Stats: 327 lines in 51 files changed: 159 ins; 67 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/7132.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7132/head:pull/7132 PR: https://git.openjdk.java.net/jdk/pull/7132 From shade at openjdk.java.net Mon Jan 24 09:46:47 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 24 Jan 2022 09:46:47 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases [v2] In-Reply-To: References: Message-ID: <2qFw5Ej9cnqsUFRSRXb2nSs6hxp27w7v3TtN9T7WQsk=.caa1102c-773e-420b-9e71-2f17024562ce@github.com> On Fri, 21 Jan 2022 16:19:07 GMT, Leonid Mesnik wrote: > Please update copyright years. Updated, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7132 From dfuchs at openjdk.java.net Mon Jan 24 11:04:04 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 11:04:04 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by dfuchs (Reviewer). LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`... ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From aturbanov at openjdk.java.net Mon Jan 24 11:17:11 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 24 Jan 2022 11:17:11 GMT Subject: Integrated: 8280174: Possible NPE in Thread.dispatchUncaughtException In-Reply-To: <6ukocdm79dKe2debIMO2ScgE56c4rXK8kFM5wNG38E4=.128081a2-2758-4e53-b84b-4c10f1ac4aca@github.com> References: <6ukocdm79dKe2debIMO2ScgE56c4rXK8kFM5wNG38E4=.128081a2-2758-4e53-b84b-4c10f1ac4aca@github.com> Message-ID: On Mon, 17 Jan 2022 20:56:56 GMT, Andrey Turbanov wrote: > Method `Thread.dispatchUncaughtException` (called by VM) uses result of of `getUncaughtExceptionHandler`. Field `uncaughtExceptionHandler` is volatile and can be changed by another Thread. Which could lead to NPE. > https://github.com/openjdk/jdk/blob/7b6738fa02023825ed9e602555bd5ed2b87a6ca6/src/java.base/share/classes/java/lang/Thread.java#L2007-L2009 > Read field to local variable to avoid double volatile read. This pull request has now been integrated. Changeset: f05ff996 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/f05ff996543d0239383d8b363fdbba15769c4aae Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8280174: Possible NPE in Thread.dispatchUncaughtException Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7117 From prappo at openjdk.java.net Mon Jan 24 11:21:08 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 Jan 2022 11:21:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> References: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> Message-ID: On Mon, 24 Jan 2022 11:00:37 GMT, Daniel Fuchs wrote: > LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`... They will do it quicker, if you create new or support existing bugs in their bug trackers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From prappo at openjdk.java.net Mon Jan 24 11:36:04 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 Jan 2022 11:36:04 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From aturbanov at openjdk.java.net Mon Jan 24 12:05:06 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 24 Jan 2022 12:05:06 GMT Subject: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 21:10:39 GMT, Andrey Turbanov wrote: > Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: > > ----------System.out:(12/489)---------- > --- Testing df > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > D: 59672 59672 0 100% /cygdrive/d > > > SecurityManager = null > C:/Programs/cygwin64: > df total= 299877003264 free = 0 usable = 248988995584 > getX total= 299877003264 free = 248988995584 usable = 248988995584 > :: > df total= 61104128 free = 0 usable = 0 > getX total= 0 free = 0 usable = 0 > ----------System.err:(23/1617)---------- > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) > at java.base/java.io.File.toPath(File.java:2396) > at GetXSpace.compare(GetXSpace.java:223) > at GetXSpace.testDF(GetXSpace.java:403) > at GetXSpace.main(GetXSpace.java:437) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > Parsing of df output is incorrect. It skips first symbols after matching of line. > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L160 > > It means that after matching first line: > > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > > > It skips first symbols of next line - symbol `D` and then proceeds to match _corrupted_ line: > > : 59672 59672 0 100% /cygdrive/d > > > Problems affects only Windows, because only in Windows case first group of matcher is used: > > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L155-L156 > > > Testing: > * Windows x64 - always failed before. No errors after fix > * Linux x64 @ArnoZeller can you please check if proposed changes fix the test in your environment? @bplb can you please have a look at this pr? ------------- PR: https://git.openjdk.java.net/jdk/pull/7170 From michaelm at openjdk.java.net Mon Jan 24 13:36:47 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 13:36:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - fixed failing test issue and update for latest comments - Merge branch 'master' into spnego - added root cause to NamingException - more tidy-up - removed sasl module dependency and added SaslException cause - changes after first review round - cleanup but still no test. Will be added in closed repo - First version of fix. No test and feature enabled always. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/058c3830..ad80dfa2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=04-05 Stats: 17855 lines in 614 files changed: 12290 ins; 2870 del; 2695 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Mon Jan 24 13:36:50 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 13:36:50 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5] In-Reply-To: <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <1NSEl8gBmZgk91vM_b41BbQ9iGLIcXs-qBIhgeTfk6I=.c0b2a3f6-8f43-404c-89b0-619cad355f85@github.com> Message-ID: On Fri, 21 Jan 2022 19:48:02 GMT, Weijun Wang wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> added root cause to NamingException > > src/java.base/share/classes/java/net/doc-files/net-properties.html line 220: > >> 218: This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos >> 219: or the Negotiate authentication scheme using Kerberos are employed over HTTPS with >> 220: {@code HttpsURLConnection}. There are three possible settings:

> > You can probably mention here that the 'tls-server-end-point' Channel Binding Type defined in RFC 5929 is used. I've updated this and moved the two properties to LdapSasl where they are used. Also, the test that was failing before needed some further updates. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Mon Jan 24 13:57:10 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 13:57:10 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - fixed failing test issue and update for latest comments > - Merge branch 'master' into spnego > - added root cause to NamingException > - more tidy-up > - removed sasl module dependency and added SaslException cause > - changes after first review round > - cleanup but still no test. Will be added in closed repo > - First version of fix. No test and feature enabled always. src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 260: > 258: * @throws ChannelBindingException > 259: */ > 260: private static TlsChannelBindingType parseType(String cbType) throws ChannelBindingException { Maybe this method could throw NamingException directly now? That would avoid wrapping CBE into NamingException? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Mon Jan 24 15:32:22 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 15:32:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - fixed failing test issue and update for latest comments > - Merge branch 'master' into spnego > - added root cause to NamingException > - more tidy-up > - removed sasl module dependency and added SaslException cause > - changes after first review round > - cleanup but still no test. Will be added in closed repo > - First version of fix. No test and feature enabled always. src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100: > (failed to retrieve contents of file, check the PR for context) I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Mon Jan 24 15:32:22 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 15:32:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Fri, 21 Jan 2022 15:40:16 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> more tidy-up > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144: > >> 142: } catch (ChannelBindingException e) { >> 143: throw new NamingException(e.getMessage()); >> 144: } > > Should we call initCause here and above? I see that we do call initCause in NegotiatorImpl.java. > On the one hand it's better for diagnostic. On the other hand it exposes a module-internal exception class which is not great. Or maybe we should set the cause of the CBE as the cause of NamingException. As long as the spec has not dictated what the cause should be, I don't care if the exception type is internal or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Mon Jan 24 15:32:23 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 15:32:23 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <3iOOsm_palWB0x2iybPZZ4rtiUY6ObLy33Cpd1nPgxs=.3e5ac581-d1c3-433f-82a8-0144e0867547@github.com> On Mon, 24 Jan 2022 13:54:12 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - fixed failing test issue and update for latest comments >> - Merge branch 'master' into spnego >> - added root cause to NamingException >> - more tidy-up >> - removed sasl module dependency and added SaslException cause >> - changes after first review round >> - cleanup but still no test. Will be added in closed repo >> - First version of fix. No test and feature enabled always. > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 260: > >> 258: * @throws ChannelBindingException >> 259: */ >> 260: private static TlsChannelBindingType parseType(String cbType) throws ChannelBindingException { > > Maybe this method could throw NamingException directly now? That would avoid wrapping CBE into NamingException? My opinion is this method should be put back. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Mon Jan 24 15:57:15 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 15:57:15 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 15:23:44 GMT, Weijun Wang wrote: >> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - fixed failing test issue and update for latest comments >> - Merge branch 'master' into spnego >> - added root cause to NamingException >> - more tidy-up >> - removed sasl module dependency and added SaslException cause >> - changes after first review round >> - cleanup but still no test. Will be added in closed repo >> - First version of fix. No test and feature enabled always. > > src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100: > >> (failed to retrieve contents of file, check the PR for context) > I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP. So, where should the two constant Strings go? It doesn't feel like they belong in java.base since they are JNDI/SASL related, and we can't have a method in `java.base` depending on code in other modules? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From igraves at openjdk.java.net Mon Jan 24 16:27:20 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 Jan 2022 16:27:20 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match Message-ID: Replacing a buggy NPE with a PatternSyntaxException for cases with a bad intersection operator. ------------- Commit messages: - 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match Changes: https://git.openjdk.java.net/jdk/pull/7199/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7199&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280403 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7199/head:pull/7199 PR: https://git.openjdk.java.net/jdk/pull/7199 From igraves at openjdk.java.net Mon Jan 24 17:23:12 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 Jan 2022 17:23:12 GMT Subject: Withdrawn: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 16:22:08 GMT, Ian Graves wrote: > Replacing a buggy NPE with a PatternSyntaxException for cases with a bad intersection operator. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7199 From igraves at openjdk.java.net Mon Jan 24 17:29:21 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 Jan 2022 17:29:21 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match Message-ID: Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException ------------- Commit messages: - 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match Changes: https://git.openjdk.java.net/jdk/pull/7201/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7201&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280403 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7201/head:pull/7201 PR: https://git.openjdk.java.net/jdk/pull/7201 From bpb at openjdk.java.net Mon Jan 24 17:44:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 24 Jan 2022 17:44:11 GMT Subject: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 21:10:39 GMT, Andrey Turbanov wrote: > Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: > > ----------System.out:(12/489)---------- > --- Testing df > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > D: 59672 59672 0 100% /cygdrive/d > > > SecurityManager = null > C:/Programs/cygwin64: > df total= 299877003264 free = 0 usable = 248988995584 > getX total= 299877003264 free = 248988995584 usable = 248988995584 > :: > df total= 61104128 free = 0 usable = 0 > getX total= 0 free = 0 usable = 0 > ----------System.err:(23/1617)---------- > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) > at java.base/java.io.File.toPath(File.java:2396) > at GetXSpace.compare(GetXSpace.java:223) > at GetXSpace.testDF(GetXSpace.java:403) > at GetXSpace.main(GetXSpace.java:437) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > Parsing of df output is incorrect. It skips first symbols after matching of line. > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L160 > > It means that after matching first line: > > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > > > It skips first symbols of next line - symbol `D` and then proceeds to match _corrupted_ line: > > : 59672 59672 0 100% /cygdrive/d > > > Problems affects only Windows, because only in Windows case first group of matcher is used: > > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L155-L156 > > > Testing: > * Windows x64 - always failed before. No errors after fix > * Linux x64 Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7170 From lancea at openjdk.java.net Mon Jan 24 17:51:11 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 24 Jan 2022 17:51:11 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7201 From darcy at openjdk.java.net Mon Jan 24 18:25:08 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 18:25:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 11:33:18 GMT, Pavel Rappo wrote: > > Use presumed syntax that will be introduced by JDK-8280488. > > Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags. Ah; thanks Pavel for the additional context. Bug JDK-8280488 will allow (i.e. ignore) cross-module @see/@link references during javac compilation. So while the syntax in this PR is already valid per JDK-8164408, I cannot (yet) enable the "reference" doctlint check in the javac build due to the cross-module situation. I'll double-check the syntax in this PR generates the expected links in the result of the docs builds, give the bug a more descriptive title, and get these changes pushed. Enabling the reference warning can be done under another bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From iris at openjdk.java.net Mon Jan 24 18:43:08 2022 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 24 Jan 2022 18:43:08 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7201 From aivanov at openjdk.java.net Mon Jan 24 18:57:10 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 24 Jan 2022 18:57:10 GMT Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From aturbanov at openjdk.java.net Mon Jan 24 18:22:29 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 24 Jan 2022 18:22:29 GMT Subject: RFR: 8280531: Remove unused DeferredCloseInputStream Message-ID: Class DeferredCloseInputStream is unused since removing of Solaris support https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 ------------- Commit messages: - [PATCH] Remove unused DeferredCloseInputStream Changes: https://git.openjdk.java.net/jdk/pull/7135/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7135&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280531 Stats: 106 lines in 1 file changed: 0 ins; 104 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7135/head:pull/7135 PR: https://git.openjdk.java.net/jdk/pull/7135 From bpb at openjdk.java.net Mon Jan 24 19:11:09 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 24 Jan 2022 19:11:09 GMT Subject: RFR: 8280531: Remove unused DeferredCloseInputStream In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 20:51:06 GMT, Andrey Turbanov wrote: > Class DeferredCloseInputStream is unused since removing of Solaris support > https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7135 From weijun at openjdk.java.net Mon Jan 24 19:13:11 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 Jan 2022 19:13:11 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Mon, 24 Jan 2022 15:54:01 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line 100: >> >>> (failed to retrieve contents of file, check the PR for context) >> I think this method should stay here. Suppose one day the CBT type is configurable for HTTPS we'll have to get it back. Of course we will need to update the message to avoid talking about LDAP. > > So, where should the two constant Strings go? It doesn't feel like they belong in java.base since they are JNDI/SASL related, and we can't have a method in `java.base` depending on code in other modules? The 2 strings should be on the LDAP side. This method does not really depend on the strings except for mentioning one in the exception message. We can just rewrite it into `"Illegal channel binding type: " + cbType`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From alanb at openjdk.java.net Mon Jan 24 19:22:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 24 Jan 2022 19:22:10 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v6] In-Reply-To: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> References: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> Message-ID: On Sat, 22 Jan 2022 19:29:45 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 295: > 293: assert(isObjectMethod(m)) : m; > 294: return switch (m.getName()) { > 295: case "toString" -> java.util.Objects.toDefaultString(self); It might be better if toString is changed to invoke toIdentityString(self), only because hashCode returns the identity hash code, it doesn't invoke hashCode(). ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From naoto at openjdk.java.net Mon Jan 24 19:29:05 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 24 Jan 2022 19:29:05 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: <65-wDnmpSZUKtMjO-FDkgFR2iiY4K1YrxQP6Q_pmWjQ=.972bcf55-409f-4bb1-b61e-c599e7571d58@github.com> On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7201 From djelinski at openjdk.java.net Mon Jan 24 19:35:14 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 24 Jan 2022 19:35:14 GMT Subject: Integrated: 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeli?ski wrote: > Reported by clang-tidy. Verified manually by running > > Calendar c = Calendar.getInstance(); > System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault())); > > with `-Djava.locale.providers=HOST` > > Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array. > > No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works. This pull request has now been integrated. Changeset: a5416669 Author: Daniel Jeli?ski Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/a5416669a57a7739af13efc32ec084560527862b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md Reviewed-by: naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7184 From smarks at openjdk.java.net Mon Jan 24 20:00:12 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 24 Jan 2022 20:00:12 GMT Subject: RFR: JDK-8280168 Add Objects.toDefaultString [v6] In-Reply-To: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> References: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> Message-ID: <5vBOWtFysotE7q7ceQhxsgns3Yyp1OQe_YKqQdIBmm8=.ccb38cf8-1450-4278-a4e0-3b6782169041@github.com> On Sat, 22 Jan 2022 19:29:45 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString I'm wondering if we want to have `toDefaultString` at all, and whether we should have just `toIdentityString`. The primary use case, it seems to me, is the ability to get a string representation for some object, without involving any code in that object itself. There are the collections with cycles that I mentioned previously (in comments on the CSR), for which there is no well-defined hashCode. There is also the case that when logging mutable objects, the hashCode can change over time. This makes it difficult to analyze a log file and track what happens to a particular object. (I know I've been confused by this phenomenon in the past.) Thus `toDefaultString` doesn't seem all that useful to me. It may be that the current use cases in the JDK can be replaced with `toDefaultString` but not `toIdentityString` without changing their behavior. But maybe we should consider changing their behavior and use `toIdentityString` instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From jwilhelm at openjdk.java.net Mon Jan 24 20:00:50 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 24 Jan 2022 20:00:50 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18 - 8280441: Missing "classpath exception" in several files from jdk.httpserver - 8279179: Update nroff pages in JDK 18 before RC The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7203&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7203&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7203/files Stats: 62 lines in 10 files changed: 46 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/7203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7203/head:pull/7203 PR: https://git.openjdk.java.net/jdk/pull/7203 From darcy at openjdk.java.net Mon Jan 24 20:10:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 20:10:40 GMT Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links [v2] In-Reply-To: References: Message-ID: <8CLBwHk3ls8ijDaN-6poNrhGMxCulNGrjFvImPGQ-sY=.e8629cdc-b51d-4614-a5af-923f848d0703@github.com> > Use presumed syntax that will be introduced by JDK-8280488. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Update copyrigths. - Merge branch 'master' into JDK-8280492 - JDK-8280492: Address remaining doclint issues in JDK build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7189/files - new: https://git.openjdk.java.net/jdk/pull/7189/files/b74e7d85..6f3bd429 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=00-01 Stats: 664 lines in 55 files changed: 433 ins; 128 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/7189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7189/head:pull/7189 PR: https://git.openjdk.java.net/jdk/pull/7189 From rriggs at openjdk.java.net Mon Jan 24 20:13:09 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 24 Jan 2022 20:13:09 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7201 From darcy at openjdk.java.net Mon Jan 24 20:20:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 20:20:12 GMT Subject: Integrated: JDK-8280492: Use cross-module syntax for cross-module links In-Reply-To: References: Message-ID: <2oUpK1s5mNt-fWdUF5YZP3MlqzjXypdqMMz8QG-3Q5U=.f971fd74-655b-400d-9718-11299edcb7c8@github.com> On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. This pull request has now been integrated. Changeset: 8e82d002 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/8e82d0021c119b7793870811fad37d7659c1174d Stats: 72 lines in 17 files changed: 0 ins; 0 del; 72 mod 8280492: Use cross-module syntax for cross-module links Reviewed-by: iris, serb, lancea, dfuchs, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From rriggs at openjdk.java.net Mon Jan 24 20:22:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 24 Jan 2022 20:22:05 GMT Subject: RFR: 8280531: Remove unused DeferredCloseInputStream In-Reply-To: References: Message-ID: <2z8xA4Q9HOIKC51RNgGDaUR4-xb1PsfLIBPTnrtKtRo=.9a80645a-e8f0-497c-982f-fc5245109f66@github.com> On Tue, 18 Jan 2022 20:51:06 GMT, Andrey Turbanov wrote: > Class DeferredCloseInputStream is unused since removing of Solaris support > https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7135 From aturbanov at openjdk.java.net Mon Jan 24 21:01:10 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 24 Jan 2022 21:01:10 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException test/jdk/java/util/regex/RegExTest.java line 4551: > 4549: } > 4550: > 4551: //This test is for This comment is confusing. Shouldn't it include JBS ID? ------------- PR: https://git.openjdk.java.net/jdk/pull/7201 From darcy at openjdk.java.net Mon Jan 24 21:31:37 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 21:31:37 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v7] In-Reply-To: References: Message-ID: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Respond to review feedback. - Merge branch 'master' into JDK-8280168 - Merge branch 'master' into JDK-8280168 - Appease jcheck. - Add toIdentityString - Respond to review feedback to augment test. - Respond to review feedback. - JDK-8280168 Add Objects.toDefaultString ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/0a4d8a4f..b7ef3017 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=05-06 Stats: 862 lines in 62 files changed: 548 ins; 203 del; 111 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Mon Jan 24 21:31:41 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 21:31:41 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v6] In-Reply-To: References: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> Message-ID: On Mon, 24 Jan 2022 19:19:21 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8280168 >> - Appease jcheck. >> - Add toIdentityString >> - Respond to review feedback to augment test. >> - Respond to review feedback. >> - JDK-8280168 Add Objects.toDefaultString > > src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 295: > >> 293: assert(isObjectMethod(m)) : m; >> 294: return switch (m.getName()) { >> 295: case "toString" -> java.util.Objects.toDefaultString(self); > > It might be better if toString is changed to invoke toIdentityString(self), only because hashCode returns the identity hash code, it doesn't invoke hashCode(). Yes; that looks like an inconsistency/bug. Updated in a subsequent push. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Mon Jan 24 21:33:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 21:33:12 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v6] In-Reply-To: <5vBOWtFysotE7q7ceQhxsgns3Yyp1OQe_YKqQdIBmm8=.ccb38cf8-1450-4278-a4e0-3b6782169041@github.com> References: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> <5vBOWtFysotE7q7ceQhxsgns3Yyp1OQe_YKqQdIBmm8=.ccb38cf8-1450-4278-a4e0-3b6782169041@github.com> Message-ID: On Mon, 24 Jan 2022 19:56:55 GMT, Stuart Marks wrote: > I'm wondering if we want to have `toDefaultString` at all, and whether we should have just `toIdentityString`. The primary use case, it seems to me, is the ability to get a string representation for some object, without involving any code in that object itself. There are the collections with cycles that I mentioned previously (in comments on the CSR), for which there is no well-defined hashCode. There is also the case that when logging mutable objects, the hashCode can change over time. This makes it difficult to analyze a log file and track what happens to a particular object. (I know I've been confused by this phenomenon in the past.) Thus `toDefaultString` doesn't seem all that useful to me. > > It may be that the current use cases in the JDK can be replaced with `toDefaultString` but not `toIdentityString` without changing their behavior. But maybe we should consider changing their behavior and use `toIdentityString` instead. Updated the PR to just have toIdentityString and make corresponding changes to the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From plevart at openjdk.java.net Mon Jan 24 21:35:08 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 24 Jan 2022 21:35:08 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v4] In-Reply-To: <3D6SSMiDJOz_WS2uaENCZn8VYnnCJrFXVaKgTalADiE=.5fde3e99-6fae-4ad7-8128-6159ffe4601f@github.com> References: <3D6SSMiDJOz_WS2uaENCZn8VYnnCJrFXVaKgTalADiE=.5fde3e99-6fae-4ad7-8128-6159ffe4601f@github.com> Message-ID: <9Yb-sfMvC0PtyeqB-j1u2fjiDCqD2uu0rrBpqK4wWbc=.0a1a75dc-4e95-4db5-9205-9946e58ba5e1@github.com> On Fri, 21 Jan 2022 11:04:22 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; >> - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Guarantee progress for at least one thread > - Merge branch 'master' into JDK-8280041-classcache-problems > - Test summary > - GC sanity test > - NullValueTest > - Merge branch 'master' into JDK-8280041-classcache-problems > - Fix This looks good, although I don't know whether the additional check for strongReferent != null is needed in clearStrong(). This is all racy code and you have already got a non-null return from getStrong() in case you are calling clearStrong()... ------------- Marked as reviewed by plevart (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7092 From igraves at openjdk.java.net Mon Jan 24 21:39:58 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 Jan 2022 21:39:58 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match [v2] In-Reply-To: References: Message-ID: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Fixing docs and dates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7201/files - new: https://git.openjdk.java.net/jdk/pull/7201/files/9a64df4a..3189490a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7201&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7201&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7201/head:pull/7201 PR: https://git.openjdk.java.net/jdk/pull/7201 From igraves at openjdk.java.net Mon Jan 24 21:39:58 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 Jan 2022 21:39:58 GMT Subject: RFR: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: <-KsoJxtzEARmzilH3Z86q-1ZerAXOfYZGjTyWmJPQls=.edf39296-a1de-494d-bc1c-22c8674e71b1@github.com> On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException Thanks @turbanoff , left off the JBS ID in the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7201 From forax at openjdk.java.net Mon Jan 24 21:54:07 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 24 Jan 2022 21:54:07 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 21:31:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280168 > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString toIdentityString is a better name than toDefaultString. It's fine for me but given that "identity" has a slightly different meaning in the context of Valhalla that in System.identityHashCode(), it may be good to ask Brian about that name. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From jwilhelm at openjdk.java.net Mon Jan 24 21:57:13 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 24 Jan 2022 21:57:13 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 19:51:08 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 52ddbe2d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/52ddbe2dcdb2fa52d85c987443ffa14522ace729 Stats: 62 lines in 10 files changed: 46 ins; 0 del; 16 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7203 From iris at openjdk.java.net Mon Jan 24 22:01:08 2022 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 24 Jan 2022 22:01:08 GMT Subject: RFR: 8280531: Remove unused DeferredCloseInputStream In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 20:51:06 GMT, Andrey Turbanov wrote: > Class DeferredCloseInputStream is unused since removing of Solaris support > https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7135 From mchung at openjdk.java.net Mon Jan 24 22:04:07 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 24 Jan 2022 22:04:07 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v6] In-Reply-To: References: <_T9g1AjZmjW_NW8nMNLrHa90Ir1YTDw6XPOXMpy0sOs=.ce96b5ff-ec33-481f-a452-2cbc7e33d799@github.com> Message-ID: <63gr47niUpFtMcXRJxh93J5dYK43BJZnPDCzy_DhNAY=.cfbbf980-586a-4b53-8167-09fb4690df8e@github.com> On Mon, 24 Jan 2022 21:27:06 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 295: >> >>> 293: assert(isObjectMethod(m)) : m; >>> 294: return switch (m.getName()) { >>> 295: case "toString" -> java.util.Objects.toDefaultString(self); >> >> It might be better if toString is changed to invoke toIdentityString(self), only because hashCode returns the identity hash code, it doesn't invoke hashCode(). > > Yes; that looks like an inconsistency/bug. Updated in a subsequent push. Yes, it's a bug and it should call the one with identity hash code. The `toString` method of a Proxy instance should return the result of the default implementation of `Object::toString` method as specified. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Mon Jan 24 22:10:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 22:10:06 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v7] In-Reply-To: References: Message-ID: <8xCds-CnxBcREpPCU77tZeuq-UReVMZm44RkfsydCZA=.e1e8cc70-22f3-4c04-a273-80b87d5c82a4@github.com> On Mon, 24 Jan 2022 21:51:13 GMT, R?mi Forax wrote: > toIdentityString is a better name than toDefaultString. > > It's fine for me but given that "identity" has a slightly different meaning in the context of Valhalla that in System.identityHashCode(), it may be good to ask Brian about that name. Modulo the method name, I have discussed with Brian adding a method with toIdentityString's semantics to Objects and he agreed the method was worth having. ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From michaelm at openjdk.java.net Mon Jan 24 22:11:51 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 24 Jan 2022 22:11:51 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: more updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/ad80dfa2..0d529f9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=05-06 Stats: 38 lines in 2 files changed: 18 ins; 19 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From igraves at openjdk.java.net Mon Jan 24 22:25:15 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 24 Jan 2022 22:25:15 GMT Subject: Integrated: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 17:21:57 GMT, Ian Graves wrote: > Replacing a buggy NullPointerException in `Pattern.compile()` with the proper PatternSyntaxException This pull request has now been integrated. Changeset: e3076552 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/e3076552ec528864e61a6e0ec91e228006fddefc Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match Reviewed-by: lancea, iris, naoto, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7201 From mchung at openjdk.java.net Mon Jan 24 23:03:49 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 24 Jan 2022 23:03:49 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v2] In-Reply-To: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: > The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: - revert MethodHandlesProxiesTest change - Add new regression test - Should not perform access check on the interface as specified ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7185/files - new: https://git.openjdk.java.net/jdk/pull/7185/files/56542fc2..5d1f3477 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=00-01 Stats: 572 lines in 13 files changed: 412 ins; 158 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7185/head:pull/7185 PR: https://git.openjdk.java.net/jdk/pull/7185 From mchung at openjdk.java.net Mon Jan 24 23:05:23 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 24 Jan 2022 23:05:23 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Sat, 22 Jan 2022 21:48:38 GMT, Johannes Kuhn wrote: >> The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. > > When testing this patch from a named module and not-exported package, I get the following exception: > > > Exception in thread "main" java.lang.reflect.UndeclaredThrowableException > at jdk.proxy1/com.sun.proxy.jdk.proxy1.$Proxy0.toString(Unknown Source) > at test.openjdk/test.openjdk.ProxyTest.main(ProxyTest.java:22) > Caused by: java.lang.IllegalAccessException: class java.lang.invoke.MethodHandleProxies$1 (in module java.base) cannot access interface test.openjdk.ProxyTest$Test (in module test.openjdk) because module test.openjdk does not export test.openjdk to module java.base > at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:394) > at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) > at java.base/java.lang.reflect.InvocationHandler.invokeDefault(InvocationHandler.java:278) > at java.base/java.lang.invoke.MethodHandleProxies$1.invoke(MethodHandleProxies.java:202) > ... 2 more > > > [My test code](https://gist.github.com/DasBrain/60dbc1c9075b15635d9c87e8295f1c1a). > Running without the patch results in the wrong output for default varargs methods, so this is a regression. @DasBrain thanks for catching this. `MethodHandleProxies::asInterfaceInstance` should perform no additional access checks other than checking the interface is public and not sealed, as specified in the spec. The patch is updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From jkuhn at openjdk.java.net Mon Jan 24 23:08:59 2022 From: jkuhn at openjdk.java.net (Johannes Kuhn) Date: Mon, 24 Jan 2022 23:08:59 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v2] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Mon, 24 Jan 2022 23:03:49 GMT, Mandy Chung wrote: >> The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. > > Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: > > - revert MethodHandlesProxiesTest change > - Add new regression test > - Should not perform access check on the interface as specified Changes requested by jkuhn (Author). src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 206: > 204: if (isDefaultMethod(method)) { > 205: // no additional access check is performed > 206: return JLRA.invokeDefault(proxy, method, null, args); Isn't the argument order `..., args, caller`? src/java.base/share/classes/java/lang/reflect/ReflectAccess.java line 134: > 132: throws Throwable { > 133: return Proxy.invokeDefault(proxy, method, args, caller); > 134: } What about other, non-jdk code that wishes to implement a similar thing - make a proxy for an arbitrary interface and handle default methods by invoking them? ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From mchung at openjdk.java.net Mon Jan 24 23:18:41 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 24 Jan 2022 23:18:41 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v3] In-Reply-To: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: > The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: fix accident argument ordering after edit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7185/files - new: https://git.openjdk.java.net/jdk/pull/7185/files/5d1f3477..30f1a05e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7185/head:pull/7185 PR: https://git.openjdk.java.net/jdk/pull/7185 From mchung at openjdk.java.net Mon Jan 24 23:18:43 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 24 Jan 2022 23:18:43 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v2] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Mon, 24 Jan 2022 23:02:52 GMT, Johannes Kuhn wrote: >> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: >> >> - revert MethodHandlesProxiesTest change >> - Add new regression test >> - Should not perform access check on the interface as specified > > src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 206: > >> 204: if (isDefaultMethod(method)) { >> 205: // no additional access check is performed >> 206: return JLRA.invokeDefault(proxy, method, null, args); > > Isn't the argument order `..., args, caller`? Such edit was an accident. Fixed. > src/java.base/share/classes/java/lang/reflect/ReflectAccess.java line 134: > >> 132: throws Throwable { >> 133: return Proxy.invokeDefault(proxy, method, args, caller); >> 134: } > > What about other, non-jdk code that wishes to implement a similar thing - make a proxy for an arbitrary interface and handle default methods by invoking them? To invoke the default method, the caller will need access to the declaring interface of the default method (via bytecode invocation or reflection). The bug I had was because java.base (the module of the invocation handler) does not have access to the interface even though the caller has. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From naoto.sato at oracle.com Tue Jan 25 00:13:57 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 24 Jan 2022 16:13:57 -0800 Subject: Additional Date-Time Formats In-Reply-To: References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> Message-ID: <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> Updated the CSR (https://bugs.openjdk.java.net/browse/JDK-8243445), by adding a regular expression for the requested template. This way, it is less depending on the LDML specification. Naoto On 1/21/22 2:39 PM, Naoto Sato wrote: > Thanks, Joe. > > Good point. I will elaborate the pattern template part more, less > depending on the LDML spec. Would have been better if we could introduce > our own, such as ofLocalizedPattern(Set template), but not > exactly suffices the need. > > Naoto > > > > On 1/20/22 9:52 PM, Joe Wang wrote: >> Hi Naoto, >> >> The javadoc points to LDML, it seems to me though it might be useful >> to add more information similar to that for the ofPattern methods, >> what's under the "Patterns for Formatting and Parsing" section, so >> that for at least the common use cases we could rely on the javadoc >> without having to consult the LDML specification. Some comparison with >> the ofPattern methods might also be helpful. >> >> Just my 2 cents. >> >> Thanks, >> Joe >> >> On 1/20/22 1:46 PM, Naoto Sato wrote: >>> Hello, >>> >>> I am proposing a couple of new factory methods in >>> java.time.format.DateTimeFormatter that produce flexible localized >>> date/time formats, other than the existing pre-defined >>> (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a >>> year and month only string, such as the title for the calendar, >>> currently they would have to use DateTimeFormatter.ofPattern() with >>> explicit pattern argument, such as "MMM y". This is problematic >>> because it is correct in locales such as US, but not correct in other >>> locales. >>> >>> So, I propose methods that are parallel to ofPattern(), which take >>> pattern template. This is based on the CLDR's skeleton: >>> https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems >>> >>> >>> Detailed design can be found in the draft CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8243445 >>> >>> Comments are welcome. >>> >>> Naoto >>> >> From weijun at openjdk.java.net Tue Jan 25 00:44:44 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 25 Jan 2022 00:44:44 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7] In-Reply-To: <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <87RySLEYHWWcb-iT4G-Vu05dbqlwR3JNjuh68-_Vygs=.ae653848-efd2-4da5-9d89-c08a387aaf6e@github.com> Message-ID: On Mon, 24 Jan 2022 22:11:51 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > more updates Looks good to me. Only several wording and style suggestions. I know you are asking SQE to create a security infra test, but I'll see if I can contribute a regression test. Don't wait for me. src/java.base/share/classes/java/net/doc-files/net-properties.html line 223: > 221:
    > 222:

  1. "never". This is also the default value if the property is not set. In this case, > 223: CBT's are never sent.

    Typo, "CBTs"? src/java.base/share/classes/java/net/doc-files/net-properties.html line 224: > 222:

  2. "never". This is also the default value if the property is not set. In this case, > 223: CBT's are never sent.

    > 224:

  3. "always". CBTs are sent for all Kerberos authentication attempts over HTTPS.

    Shall we remove "Kerberos"? Or we can use "Kerberos or Negotiate". src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java line 1: > 1: /** This is not a doc comment. src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java line 124: > 122: try { > 123: init(hci); > 124: } catch (GSSException | ChannelBindingException e) { Two spaces before "e". ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7065 From smarks at openjdk.java.net Tue Jan 25 01:00:35 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 25 Jan 2022 01:00:35 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 21:31:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280168 > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From mchung at openjdk.java.net Tue Jan 25 01:30:44 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 25 Jan 2022 01:30:44 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 21:31:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280168 > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From dholmes at openjdk.java.net Tue Jan 25 01:40:35 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 Jan 2022 01:40:35 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin This needs reviewing by the jimage folk too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From huizhe.wang at oracle.com Tue Jan 25 01:50:16 2022 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 24 Jan 2022 17:50:16 -0800 Subject: Additional Date-Time Formats In-Reply-To: <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> Message-ID: <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> Hi Naoto, Nice use of regular expression! Saves a lot of description if I would just follow the regex pattern. Question: ?????? The 2nd and 3rd statements defined the requestedTemplate, does it imply the characters listed in the snippet are the only ones that are valid, in other words, can other characters under the Patterns section be used? It may be helpful to elaborate on the snippet a bit more. ?????? Also, the range implies a valid range for a particular symbol, if that's the case, y and w feel like they are unbound. If I do that with ofPettern, I get ArrayIndexOutOfBoundsException. For the sample code, it might be helpful to put them in a code snippet and with the actual java code. If "yMMM" formats to 'Jun 2020', that might require some explanation too since that would be the same as ofPattern("MMM y") for the default(US) locale, or was it a typo?. (I'm not familiar with the use of DTF, just printed out date.format(DTF.ofPattern("yMMM" and "MMM y") :-)) Joe On 1/24/22 4:13 PM, Naoto Sato wrote: > Updated the CSR (https://bugs.openjdk.java.net/browse/JDK-8243445), by > adding a regular expression for the requested template. This way, it > is less depending on the LDML specification. > > Naoto > > On 1/21/22 2:39 PM, Naoto Sato wrote: >> Thanks, Joe. >> >> Good point. I will elaborate the pattern template part more, less >> depending on the LDML spec. Would have been better if we could >> introduce our own, such as ofLocalizedPattern(Set >> template), but not exactly suffices the need. >> >> Naoto >> >> >> >> On 1/20/22 9:52 PM, Joe Wang wrote: >>> Hi Naoto, >>> >>> The javadoc points to LDML, it seems to me though it might be useful >>> to add more information similar to that for the ofPattern methods, >>> what's under the "Patterns for Formatting and Parsing" section, so >>> that for at least the common use cases we could rely on the javadoc >>> without having to consult the LDML specification. Some comparison >>> with the ofPattern methods might also be helpful. >>> >>> Just my 2 cents. >>> >>> Thanks, >>> Joe >>> >>> On 1/20/22 1:46 PM, Naoto Sato wrote: >>>> Hello, >>>> >>>> I am proposing a couple of new factory methods in >>>> java.time.format.DateTimeFormatter that produce flexible localized >>>> date/time formats, other than the existing pre-defined >>>> (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a >>>> year and month only string, such as the title for the calendar, >>>> currently they would have to use DateTimeFormatter.ofPattern() with >>>> explicit pattern argument, such as "MMM y". This is problematic >>>> because it is correct in locales such as US, but not correct in >>>> other locales. >>>> >>>> So, I propose methods that are parallel to ofPattern(), which take >>>> pattern template. This is based on the CLDR's skeleton: >>>> https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems >>>> >>>> >>>> Detailed design can be found in the draft CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8243445 >>>> >>>> Comments are welcome. >>>> >>>> Naoto >>>> >>> From dholmes at openjdk.java.net Tue Jan 25 02:03:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 Jan 2022 02:03:36 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin Hi Yumin, So let me see if I have this clear. - The jimage code was using the OS code (dlopen/loadlibrary etc) to try and load the zip library when needed. - The VM, which is always loaded first, always used to load the zip library unconditionally, hence the OS would simply return the JVM's zip handle to the jimage code. - When we changed the VM to only load the zip library if needed (not realizing jimage may also need it) then the jimage code would now only succeed if the zip library was in the appropriate lookup paths for the OS. - The fix is to change the jimage code so that it asks the JVM for the zip library, as the JVM is always setup correctly to find it. Does that sum it up? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From darcy at openjdk.java.net Tue Jan 25 02:49:55 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 02:49:55 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement Message-ID: Making the exception message friendlier to users. ------------- Commit messages: - JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement Changes: https://git.openjdk.java.net/jdk/pull/7208/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279242 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208 From dholmes at openjdk.java.net Tue Jan 25 03:54:35 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 Jan 2022 03:54:35 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 02:42:45 GMT, Joe Darcy wrote: > Making the exception message friendlier to users. src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 387: > 385: msg += "a member of " + memberClass + memberSuffix + > 386: (packageAccess ? > 387: " package access" : Suggestion: "with package access". ------------- PR: https://git.openjdk.java.net/jdk/pull/7208 From minqi at openjdk.java.net Tue Jan 25 05:06:39 2022 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 25 Jan 2022 05:06:39 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: <1iUBAAAsXbvt0D1eL1MfN_7H9Ou3T8RiDIEHQhp_5bI=.7a9bf5be-407f-452f-887d-879d92bebc70@github.com> On Tue, 25 Jan 2022 01:59:56 GMT, David Holmes wrote: > * The jimage code was using the OS code (dlopen/loadlibrary etc) to try and load the zip library when needed. Yes. The zip library has to be in PATH. > * The VM, which is always loaded first, always used to load the zip library unconditionally, hence the OS would simply return the JVM's zip handle to the jimage code. Yes. After the fix, jimage will use the version that JVM is using. > * When we changed the VM to only load the zip library if needed (not realizing jimage may also need it) then the jimage code would now only succeed if the zip library was in the appropriate lookup paths for the OS. Yes. When in JVM, zip library was always loaded (before https://bugs.openjdk.java.net/browse/JDK-8237750) so jimage in fact get the loaded zip handle from JVM. Unless user set PATH(other than jdk(jre)\bin) to contain the "zip.dll | libzip.so | libzip.dylib" then jimage will load and use that version. After this fix, jimage will use the same version as jvm. > * The fix is to change the jimage code so that it asks the JVM for the zip library, as the JVM is always setup correctly to find it. Yes. Thanks for taking a detail look. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From darcy at openjdk.java.net Tue Jan 25 05:25:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 05:25:12 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2] In-Reply-To: References: Message-ID: > Making the exception message friendlier to users. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7208/files - new: https://git.openjdk.java.net/jdk/pull/7208/files/c93b91ff..1885c04a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208 From darcy at openjdk.java.net Tue Jan 25 05:42:30 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 05:42:30 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 03:51:43 GMT, David Holmes wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 387: > >> 385: msg += "a member of " + memberClass + memberSuffix + >> 386: (packageAccess ? >> 387: " package access" : > > Suggestion: "with package access". Updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/7208 From iris at openjdk.java.net Tue Jan 25 05:58:33 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 25 Jan 2022 05:58:33 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 05:25:12 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7208 From dholmes at openjdk.java.net Tue Jan 25 06:07:35 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 Jan 2022 06:07:35 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 05:25:12 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Looks good. I see Mandy has suggested the same wording in the JBS issue. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7208 From dholmes at openjdk.java.net Tue Jan 25 06:14:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 Jan 2022 06:14:42 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin Seems okay as long as there are no concerns from jimage folk about usage scenarios we may not be aware of. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7206 From aturbanov at openjdk.java.net Tue Jan 25 08:12:40 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 25 Jan 2022 08:12:40 GMT Subject: Integrated: 8280470: Confusing instanceof check in HijrahChronology.range In-Reply-To: References: Message-ID: On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote: > Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`. > But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`. This pull request has now been integrated. Changeset: 53804720 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/53804720a04b5b314701de82eddf1a55798eba00 Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod 8280470: Confusing instanceof check in HijrahChronology.range Reviewed-by: rriggs, naoto, dfuchs, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7118 From alanb at openjdk.java.net Tue Jan 25 08:26:38 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 08:26:38 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 21:31:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280168 > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString Updated proposal and naming looks okay. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7139 From mbaesken at openjdk.java.net Tue Jan 25 08:29:05 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 25 Jan 2022 08:29:05 GMT Subject: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v2] In-Reply-To: References: Message-ID: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7155/files - new: https://git.openjdk.java.net/jdk/pull/7155/files/666fdee0..8f2169cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7155/head:pull/7155 PR: https://git.openjdk.java.net/jdk/pull/7155 From mbaesken at openjdk.java.net Tue Jan 25 08:33:21 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 25 Jan 2022 08:33:21 GMT Subject: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v3] In-Reply-To: References: Message-ID: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add LastModified ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7155/files - new: https://git.openjdk.java.net/jdk/pull/7155/files/8f2169cb..69584e8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7155&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7155/head:pull/7155 PR: https://git.openjdk.java.net/jdk/pull/7155 From mbaesken at openjdk.java.net Tue Jan 25 08:33:22 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 25 Jan 2022 08:33:22 GMT Subject: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 In-Reply-To: <78xJzEH4j6WTkfNljXgN2XhzY3UYepaK2FuQaExZ9Bs=.93995dce-5521-4122-9787-7e5779e0db2b@github.com> References: <78xJzEH4j6WTkfNljXgN2XhzY3UYepaK2FuQaExZ9Bs=.93995dce-5521-4122-9787-7e5779e0db2b@github.com> Message-ID: <9eb01LBNgCcvBzocw02DjS-TYf4xDeAzXcL9xPA5bPo=.9b05c8b3-81be-45cd-8317-0d7e4f0bec65@github.com> On Thu, 20 Jan 2022 23:32:33 GMT, Joe Wang wrote: > Thanks Alan for the reminder. The change looks good. Please add a copyright header and the LastModified tag as the other class did. Hi, I added the header and LastModified. Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/7155 From michaelm at openjdk.java.net Tue Jan 25 10:30:20 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 25 Jan 2022 10:30:20 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: final review update (pre CSR) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/0d529f9d..004466ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=06-07 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From stuefe at openjdk.java.net Tue Jan 25 10:32:37 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 25 Jan 2022 10:32:37 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already? For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7206 From myano at openjdk.java.net Tue Jan 25 10:55:57 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 25 Jan 2022 10:55:57 GMT Subject: RFR: 8266974: duplicate property key in java.sql.rowset resource bundle Message-ID: I have removed the duplicate property keys. Could you please review the fix? ------------- Commit messages: - 8266974: duplicate property key in java.sql.rowset resource bundle Changes: https://git.openjdk.java.net/jdk/pull/7212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266974 Stats: 22 lines in 11 files changed: 0 ins; 11 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7212/head:pull/7212 PR: https://git.openjdk.java.net/jdk/pull/7212 From dfuchs at openjdk.java.net Tue Jan 25 11:13:37 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 25 Jan 2022 11:13:37 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > final review update (pre CSR) The new version LGTM. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7065 From lancea at openjdk.java.net Tue Jan 25 11:29:32 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 25 Jan 2022 11:29:32 GMT Subject: RFR: 8266974: duplicate property key in java.sql.rowset resource bundle In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 10:47:41 GMT, Masanori Yano wrote: > I have removed the duplicate property keys. > Could you please review the fix? Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7212 From duke at openjdk.java.net Tue Jan 25 11:38:35 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Tue, 25 Jan 2022 11:38:35 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 10:30:20 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > final review update (pre CSR) src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: > 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is > 149: * a comma separated list of arbitrary length with no white-space allowed. > 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include Previously `Negotiate` was used, now `SPNEGO`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Tue Jan 25 12:50:37 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 25 Jan 2022 12:50:37 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 11:34:57 GMT, Michael Osipov wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> final review update (pre CSR) > > src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: > >> 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is >> 149: * a comma separated list of arbitrary length with no white-space allowed. >> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include > > Previously `Negotiate` was used, now `SPNEGO`? "Negotiate" is the name of the HTTP authentication scheme which uses the SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From duke at openjdk.java.net Tue Jan 25 13:03:33 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Tue, 25 Jan 2022 13:03:33 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v8] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Tue, 25 Jan 2022 12:47:26 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 150: >> >>> 148: * "domain:a,c.d,*.e.f" (sent to host a, or c.d or to the domain e.f and any of its subdomains). This is >>> 149: * a comma separated list of arbitrary length with no white-space allowed. >>> 150: * If enabled (for a particular destination) then SPNEGO authentication requests will include >> >> Previously `Negotiate` was used, now `SPNEGO`? > > "Negotiate" is the name of the HTTP authentication scheme which uses the SPNEGO mechanism. Possibly makes more sense to refer to Negotiate here. Yes, I know. That's the point. Clearly differentiate between GSS-API mech and HTTP auth scheme. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From alanb at openjdk.java.net Tue Jan 25 14:41:36 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 14:41:36 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v3] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: <37Kqqtlo1kxEuIrkZIBUhlKcEHtGbvQOaCw2wcuDx_w=.1f73af06-e70e-4869-acf6-80f733d4e402@github.com> On Mon, 24 Jan 2022 23:18:41 GMT, Mandy Chung wrote: >> The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix accident argument ordering after edit Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java line 107: > 105: > 106: public Object invokeDefault(Object proxy, Method method, Object[] args, Class caller) > 107: throws Throwable; Minor nit: add a comment to the method so that it's consistent with the other JLRA methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From rriggs at openjdk.java.net Tue Jan 25 14:41:37 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 Jan 2022 14:41:37 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v7] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 21:31:37 GMT, Joe Darcy wrote: >> While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280168 > - Merge branch 'master' into JDK-8280168 > - Appease jcheck. > - Add toIdentityString > - Respond to review feedback to augment test. > - Respond to review feedback. > - JDK-8280168 Add Objects.toDefaultString Looks good ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7139 From alanb at openjdk.java.net Tue Jan 25 14:41:37 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 14:41:37 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v2] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Mon, 24 Jan 2022 23:13:24 GMT, Mandy Chung wrote: > To invoke the default method, the caller will need access to the declaring interface of the default method (via bytecode invocation or reflection). The bug I had was because java.base (the module of the invocation handler) does not have access to the interface even though the caller has. So invokeDefault is moved to Proxy with an optional access check, and you've made it callable from MHProxies by way of JLRA. I think that is okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From mcimadamore at openjdk.java.net Tue Jan 25 15:32:07 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 25 Jan 2022 15:32:07 GMT Subject: [jdk18] RFR: 8280592: Small javadoc tweaks to foreign API Message-ID: This patch fixes some inconsistencies in the foreign API javadoc. The main fix is to make javadoc of all predicate methods consistent, and to use the `@return` tag where appropriate, as to avoid duplication. There were also minor fixes in the package-level javadoc (one typo) and in `ValueLayout` (where hyphenation in *bit-alignment* has been dropped). ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk18/pull/113/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=113&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280592 Stats: 91 lines in 12 files changed: 0 ins; 42 del; 49 mod Patch: https://git.openjdk.java.net/jdk18/pull/113.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/113/head:pull/113 PR: https://git.openjdk.java.net/jdk18/pull/113 From msheppar at openjdk.java.net Tue Jan 25 15:33:34 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Tue, 25 Jan 2022 15:33:34 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: <95CuJQqoVfJOEdYeRhgTJbLqdQwyyGvBlDR2WoyIsfg=.2230a07d-ad5f-457f-ac33-283e732cda25@github.com> Message-ID: On Fri, 21 Jan 2022 17:07:37 GMT, Mark Sheppard wrote: >> Good point. I think its better to deal with the casts at the edges since the timeout handling will use long by default. > > yes a redeclaration of timeout with a type long across the component would be a consistent approach, also so just to clarify, we're not taking the approach to homogenise the timeout declarations, throughout the component, to be of type long? which would see LdapClientFactory constructor take a long timeout and timeout member varaiables be redefined as long ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From shade at openjdk.java.net Tue Jan 25 16:15:30 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 16:15:30 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v4] In-Reply-To: <9Yb-sfMvC0PtyeqB-j1u2fjiDCqD2uu0rrBpqK4wWbc=.0a1a75dc-4e95-4db5-9205-9946e58ba5e1@github.com> References: <3D6SSMiDJOz_WS2uaENCZn8VYnnCJrFXVaKgTalADiE=.5fde3e99-6fae-4ad7-8128-6159ffe4601f@github.com> <9Yb-sfMvC0PtyeqB-j1u2fjiDCqD2uu0rrBpqK4wWbc=.0a1a75dc-4e95-4db5-9205-9946e58ba5e1@github.com> Message-ID: <8FLF_RVQgqh7iZ_8y8hi5fe55iCzfv2G72xe3nH0ZZQ=.19f1865d-1556-4789-8372-5350d80f2c17@github.com> On Mon, 24 Jan 2022 21:32:16 GMT, Peter Levart wrote: > This looks good, although I don't know whether the additional check for strongReferent != null is needed in clearStrong(). This is all racy code and you have already got a non-null return from getStrong() in case you are calling clearStrong()... This seems like a standard thing to do to avoid multi-threaded write contention under the race. By the time one thread calls `clearStrong`, some other thread might have already cleared it, and we don't have to clear again. Granted, that is a micro-optimization, but I'd like to avoid surprises on this path :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Tue Jan 25 16:22:30 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 16:22:30 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 20:07:10 GMT, Roger Riggs wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; >> - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > It may not be worth it. If not, add the label "noreg-hard". > > It is possible for add to the test description the modules to be opened: > > * @modules java.base/java.io:open > > jtreg will add the appropriate command line args when it is compiled and run. > There are various examples in existing test/jdk/java/io... tests. @RogerRiggs, are you happy with tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Tue Jan 25 16:23:35 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 16:23:35 GMT Subject: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases [v3] In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Update copyright dates >> - Merge branch 'master' into JDK-8280166-getobjectsize >> - Merge branch 'master' into JDK-8280166-getobjectsize >> - Fix > > test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 326: > >> 324: >> 325: public static void main(String[] args)throws Throwable { >> 326: new GetObjectSizeIntrinsicsTest(args[0], (args.length >= 2 ? args[1] : "")).runTest(); > > Shouldn't this be `args.length == 2`? @plummercj This does not look like a review-blocking comment, so I am going to proceed with integration, if there are no other comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7132 From shade at openjdk.java.net Tue Jan 25 16:33:10 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 16:33:10 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v5] In-Reply-To: References: Message-ID: <0U3QKqS9MXCbZoPNK4yB1EeXPnncL41ImjY3zsxzhkA=.8db05ef3-f48f-42bb-83b8-2624c00408e0@github.com> > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Drop unnecessary null check in clearStrong - Merge branch 'master' into JDK-8280041-classcache-problems - Guarantee progress for at least one thread - Merge branch 'master' into JDK-8280041-classcache-problems - Test summary - GC sanity test - NullValueTest - Merge branch 'master' into JDK-8280041-classcache-problems - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7092/files - new: https://git.openjdk.java.net/jdk/pull/7092/files/0f2dcd0d..17073ef2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7092&range=03-04 Stats: 330 lines in 51 files changed: 159 ins; 70 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/7092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7092/head:pull/7092 PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Tue Jan 25 16:33:12 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 16:33:12 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v4] In-Reply-To: <8FLF_RVQgqh7iZ_8y8hi5fe55iCzfv2G72xe3nH0ZZQ=.19f1865d-1556-4789-8372-5350d80f2c17@github.com> References: <3D6SSMiDJOz_WS2uaENCZn8VYnnCJrFXVaKgTalADiE=.5fde3e99-6fae-4ad7-8128-6159ffe4601f@github.com> <9Yb-sfMvC0PtyeqB-j1u2fjiDCqD2uu0rrBpqK4wWbc=.0a1a75dc-4e95-4db5-9205-9946e58ba5e1@github.com> <8FLF_RVQgqh7iZ_8y8hi5fe55iCzfv2G72xe3nH0ZZQ=.19f1865d-1556-4789-8372-5350d80f2c17@github.com> Message-ID: On Tue, 25 Jan 2022 16:12:11 GMT, Aleksey Shipilev wrote: > > This looks good, although I don't know whether the additional check for strongReferent != null is needed in clearStrong(). This is all racy code and you have already got a non-null return from getStrong() in case you are calling clearStrong()... > > This seems like a standard thing to do to avoid multi-threaded write contention under the race. By the time one thread calls `clearStrong`, some other thread might have already cleared it, and we don't have to clear again. Granted, that is a micro-optimization, but I'd like to avoid surprises on this path :) Actually, the window after the first `strongVal != null` check is not that large that a second null check would matter. Dropped the null check in `clearStrong` for simplicity. (IIRC, it mattered a bit in prior internal iterations of my patch). ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From psandoz at openjdk.java.net Tue Jan 25 17:03:44 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 25 Jan 2022 17:03:44 GMT Subject: [jdk18] RFR: 8280592: Small javadoc tweaks to foreign API In-Reply-To: References: Message-ID: <3xJpjna475nxR0RvcwtsOnW5_ORofyXYCbeJV6o7qFY=.5e19509c-c495-439b-b7ef-b2c04dc9d8e4@github.com> On Tue, 25 Jan 2022 15:22:30 GMT, Maurizio Cimadamore wrote: > This patch fixes some inconsistencies in the foreign API javadoc. The main fix is to make javadoc of all predicate methods consistent, and to use the `@return` tag where appropriate, as to avoid duplication. > > There were also minor fixes in the package-level javadoc (one typo) and in `ValueLayout` (where hyphenation in *bit-alignment* has been dropped). Marked as reviewed by psandoz (Reviewer). src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java line 43: > 41: > 42: /** > 43: * {@return the {@linkplain MemoryAddress memory address} associated with this addressable} Oh, i just learnt a new JavaDoc trick! ------------- PR: https://git.openjdk.java.net/jdk18/pull/113 From mchung at openjdk.java.net Tue Jan 25 17:13:35 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 25 Jan 2022 17:13:35 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 05:25:12 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. There is another `newIllegalAccessException(Class memberClass, int modifiers)` method that also needs to be updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7208 From rriggs at openjdk.java.net Tue Jan 25 17:15:32 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 Jan 2022 17:15:32 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v5] In-Reply-To: <0U3QKqS9MXCbZoPNK4yB1EeXPnncL41ImjY3zsxzhkA=.8db05ef3-f48f-42bb-83b8-2624c00408e0@github.com> References: <0U3QKqS9MXCbZoPNK4yB1EeXPnncL41ImjY3zsxzhkA=.8db05ef3-f48f-42bb-83b8-2624c00408e0@github.com> Message-ID: <9_NDc2tS5vegOn2NsRLV8-RUh-2ep93O8VQPKKS6N8c=.0ea4e6fc-1651-4fd3-9322-2eb5788e7072@github.com> On Tue, 25 Jan 2022 16:33:10 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; >> - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Drop unnecessary null check in clearStrong > - Merge branch 'master' into JDK-8280041-classcache-problems > - Guarantee progress for at least one thread > - Merge branch 'master' into JDK-8280041-classcache-problems > - Test summary > - GC sanity test > - NullValueTest > - Merge branch 'master' into JDK-8280041-classcache-problems > - Fix Looks good, thanks for the tests. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7092 From mchung at openjdk.java.net Tue Jan 25 17:23:38 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 25 Jan 2022 17:23:38 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v3] In-Reply-To: <37Kqqtlo1kxEuIrkZIBUhlKcEHtGbvQOaCw2wcuDx_w=.1f73af06-e70e-4869-acf6-80f733d4e402@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> <37Kqqtlo1kxEuIrkZIBUhlKcEHtGbvQOaCw2wcuDx_w=.1f73af06-e70e-4869-acf6-80f733d4e402@github.com> Message-ID: On Tue, 25 Jan 2022 14:36:26 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix accident argument ordering after edit > > src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java line 107: > >> 105: >> 106: public Object invokeDefault(Object proxy, Method method, Object[] args, Class caller) >> 107: throws Throwable; > > Minor nit: add a comment to the method so that it's consistent with the other JLRA methods. What about this: /** Invokes the given default method if the method's declaring interface is * accessible to the given caller. Otherwise, IllegalAccessException will * be thrown. If the caller is null, no access check is performed. */ public Object invokeDefault(Object proxy, Method method, Object[] args, Class caller) throws Throwable; ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From minqi at openjdk.java.net Tue Jan 25 17:26:34 2022 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 25 Jan 2022 17:26:34 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 10:29:48 GMT, Thomas Stuefe wrote: > I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already? > > For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point. Thanks for review. Before 8237750, the zip library is always loaded so jimage just get the handle of the loaded zip by calling . After that, zip is loaded at need, so if jvm does not use zip, it will not be loaded. Unfortunately, it does not realize that jimage is using this zip, so it failed to get the handle. But there exists a case, if the zip is in PATH, the following fix 8244495 used LoadLibrary("zip.dll") for a rescue. If zip.dll is not in PATH, the call still failed to load zip. This is the current issue. So far, if user loaded zip from native code before jimage code is executed ( I could not image a scenario how it can happen), the GetModuleHandle("zip.dll") may return the handle to it, but it does not surely it is for the "zip.dll" --- if multiple instances exist, the returned handle is not guaranteed the one you want. With this change, if user loads zip from native code (with different version), JVM does not sense that, it will still load zip from $JDK or $JRE, and jimage still uses handle returned from JVM. The only case is JVM failed to load zip library: if (_zip_handle == NULL) { vm_exit_during_initialization("Unable to load zip library", path); } You cannot make any progress on the failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From darcy at openjdk.java.net Tue Jan 25 18:03:18 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 18:03:18 GMT Subject: RFR: JDK-8280168: Add Objects.toIdentityString [v8] In-Reply-To: References: Message-ID: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright, remove author tag. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7139/files - new: https://git.openjdk.java.net/jdk/pull/7139/files/b7ef3017..2cf7a54d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7139&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7139/head:pull/7139 PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Tue Jan 25 18:19:37 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 18:19:37 GMT Subject: Integrated: JDK-8280168: Add Objects.toIdentityString In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 23:15:20 GMT, Joe Darcy wrote: > While it is strongly recommend to not use the default toString for a class, at times it is the least-bad alternative. When that alternative needs to be used, it would be helpful to have the implementation already available, such as in Objects.toDefaultString(). This method is analagous to System.identityHashCode. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8280184 This pull request has now been integrated. Changeset: cbe8395a Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/cbe8395ace3230dc599c7f082e3524a861b2da8e Stats: 61 lines in 3 files changed: 56 ins; 1 del; 4 mod 8280168: Add Objects.toIdentityString Reviewed-by: alanb, mchung, rriggs, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/7139 From darcy at openjdk.java.net Tue Jan 25 18:21:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 18:21:06 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v3] In-Reply-To: References: Message-ID: <99sMQOJjM6o5x-ufvbHqGqBIVkbN1dLj3zBXBq8Rdz0=.d2489f1f-ba56-4371-9eed-1ae4e95b6324@github.com> > Making the exception message friendlier to users. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7208/files - new: https://git.openjdk.java.net/jdk/pull/7208/files/1885c04a..9cff95dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=01-02 Stats: 25 lines in 1 file changed: 10 ins; 12 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208 From darcy at openjdk.java.net Tue Jan 25 18:25:14 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 18:25:14 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v4] In-Reply-To: References: Message-ID: > Making the exception message friendlier to users. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7208/files - new: https://git.openjdk.java.net/jdk/pull/7208/files/9cff95dc..d0011e41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208 From darcy at openjdk.java.net Tue Jan 25 18:25:16 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 18:25:16 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 17:10:33 GMT, Mandy Chung wrote: > There is another `newIllegalAccessException(Class memberClass, int modifiers)` method that also needs to be updated. Updated accordingly and refactored slightly to pull out the string suffix construction into a new method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7208 From joehw at openjdk.java.net Tue Jan 25 18:50:30 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 25 Jan 2022 18:50:30 GMT Subject: RFR: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 [v3] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 08:33:21 GMT, Matthias Baesken wrote: >> After 8270492 >> https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 >> has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add LastModified Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7155 From iris at openjdk.java.net Tue Jan 25 19:01:35 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 25 Jan 2022 19:01:35 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v4] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 18:25:14 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7208 From mchung at openjdk.java.net Tue Jan 25 19:24:40 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 25 Jan 2022 19:24:40 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v4] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 18:25:14 GMT, Joe Darcy wrote: >> Making the exception message friendlier to users. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7208 From shade at openjdk.java.net Tue Jan 25 19:24:43 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 19:24:43 GMT Subject: RFR: 8280041: Retry loop issues in java.io.ClassCache [v5] In-Reply-To: <0U3QKqS9MXCbZoPNK4yB1EeXPnncL41ImjY3zsxzhkA=.8db05ef3-f48f-42bb-83b8-2624c00408e0@github.com> References: <0U3QKqS9MXCbZoPNK4yB1EeXPnncL41ImjY3zsxzhkA=.8db05ef3-f48f-42bb-83b8-2624c00408e0@github.com> Message-ID: On Tue, 25 Jan 2022 16:33:10 GMT, Aleksey Shipilev wrote: >> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: >> - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; >> - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; >> >> Attention @rkennke, @plevart. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Drop unnecessary null check in clearStrong > - Merge branch 'master' into JDK-8280041-classcache-problems > - Guarantee progress for at least one thread > - Merge branch 'master' into JDK-8280041-classcache-problems > - Test summary > - GC sanity test > - NullValueTest > - Merge branch 'master' into JDK-8280041-classcache-problems > - Fix All right, we seem to be good to go. ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Tue Jan 25 19:24:43 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 19:24:43 GMT Subject: Integrated: 8280041: Retry loop issues in java.io.ClassCache In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote: > JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two issues with it: > - The cache cannot disambiguate between cleared SoftReference and the accidental passing of `null` value; in that case, the retry loop would spin indefinitely; > - If retry loop would spin several times, every time discovering a cleared SoftReference, it would create and register new SoftReference on the ReferenceQueue. However, it would not *drain* the RQ in the loop; in that case, we might have the unbounded garbage accumulating in RQ; > > Attention @rkennke, @plevart. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` This pull request has now been integrated. Changeset: cebaad1c Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/cebaad1c94c301304fd146526cac95bfeaac66bf Stats: 202 lines in 5 files changed: 190 ins; 0 del; 12 mod 8280041: Retry loop issues in java.io.ClassCache Co-authored-by: Peter Levart Reviewed-by: rkennke, rriggs, plevart ------------- PR: https://git.openjdk.java.net/jdk/pull/7092 From shade at openjdk.java.net Tue Jan 25 19:26:41 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 25 Jan 2022 19:26:41 GMT Subject: Integrated: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote: > While working on JDK-8280003, I noticed that java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with more than 1-byte size elements, and no large arrays (past 4G limit) are tested either. It would be better to add those test cases. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test still passes > - [x] Linux x86_32 fastdebug, affected test still passes > - [x] Linux AArch64 fastdebug, affected test still passes > - [x] Linux PPC64 fastdebug, affected test still passes This pull request has now been integrated. Changeset: 76fe03fe Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/76fe03fe01a7c824e2e9263de95b8bcbb4b9d752 Stats: 89 lines in 1 file changed: 62 ins; 0 del; 27 mod 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases Reviewed-by: sspitsyn, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/7132 From darcy at openjdk.java.net Tue Jan 25 20:10:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 20:10:06 GMT Subject: RFR: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement [v5] In-Reply-To: References: Message-ID: > Making the exception message friendlier to users. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve formatting. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7208/files - new: https://git.openjdk.java.net/jdk/pull/7208/files/d0011e41..f92b8f78 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7208&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7208.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7208/head:pull/7208 PR: https://git.openjdk.java.net/jdk/pull/7208 From darcy at openjdk.java.net Tue Jan 25 20:10:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 20:10:07 GMT Subject: Integrated: JDK-8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 02:42:45 GMT, Joe Darcy wrote: > Making the exception message friendlier to users. This pull request has now been integrated. Changeset: 295c0474 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/295c0474c43484e793b67a70af316aaae49fe361 Stats: 19 lines in 1 file changed: 10 ins; 6 del; 3 mod 8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement Reviewed-by: iris, dholmes, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7208 From alanb at openjdk.java.net Tue Jan 25 20:20:29 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 20:20:29 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v3] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> <37Kqqtlo1kxEuIrkZIBUhlKcEHtGbvQOaCw2wcuDx_w=.1f73af06-e70e-4869-acf6-80f733d4e402@github.com> Message-ID: On Tue, 25 Jan 2022 17:20:50 GMT, Mandy Chung wrote: > What about this: Looks okay, main thing is to have it be consistent with the existing methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From rriggs at openjdk.java.net Tue Jan 25 20:27:29 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 25 Jan 2022 20:27:29 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 15:57:58 GMT, Roger Riggs wrote: > The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. > The result is retention of the class loader. > > The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. > The test verifies that the process reaper threads have a null context classloader. @AlanBateman Can you take a look at this use of InnocuousThread. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7131 From mchung at openjdk.java.net Tue Jan 25 21:35:27 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 25 Jan 2022 21:35:27 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4] In-Reply-To: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: > The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: add comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7185/files - new: https://git.openjdk.java.net/jdk/pull/7185/files/30f1a05e..3f31d379 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7185&range=02-03 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7185/head:pull/7185 PR: https://git.openjdk.java.net/jdk/pull/7185 From mcimadamore at openjdk.java.net Tue Jan 25 21:48:43 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 25 Jan 2022 21:48:43 GMT Subject: [jdk18] RFR: 8280592: Small javadoc tweaks to foreign API In-Reply-To: <3xJpjna475nxR0RvcwtsOnW5_ORofyXYCbeJV6o7qFY=.5e19509c-c495-439b-b7ef-b2c04dc9d8e4@github.com> References: <3xJpjna475nxR0RvcwtsOnW5_ORofyXYCbeJV6o7qFY=.5e19509c-c495-439b-b7ef-b2c04dc9d8e4@github.com> Message-ID: On Tue, 25 Jan 2022 17:00:34 GMT, Paul Sandoz wrote: >> This patch fixes some inconsistencies in the foreign API javadoc. The main fix is to make javadoc of all predicate methods consistent, and to use the `@return` tag where appropriate, as to avoid duplication. >> >> There were also minor fixes in the package-level javadoc (one typo) and in `ValueLayout` (where hyphenation in *bit-alignment* has been dropped). > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java line 43: > >> 41: >> 42: /** >> 43: * {@return the {@linkplain MemoryAddress memory address} associated with this addressable} > > Oh, i just learnt a new JavaDoc trick! heh - me too - hat tip to @pavelrappo :-) ------------- PR: https://git.openjdk.java.net/jdk18/pull/113 From darcy at openjdk.java.net Tue Jan 25 21:55:58 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 25 Jan 2022 21:55:58 GMT Subject: RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly Message-ID: Update the java.lang.{Math, StrictMath} regression test helper library to accept method references. This allows the test programs to be DRY-er as the inputs to the method under test don't have to be repeated. The float test method were not updated due to limitations in type inference if both float and double methods with functional interface parameters are present. Also did some general tidying up for the test code. ------------- Commit messages: - Appease jcheck. - Further refactoring. - Update copyright year, remove author tags. - JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly Changes: https://git.openjdk.java.net/jdk/pull/7216/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270476 Stats: 455 lines in 27 files changed: 118 ins; 145 del; 192 mod Patch: https://git.openjdk.java.net/jdk/pull/7216.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7216/head:pull/7216 PR: https://git.openjdk.java.net/jdk/pull/7216 From jkuhn at openjdk.java.net Tue Jan 25 22:04:30 2022 From: jkuhn at openjdk.java.net (Johannes Kuhn) Date: Tue, 25 Jan 2022 22:04:30 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Tue, 25 Jan 2022 21:35:27 GMT, Mandy Chung wrote: >> The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > add comment My question was for when a library wants to implement something similar to `MethodHandleProxies.asInterfaceInstace`, and for example supports Interfaces with more than a single abstract method. Currently, such a library would also have to call `ReflectAccess.invokeDefault`, as the interface may not be accessible by the `InvocationHandler` (as it could be the case with `MethodHandleProxies.asInterfaceInstace` But this might be a discussion for an other time. Patch looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From naoto.sato at oracle.com Tue Jan 25 22:30:25 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 25 Jan 2022 14:30:25 -0800 Subject: Additional Date-Time Formats In-Reply-To: <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> Message-ID: Hi Joe, On 1/24/22 5:50 PM, Joe Wang wrote: > ?????? The 2nd and 3rd statements defined the requestedTemplate, does > it imply the characters listed in the snippet are the only ones that are > valid, in other words, can other characters under the Patterns section > be used? It may be helpful to elaborate on the snippet a bit more. Those symbols represent each field, so other symbols are considered illegal as a template symbol. Added some explanation there. > ?????? Also, the range implies a valid range for a particular symbol, > if that's the case, y and w feel like they are unbound. If I do that > with ofPettern, I get ArrayIndexOutOfBoundsException. The spec of 'year' and 'number' presentations do not have any upper limit number of letters, thus I added the '*' quantifier. Not exactly sure why AIOOBE is thrown with ofPattern(), could be a separate bug? It should be zero-padded or sign-padded. > > For the sample code, it might be helpful to put them in a code snippet > and with the actual java code. If "yMMM" formats to 'Jun 2020', that > might require some explanation too since that would be the same as > ofPattern("MMM y") for the default(US) locale, or was it a typo?. (I'm > not familiar with the use of DTF, just printed out > date.format(DTF.ofPattern("yMMM" and "MMM y") :-)) Well, it is not a typo and `ofLocalizedPattern("yMMM", Locale.US)` and `ofPattern("MMM y", Locale.US)` both generating the same result is exactly what this API is aiming at. Users don't need to pay attention to locale specific format pattern with this API. HTH, Naoto From huizhe.wang at oracle.com Tue Jan 25 23:49:11 2022 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 25 Jan 2022 15:49:11 -0800 Subject: Additional Date-Time Formats In-Reply-To: References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> Message-ID: Hi Naoto, Looks good to me, and thanks for the explanation. I agree, AIOOBE would be a separate bug with ofPattern. Thanks, Joe On 1/25/22 2:30 PM, Naoto Sato wrote: > Hi Joe, > > On 1/24/22 5:50 PM, Joe Wang wrote: >> ??????? The 2nd and 3rd statements defined the requestedTemplate, >> does it imply the characters listed in the snippet are the only ones >> that are valid, in other words, can other characters under the >> Patterns section be used? It may be helpful to elaborate on the >> snippet a bit more. > > Those symbols represent each field, so other symbols are considered > illegal as a template symbol. Added some explanation there. > >> ??????? Also, the range implies a valid range for a particular >> symbol, if that's the case, y and w feel like they are unbound. If I >> do that with ofPettern, I get ArrayIndexOutOfBoundsException. > > The spec of 'year' and 'number' presentations do not have any upper > limit number of letters, thus I added the '*' quantifier. Not exactly > sure why AIOOBE is thrown with ofPattern(), could be a separate bug? > It should be zero-padded or sign-padded. > >> >> For the sample code, it might be helpful to put them in a code >> snippet and with the actual java code. If "yMMM" formats to 'Jun >> 2020', that might require some explanation too since that would be >> the same as ofPattern("MMM y") for the default(US) locale, or was it >> a typo?. (I'm not familiar with the use of DTF, just printed out >> date.format(DTF.ofPattern("yMMM" and "MMM y") :-)) > > Well, it is not a typo and `ofLocalizedPattern("yMMM", Locale.US)` and > `ofPattern("MMM y", Locale.US)` both generating the same result is > exactly what this API is aiming at. Users don't need to pay attention > to locale specific format pattern with this API. > > HTH, > Naoto From duke at openjdk.java.net Wed Jan 26 00:09:36 2022 From: duke at openjdk.java.net (liach) Date: Wed, 26 Jan 2022 00:09:36 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Tue, 25 Jan 2022 22:01:22 GMT, Johannes Kuhn wrote: > My question was for when a library wants to implement something similar to `MethodHandleProxies.asInterfaceInstace`, and for example supports Interfaces with more than a single abstract method. Currently, such a library would also have to call `ReflectAccess.invokeDefault`, as the interface may not be accessible by the `InvocationHandler` (as it could be the case with `MethodHandleProxies.asInterfaceInstace` > > But this might be a discussion for an other time. Patch looks good. They will probably accept a `MethodHandles.Lookup` object to define a class for such a single-interface instance plus calling the default methods beyond the restrictions. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From darcy at openjdk.java.net Wed Jan 26 00:20:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 26 Jan 2022 00:20:07 GMT Subject: RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly [v2] In-Reply-To: References: Message-ID: > Update the java.lang.{Math, StrictMath} regression test helper library to accept method references. This allows the test programs to be DRY-er as the inputs to the method under test don't have to be repeated. The float test method were not updated due to limitations in type inference if both float and double methods with functional interface parameters are present. > > Also did some general tidying up for the test code. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Use consistent syntax for main method. - Merge branch 'master' into JDK-8270476 - Appease jcheck. - Further refactoring. - Update copyright year, remove author tags. - JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7216/files - new: https://git.openjdk.java.net/jdk/pull/7216/files/e040a8ea..789782ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=00-01 Stats: 2042 lines in 266 files changed: 1058 ins; 227 del; 757 mod Patch: https://git.openjdk.java.net/jdk/pull/7216.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7216/head:pull/7216 PR: https://git.openjdk.java.net/jdk/pull/7216 From vromero at openjdk.java.net Wed Jan 26 00:36:36 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 26 Jan 2022 00:36:36 GMT Subject: Integrated: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero wrote: > Hi, > > Please review this change that is fixing a bug in reflection in particular in `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current code is assuming that for inner class constructors, there are only type annotations on parameters, but it is also invoked to extract type annotations applied to exception types for example. This bug affects the behavior of method: `java.lang.reflect.Executable::getAnnotatedExceptionTypes` which is not behaving according to its specification. Given that this fix affects the behavior of a method belonging to our API a CSR has been filed too. Please review it at [JDK-8278926](https://bugs.openjdk.java.net/browse/JDK-8278926). > > TIA This pull request has now been integrated. Changeset: 2eab86b5 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/2eab86b513a9e4566b3f5989f899ae44280d3834 Stats: 16 lines in 2 files changed: 11 ins; 1 del; 4 mod 8213905: reflection not working for type annotations applied to exception types in the inner class constructor Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/6869 From duke at openjdk.java.net Wed Jan 26 00:52:57 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Wed, 26 Jan 2022 00:52:57 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random Message-ID: Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 ------------- Commit messages: - No need to synchronize setSeed nextGaussian - No need to synchronize setSeed - Fix whitespace and tab - Rewrite javadoc - Add copyright notice - Make use of the new wrapper function - Add static method to create wrapper - implement RandomGenerator interface - Fix imports - Create asRandom() method in RandomGenerator - ... and 1 more: https://git.openjdk.java.net/jdk/compare/d47af74e...fbdf4969 Changes: https://git.openjdk.java.net/jdk/pull/7001/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279598 Stats: 171 lines in 2 files changed: 171 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From mchung at openjdk.java.net Wed Jan 26 01:12:35 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 26 Jan 2022 01:12:35 GMT Subject: RFR: 8280377: MethodHandleProxies does not correctly invoke default methods with varags [v4] In-Reply-To: References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Wed, 26 Jan 2022 00:06:25 GMT, liach wrote: > They will probably accept a MethodHandles.Lookup object to define a class for such a single-interface instance plus calling the default methods beyond the restrictions. Yes, that's one option. Such library should take a Lookup parameter to find the method handle for the default method as in the previous `MethodHandleProxies` implementation. Alternatively, the module of the target interface will need to be open to the library's module for deep reflection and the library can use `MethodHandles::privateLookupIn` to lookup the default method then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From mcimadamore at openjdk.java.net Wed Jan 26 01:16:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 26 Jan 2022 01:16:42 GMT Subject: [jdk18] Integrated: 8280592: Small javadoc tweaks to foreign API In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 15:22:30 GMT, Maurizio Cimadamore wrote: > This patch fixes some inconsistencies in the foreign API javadoc. The main fix is to make javadoc of all predicate methods consistent, and to use the `@return` tag where appropriate, as to avoid duplication. > > There were also minor fixes in the package-level javadoc (one typo) and in `ValueLayout` (where hyphenation in *bit-alignment* has been dropped). This pull request has now been integrated. Changeset: ef08e2c6 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk18/commit/ef08e2c63b040cef6ca5f71dbce49f3d7647fdd8 Stats: 91 lines in 12 files changed: 0 ins; 42 del; 49 mod 8280592: Small javadoc tweaks to foreign API Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk18/pull/113 From mchung at openjdk.java.net Wed Jan 26 01:28:36 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 26 Jan 2022 01:28:36 GMT Subject: Integrated: 8280377: MethodHandleProxies does not correctly invoke default methods with varags In-Reply-To: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> References: <3aIv9nC3vktiYwk9szSt_xrxO7UnYPcS_-KjwWT4H7E=.37bd74a3-ecb7-40f7-a050-853704011367@github.com> Message-ID: On Fri, 21 Jan 2022 22:49:38 GMT, Mandy Chung wrote: > The MethodHandle of a default method should be made as a fixed arity method handle because it is invoked via Proxy's invocation handle with a non-vararg array of arguments. On the other hand, the `InvocationHandle::invokeDefault` method was added in Java 16 to invoke a default method of a proxy instance. This patch simply converts the implementation to call `InvocationHandle::invokeDefault` instead. This pull request has now been integrated. Changeset: a183bfb4 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/a183bfb436a7dd998e602c2d16486e88c390fca1 Stats: 358 lines in 12 files changed: 292 ins; 63 del; 3 mod 8280377: MethodHandleProxies does not correctly invoke default methods with varags Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7185 From darcy at openjdk.java.net Wed Jan 26 02:29:55 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 26 Jan 2022 02:29:55 GMT Subject: RFR: JDK-8280550: SplittableRandom#nextDouble(double,double) can return result >= bound Message-ID: Use floating-point library methods to nudge down the result if needed. The nextAfter(r, origin) call return the next value in the direction of origin, handling cases for negative values, etc. Changing to call nextDown for the origin is bounded at zero is just a refactoring that is clearer to read IMO. The regression test fails on an unpatched JDK. ------------- Commit messages: - Appease jcheck - JDK-8280550: SplittableRandom#nextDouble(double,double) can return result >= bound Changes: https://git.openjdk.java.net/jdk/pull/7221/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280550 Stats: 54 lines in 2 files changed: 52 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7221.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7221/head:pull/7221 PR: https://git.openjdk.java.net/jdk/pull/7221 From stuefe at openjdk.java.net Wed Jan 26 05:54:30 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 26 Jan 2022 05:54:30 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 17:22:54 GMT, Yumin Qi wrote: >> I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already? >> >> For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point. > >> I'm curious, under what circumstances would, before https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a scenario where the JVM was not involved and hence the zip.dll was not loaded already? >> >> For me, the code looks good unless I miss a scenario where we don't have the JVM loaded already at this point. > > Thanks for review. Before 8237750, the zip library is always loaded so jimage just get the handle of the loaded zip by calling . After that, zip is loaded at need, so if jvm does not use zip, it will not be loaded. Unfortunately, it does not realize that jimage is using this zip, so it failed to get the handle. But there exists a case, if the zip is in PATH, the following fix 8244495 used LoadLibrary("zip.dll") for a rescue. If zip.dll is not in PATH, the call still failed to load zip. This is the current issue. > > So far, if user loaded zip from native code before jimage code is executed ( I could not image a scenario how it can happen), the GetModuleHandle("zip.dll") may return the handle to it, but it does not surely it is for the "zip.dll" --- if multiple instances exist, the returned handle is not guaranteed the one you want. > > With this change, if user loads zip from native code (with different version), JVM does not sense that, it will still load zip from $JDK or $JRE, and jimage still uses handle returned from JVM. The only case is JVM failed to load zip library: > > if (_zip_handle == NULL) { > vm_exit_during_initialization("Unable to load zip library", path); > } > > You cannot make any progress on the failure. Thanks for the explanation, @yminqi. Change looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From aturbanov at openjdk.java.net Wed Jan 26 06:55:37 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 26 Jan 2022 06:55:37 GMT Subject: Integrated: 8280531: Remove unused DeferredCloseInputStream In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 20:51:06 GMT, Andrey Turbanov wrote: > Class DeferredCloseInputStream is unused since removing of Solaris support > https://github.com/openjdk/jdk/blob/9fe4b69c1a1120e1d761730495c3cfac8f179d13/src/java.base/unix/classes/java/lang/ProcessImpl.java#L80-L81 This pull request has now been integrated. Changeset: e72eefd9 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/e72eefd9f66e63a1e11d582e4916374840111928 Stats: 106 lines in 1 file changed: 0 ins; 104 del; 2 mod 8280531: Remove unused DeferredCloseInputStream Reviewed-by: bpb, rriggs, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7135 From mbaesken at openjdk.java.net Wed Jan 26 08:45:35 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 26 Jan 2022 08:45:35 GMT Subject: Integrated: JDK-8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 10:55:59 GMT, Matthias Baesken wrote: > After 8270492 > https://github.com/openjdk/jdk/commit/78b2c8419bc69436873e6fc9c542480949d140c5 > has been pushed, we should adjust src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java getAbsoluteURI to what has been done in 8270492 to src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java This pull request has now been integrated. Changeset: c180070c Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/c180070cb59b8e075376ae913c5db9a4ed868303 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod 8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 Reviewed-by: yan, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/7155 From alanb at openjdk.java.net Wed Jan 26 09:02:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 Jan 2022 09:02:34 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin I think this looks okay but I think @JimLaskey and/or @sundararajana should look at this because it creates a dependency on a JVM_* function. I'm trying to think if there are any interop issues when using jrtfs. Jim/Sundar can correct me but I think we are okay there because a tool on say JDK 8 (or 11 or 17) that accesses a JDK 19 run-time image will use the BasicImageReader and won't use libjimage in the target VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From azeller at openjdk.java.net Wed Jan 26 09:20:33 2022 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 26 Jan 2022 09:20:33 GMT Subject: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 12:02:10 GMT, Andrey Turbanov wrote: >> Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: >> >> ----------System.out:(12/489)---------- >> --- Testing df >> C:/Programs/cygwin64 292848636 49695320 243153316 17% / >> D: 59672 59672 0 100% /cygdrive/d >> >> >> SecurityManager = null >> C:/Programs/cygwin64: >> df total= 299877003264 free = 0 usable = 248988995584 >> getX total= 299877003264 free = 248988995584 usable = 248988995584 >> :: >> df total= 61104128 free = 0 usable = 0 >> getX total= 0 free = 0 usable = 0 >> ----------System.err:(23/1617)---------- >> java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) >> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) >> at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) >> at java.base/java.io.File.toPath(File.java:2396) >> at GetXSpace.compare(GetXSpace.java:223) >> at GetXSpace.testDF(GetXSpace.java:403) >> at GetXSpace.main(GetXSpace.java:437) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:833) >> >> Parsing of df output is incorrect. It skips first symbols after matching of line. >> https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L160 >> >> It means that after matching first line: >> >> C:/Programs/cygwin64 292848636 49695320 243153316 17% / >> >> >> It skips first symbols of next line - symbol `D` and then proceeds to match _corrupted_ line: >> >> : 59672 59672 0 100% /cygdrive/d >> >> >> Problems affects only Windows, because only in Windows case first group of matcher is used: >> >> https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L155-L156 >> >> >> Testing: >> * Windows x64 - always failed before. No errors after fix >> * Linux x64 > > @ArnoZeller can you please check if proposed changes fix the test in your environment? > @bplb can you please have a look at this pr? @turbanoff I put your change in our nightly test queue. I will check tomorrow for the results. ------------- PR: https://git.openjdk.java.net/jdk/pull/7170 From jlaskey at openjdk.java.net Wed Jan 26 13:42:30 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 26 Jan 2022 13:42:30 GMT Subject: RFR: JDK-8280550: SplittableRandom#nextDouble(double, double) can return result >= bound In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 02:12:11 GMT, Joe Darcy wrote: > Use floating-point library methods to nudge down the result if needed. The nextAfter(r, origin) call return the next value in the direction of origin, handling cases for negative values, etc. > > Changing to call nextDown for the origin is bounded at zero is just a refactoring that is clearer to read IMO. > > The regression test fails on an unpatched JDK. LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7221 From jwilhelm at openjdk.java.net Wed Jan 26 15:07:38 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 26 Jan 2022 15:07:38 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge remote-tracking branch 'jdk18/master' into Merge_jdk18 - 8280592: Small javadoc tweaks to foreign API The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/7232/files Stats: 91 lines in 12 files changed: 0 ins; 42 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/7232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7232/head:pull/7232 PR: https://git.openjdk.java.net/jdk/pull/7232 From michaelm at openjdk.java.net Wed Jan 26 15:41:22 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 26 Jan 2022 15:41:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v9] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Added unit test and comment update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/004466ea..e5a5a79a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=07-08 Stats: 312 lines in 2 files changed: 311 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From rriggs at openjdk.java.net Wed Jan 26 15:53:35 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 Jan 2022 15:53:35 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random In-Reply-To: References: Message-ID: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> On Sat, 8 Jan 2022 21:00:37 GMT, Yasser Bazzi wrote: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 src/java.base/share/classes/java/util/random/RandomGenerator.java line 144: > 142: /** > 143: * Returns a wrapper to use {@link java.util.Random} > 144: * @return {@link java.util.Random} Possible reword: "Returns a Random from this RandomGenerator." It should be specified that the resulting Random acts in all respects except that setSeed is not available. Missing period at the end of the sentence. Check all comments for grammar and punctuation. src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 41: > 39: @SuppressWarnings("serial") > 40: public class RandomWrapper extends Random implements RandomGenerator { > 41: private final RandomGenerator randomToWrap; Does this class need to be public? It acts as Random in almost all respects. src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 58: > 56: * setSeed does not exist in {@link java.util.random.RandomGenerator} so can't > 57: * use it > 58: */ Its debatable whether setSeed can ignore the argument or should throw an exception. If it ignores the argument, it is explicitly violating the contract of the supertype Random.setSeed that says the seed is set. I'd recommend throwing an UnsupportedOperationException because setSeed will not work as expected. Other classes (ThreadLocalRandom) throws UnsupportedOperationException from setSeed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From michaelm at openjdk.java.net Wed Jan 26 16:02:09 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 26 Jan 2022 16:02:09 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: removed ^M from test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/e5a5a79a..b44184de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=08-09 Stats: 311 lines in 1 file changed: 0 ins; 0 del; 311 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Wed Jan 26 16:32:38 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 Jan 2022 16:32:38 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 16:02:09 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > removed ^M from test Looks mostly good. Some doubts about catching just any exception indiscriminately though. test/jdk/sun/security/krb5/auto/HttpsCB.java line 120: > 118: > 119: boolean expected1 = Boolean.parseBoolean(args[0]); > 120: boolean expected2 = Boolean.parseBoolean(args[1]); It might be better for future maintainers and readability if these two variables could have better names, and possibly a comment to explain their purpose. AFAIU it's the expected result of running with/without CBT - where `true` means that the operation should succeed and `false` that it's expected to fail with some exception... test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: > 199: return reader.readLine().equals(CONTENT); > 200: } catch (Exception e) { > 201: return false; Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting? ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From psandoz at openjdk.java.net Wed Jan 26 16:41:33 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 26 Jan 2022 16:41:33 GMT Subject: RFR: JDK-8280550: SplittableRandom#nextDouble(double, double) can return result >= bound In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 02:12:11 GMT, Joe Darcy wrote: > Use floating-point library methods to nudge down the result if needed. The nextAfter(r, origin) call return the next value in the direction of origin, handling cases for negative values, etc. > > Changing to call nextDown for the origin is bounded at zero is just a refactoring that is clearer to read IMO. > > The regression test fails on an unpatched JDK. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7221 From duke at openjdk.java.net Wed Jan 26 17:08:36 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Wed, 26 Jan 2022 17:08:36 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random In-Reply-To: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> References: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> Message-ID: On Wed, 26 Jan 2022 15:36:28 GMT, Roger Riggs wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > src/java.base/share/classes/java/util/random/RandomGenerator.java line 144: > >> 142: /** >> 143: * Returns a wrapper to use {@link java.util.Random} >> 144: * @return {@link java.util.Random} > > Possible reword: > "Returns a Random from this RandomGenerator." > > It should be specified that the resulting Random acts in all respects except that > setSeed is not available. > > Missing period at the end of the sentence. Check all comments for grammar and punctuation. Is something like this better? /** * Returns a {@link java.util.Random} from this {@link java.util.RandomGenerator}. * The resulting Random acts in all respects except that setSeed is not available. * * @return {@link java.util.Random} */ > src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 41: > >> 39: @SuppressWarnings("serial") >> 40: public class RandomWrapper extends Random implements RandomGenerator { >> 41: private final RandomGenerator randomToWrap; > > Does this class need to be public? It acts as Random in almost all respects. Since it is in jdk.internal it needs to be public to use it in RandomGenerator interface, unless i move it to java.util > src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 58: > >> 56: * setSeed does not exist in {@link java.util.random.RandomGenerator} so can't >> 57: * use it >> 58: */ > > Its debatable whether setSeed can ignore the argument or should throw an exception. > If it ignores the argument, it is explicitly violating the contract of the supertype Random.setSeed > that says the seed is set. > I'd recommend throwing an UnsupportedOperationException because setSeed will not work as expected. > Other classes (ThreadLocalRandom) throws UnsupportedOperationException from setSeed. throwing UnsupportedOperationException was my first thought but when i call asRandom() it will always throw it, i could create something like what ThreadLocalRandom does (check if it initialized and throw) ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From rriggs at openjdk.java.net Wed Jan 26 17:16:35 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 Jan 2022 17:16:35 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random In-Reply-To: References: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> Message-ID: On Wed, 26 Jan 2022 17:05:33 GMT, Yasser Bazzi wrote: >> src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 41: >> >>> 39: @SuppressWarnings("serial") >>> 40: public class RandomWrapper extends Random implements RandomGenerator { >>> 41: private final RandomGenerator randomToWrap; >> >> Does this class need to be public? It acts as Random in almost all respects. > > Since it is in jdk.internal it needs to be public to use it in RandomGenerator interface, unless i move it to java.util Right, I missed it was in jdk.internal. public is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From jwilhelm at openjdk.java.net Wed Jan 26 17:27:40 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 26 Jan 2022 17:27:40 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 14:58:43 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: a5a11f14 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/a5a11f14b9ccc8c25f8a4232e9de23f47fbfb400 Stats: 91 lines in 12 files changed: 0 ins; 42 del; 49 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7232 From darcy at openjdk.java.net Wed Jan 26 17:29:42 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 26 Jan 2022 17:29:42 GMT Subject: Integrated: JDK-8280550: SplittableRandom#nextDouble(double,double) can return result >= bound In-Reply-To: References: Message-ID: <_sDXPXw4y8pWNdRbQWpSLX1WdDjSSIToupreUSH8yJk=.cf9af12b-7a78-4f6d-b59b-e3475dee273a@github.com> On Wed, 26 Jan 2022 02:12:11 GMT, Joe Darcy wrote: > Use floating-point library methods to nudge down the result if needed. The nextAfter(r, origin) call return the next value in the direction of origin, handling cases for negative values, etc. > > Changing to call nextDown for the origin is bounded at zero is just a refactoring that is clearer to read IMO. > > The regression test fails on an unpatched JDK. This pull request has now been integrated. Changeset: 0c42e43f Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/0c42e43f77b91a50fedc3fddb74e17f910d8df2a Stats: 54 lines in 2 files changed: 52 ins; 0 del; 2 mod 8280550: SplittableRandom#nextDouble(double,double) can return result >= bound Reviewed-by: jlaskey, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/7221 From smarks at openjdk.java.net Wed Jan 26 17:47:34 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 26 Jan 2022 17:47:34 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random In-Reply-To: References: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> Message-ID: On Wed, 26 Jan 2022 17:04:35 GMT, Yasser Bazzi wrote: >> src/java.base/share/classes/java/util/random/RandomGenerator.java line 144: >> >>> 142: /** >>> 143: * Returns a wrapper to use {@link java.util.Random} >>> 144: * @return {@link java.util.Random} >> >> Possible reword: >> "Returns a Random from this RandomGenerator." >> >> It should be specified that the resulting Random acts in all respects except that >> setSeed is not available. >> >> Missing period at the end of the sentence. Check all comments for grammar and punctuation. > > Is something like this better? > /** > * Returns a {@link java.util.Random} from this {@link java.util.RandomGenerator}. > * The resulting Random acts in all respects except that setSeed is not available. > * > * @return {@link java.util.Random} > */ Suggest: > Returns an instance of {@link java.util.Random} based on this {@code RandomGenerator}. > If this generator is already an instance of {@code Random}, it is returned. Otherwise, this method > returns an instance of {@code Random} that delegates all methods except `setSeed` to this > generator. Its `setSeed` method always throws {@link UnsupportedOperationException}. (Note no link is necessary for RandomGenerator since we are in that class already.) >> src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 58: >> >>> 56: * setSeed does not exist in {@link java.util.random.RandomGenerator} so can't >>> 57: * use it >>> 58: */ >> >> Its debatable whether setSeed can ignore the argument or should throw an exception. >> If it ignores the argument, it is explicitly violating the contract of the supertype Random.setSeed >> that says the seed is set. >> I'd recommend throwing an UnsupportedOperationException because setSeed will not work as expected. >> Other classes (ThreadLocalRandom) throws UnsupportedOperationException from setSeed. > > throwing UnsupportedOperationException was my first thought but when i call asRandom() it will always throw it, i could create something like what ThreadLocalRandom does (check if it initialized and throw) Yes, probably following ThreadLocalRandom is the right thing. Pretty clunky but I think it's necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From smarks at openjdk.java.net Wed Jan 26 17:47:35 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 26 Jan 2022 17:47:35 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random In-Reply-To: References: Message-ID: <-N5NGoW-J3L_xDXtqQRf1STWa9c_R7g4dFd2m3d0PmA=.692742c1-c3ff-4e68-b9de-d16a5323fa25@github.com> On Sat, 8 Jan 2022 21:00:37 GMT, Yasser Bazzi wrote: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 41: > 39: @SuppressWarnings("serial") > 40: public class RandomWrapper extends Random implements RandomGenerator { > 41: private final RandomGenerator randomToWrap; Suggest renaming the field to "generator" and replacing subsequent calls to `this.randomToWrap.foo()` with `generator.foo()`. src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 47: > 45: } > 46: > 47: public static Random wrapRandom(RandomGenerator random) { Probably better if the method is just `wrap` since the class name is descriptive enough already. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From smarks at openjdk.java.net Wed Jan 26 17:52:34 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 26 Jan 2022 17:52:34 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 21:00:37 GMT, Yasser Bazzi wrote: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 This will also need a regression test. It should have a case to ensure that `asRandom` returns `this` if it's already an instance of `Random`. Maybe also a simple case of shuffling a list, similar to the gist. Also see if there are some tests for Random already that this can be plugged into. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From minqi at openjdk.java.net Wed Jan 26 18:13:35 2022 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 26 Jan 2022 18:13:35 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin Update: tier1,tier4 passed tier7 failed on: test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java That is not related to the change since it is not using zip. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From weijun at openjdk.java.net Wed Jan 26 19:03:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 26 Jan 2022 19:03:40 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 16:27:29 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: > >> 199: return reader.readLine().equals(CONTENT); >> 200: } catch (Exception e) { >> 201: return false; > > Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting? It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From weijun at openjdk.java.net Wed Jan 26 19:08:38 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 26 Jan 2022 19:08:38 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 16:25:24 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 120: > >> 118: >> 119: boolean expected1 = Boolean.parseBoolean(args[0]); >> 120: boolean expected2 = Boolean.parseBoolean(args[1]); > > It might be better for future maintainers and readability if these two variables could have better names, and possibly a comment to explain their purpose. AFAIU it's the expected result of running with/without CBT - where `true` means that the operation should succeed and `false` that it's expected to fail with some exception... Maybe `expectedCbtUrlResult` and `expectedNormalUrlResult`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From alanb at openjdk.java.net Wed Jan 26 19:13:26 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 Jan 2022 19:13:26 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: References: Message-ID: <5_4g8M8TTU3-u2EAat39xKmvyIr8iBAJwNXjRh5aZAk=.504eae29-e9bd-4566-bdfb-312a03b11d37@github.com> On Thu, 13 Jan 2022 12:19:03 GMT, Roman Kennke wrote: >> Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete comment I think this looks okay. It's only used when running with a SecurityManager so unlikely to be used in most deployments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From rkennke at openjdk.java.net Wed Jan 26 19:54:36 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 26 Jan 2022 19:54:36 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: <5_4g8M8TTU3-u2EAat39xKmvyIr8iBAJwNXjRh5aZAk=.504eae29-e9bd-4566-bdfb-312a03b11d37@github.com> References: <5_4g8M8TTU3-u2EAat39xKmvyIr8iBAJwNXjRh5aZAk=.504eae29-e9bd-4566-bdfb-312a03b11d37@github.com> Message-ID: <9q2RaMXdNXMPkZZq0g3lCYoSEtwb2NcNtRXFjdLjN6Q=.e960fbc8-5fb2-4726-838a-a9a377f404ce@github.com> On Wed, 26 Jan 2022 19:09:58 GMT, Alan Bateman wrote: > I think this looks okay. It's only used when running with a SecurityManager so unlikely to be used in most deployments. Thanks, Alan! Could you also 'approve' this PR? Thanks, Roman ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From alanb at openjdk.java.net Wed Jan 26 20:07:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 Jan 2022 20:07:32 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 12:19:03 GMT, Roman Kennke wrote: >> Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete comment Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From serb at openjdk.java.net Wed Jan 26 20:30:31 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 26 Jan 2022 20:30:31 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote: > The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. > > Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). > > One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7237 From dcubed at openjdk.java.net Wed Jan 26 20:53:29 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 26 Jan 2022 20:53:29 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin Your Tier7 failure is likely this known bug: JDK-8280601 ClhsdbThreadContext.java test is triggering codecache related assert in PointerFinder.find() https://bugs.openjdk.java.net/browse/JDK-8280601 ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From darcy at openjdk.java.net Wed Jan 26 21:28:51 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 26 Jan 2022 21:28:51 GMT Subject: RFR: JDK-8280745: Allow SuppressWarnings to be used in package declarations Message-ID: The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8280745 While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. ------------- Commit messages: - JDK-8280745: Allow SuppressWarnings to be used in package declarations Changes: https://git.openjdk.java.net/jdk/pull/7239/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280745 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7239/head:pull/7239 PR: https://git.openjdk.java.net/jdk/pull/7239 From azeller at openjdk.java.net Thu Jan 27 07:29:35 2022 From: azeller at openjdk.java.net (Arno Zeller) Date: Thu, 27 Jan 2022 07:29:35 GMT Subject: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 12:02:10 GMT, Andrey Turbanov wrote: >> Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: >> >> ----------System.out:(12/489)---------- >> --- Testing df >> C:/Programs/cygwin64 292848636 49695320 243153316 17% / >> D: 59672 59672 0 100% /cygdrive/d >> >> >> SecurityManager = null >> C:/Programs/cygwin64: >> df total= 299877003264 free = 0 usable = 248988995584 >> getX total= 299877003264 free = 248988995584 usable = 248988995584 >> :: >> df total= 61104128 free = 0 usable = 0 >> getX total= 0 free = 0 usable = 0 >> ----------System.err:(23/1617)---------- >> java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) >> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) >> at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) >> at java.base/java.io.File.toPath(File.java:2396) >> at GetXSpace.compare(GetXSpace.java:223) >> at GetXSpace.testDF(GetXSpace.java:403) >> at GetXSpace.main(GetXSpace.java:437) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:833) >> >> Parsing of df output is incorrect. It skips first symbols after matching of line. >> https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L160 >> >> It means that after matching first line: >> >> C:/Programs/cygwin64 292848636 49695320 243153316 17% / >> >> >> It skips first symbols of next line - symbol `D` and then proceeds to match _corrupted_ line: >> >> : 59672 59672 0 100% /cygdrive/d >> >> >> Problems affects only Windows, because only in Windows case first group of matcher is used: >> >> https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L155-L156 >> >> >> Testing: >> * Windows x64 - always failed before. No errors after fix >> * Linux x64 > > @ArnoZeller can you please check if proposed changes fix the test in your environment? > @bplb can you please have a look at this pr? @turbanoff The results look good - the failure is fixed with your patch!. Thanks for taking care of the issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7170 From scolebourne at joda.org Thu Jan 27 09:00:23 2022 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 27 Jan 2022 09:00:23 +0000 Subject: Additional Date-Time Formats In-Reply-To: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> Message-ID: Hi, This would be a useful addition. Some comments: There is no need for the method overload that takes Locale. The other similar methods all operate using the locale of the formatter, and have this Javadoc: * The locale is determined from the formatter. The formatter returned directly by * this method will use the {@link Locale#getDefault() default FORMAT locale}. * The locale can be controlled using {@link DateTimeFormatter#withLocale(Locale) withLocale(Locale)} * on the result of this method. And `appendLocalizedPattern` should not take a Locale either. Again , it would use the locale of the formatter instance, calculating the actual pattern on-demand when the formatter is run. The spec Javadoc doesn't explain what repeating the pattern letter actually does/means. Is "M" the same as "MMMM"? thanks Stephen On Thu, 20 Jan 2022 at 21:47, Naoto Sato wrote: > > Hello, > > I am proposing a couple of new factory methods in > java.time.format.DateTimeFormatter that produce flexible localized > date/time formats, other than the existing pre-defined > (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year > and month only string, such as the title for the calendar, currently > they would have to use DateTimeFormatter.ofPattern() with explicit > pattern argument, such as "MMM y". This is problematic because it is > correct in locales such as US, but not correct in other locales. > > So, I propose methods that are parallel to ofPattern(), which take > pattern template. This is based on the CLDR's skeleton: > https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems > > Detailed design can be found in the draft CSR: > https://bugs.openjdk.java.net/browse/JDK-8243445 > > Comments are welcome. > > Naoto > From duke at openjdk.java.net Thu Jan 27 09:07:40 2022 From: duke at openjdk.java.net (duke) Date: Thu, 27 Jan 2022 09:07:40 GMT Subject: Withdrawn: JDK-8277375: jdeps errors on a class path with a file path with no permission In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 01:12:01 GMT, Mandy Chung wrote: > This changes jdeps -cp to ignore files/directories with no permission to access. This is consistent with the runtime behavior. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6531 From michaelm at openjdk.java.net Thu Jan 27 15:54:15 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 27 Jan 2022 15:54:15 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v11] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: test update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/b44184de..d604ee7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=09-10 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From mandy.chung at oracle.com Thu Jan 27 16:45:59 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Jan 2022 08:45:59 -0800 Subject: Fix proposal for bug JDK-8221642 In-Reply-To: References: Message-ID: <0ab483b9-05ea-6ca3-668c-4bae665190cc@oracle.com> Hi Andreas, What methods are you calling that throws NPE?? Do you have the stack trace to share? The spec of AccessibleObject was updated for JDK-8221530 if there is no caller frame when calling from JNI: "The check when invoked by JNI code with no Java class on the stack only succeeds if the member and the declaring class are public, and the class is in a package that is exported to all modules." I think AccessibleObject::canAccess, setAccessible, trySetAccessible should follow the same rule. Mandy On 1/27/22 2:19 AM, Andreas Rosenberg wrote: > Hi, > > this is my first posting regarding to JDK contribution, so this may be the wrong place to ask. > Please point me in the right direction in this case. > > We are using Java rather heavily via JNI on a custom application. For a long time we did stick to JRE 1.8 > for various reasons. My task is to plan an upgrade to a more recent JDK version and while doing some > test I encountered bugs related to this: JDK-8227491 (JNI - caller sensitive methods). > > We are parsing Java class files to auto gen the JNI code for our application, and are also using reflection. > The workaround given is clumsy and needs manual intervention, so I was looking for a more elegant solution. > > The problem is: a caller sensitive method wants to determine the caller class for security checks. In case of > a JNI call no Java stack frame exists, so the JVM function "jclass JVM_GetCallerClass(JNIEnv* env)" answers NULL > which leads to NPEs. > > My idea is this: create an internal proxy class inside "java.base" that reflects this case > (e.g. "java.lang.NativeCall" or "java.lang.NativeCode"). > This class is final and implements nothing. > > Then "jclass JVM_GetCallerClass(JNIEnv* env)" (jvm.cpp) could be modified and instead of answering NULL > in case of a JNI call, it should do this to answer the class proxy: > > return JVM_FindClassFromBootLoader(env, "java/lang/NativeCall"); > > This would have the following advantages: > - JNI code could again simply call "caller sensitive methods" without the need to make an additional wrapper class > - it would be more a expressive way on the Java side to detect "the callee is native code" than checking for null > - it would fit better into the framework > > I already applied this fix on my own copy of the JDK 17 sources and it works pretty well for us. > > As there are probably security considerations involved, advice from experts is required. > But from my understanding the Java security model is designed for the main app being writing in Java. > In this case there are always Java stacks frames available as parents for caller sensitive methods, so > the proposed fix would not affect the behavior. This assumes that "GetCallerClass" only answers > NULL for the JNI case. This needs verification. > > If the main app is native code which uses JNI, the Java security model can only affect the Java part and > as soon as an additional Java stack frame has been generated a regular Java class will be found and > the "standard behavior" should apply again. > > Comments appreciated. > > It this fix looks reasonable, what are the steps to get it implemented and integrated into the official > source tree? > > Best regards, > Andy > > From dfuchs at openjdk.java.net Thu Jan 27 16:50:49 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 Jan 2022 16:50:49 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Wed, 26 Jan 2022 19:00:14 GMT, Weijun Wang wrote: >> test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: >> >>> 199: return reader.readLine().equals(CONTENT); >>> 200: } catch (Exception e) { >>> 201: return false; >> >> Should we log that we have received the excepted exception here? Shouldn't the catch clause only list the exceptions that we are expecting? > > It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing. Thanks. Then it would be better to catch only `SocketException` here rather than `Exception`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Thu Jan 27 18:05:25 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 27 Jan 2022 18:05:25 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v12] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - test update - Merge branch 'master' into spnego - test update - removed ^M from test - Added unit test and comment update - final review update (pre CSR) - more updates - fixed failing test issue and update for latest comments - Merge branch 'master' into spnego - added root cause to NamingException - ... and 5 more: https://git.openjdk.java.net/jdk/compare/35ce454c...59f703da ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/d604ee7f..59f703da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=10-11 Stats: 4735 lines in 368 files changed: 2835 ins; 809 del; 1091 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Thu Jan 27 18:05:27 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 27 Jan 2022 18:05:27 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10] In-Reply-To: References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <64ecMlTGcFJvgXe-Wo_R7F_3yrxSom_mb549yKt0MGo=.9b40e87d-59be-4a63-8b05-947afa00f475@github.com> On Thu, 27 Jan 2022 16:47:52 GMT, Daniel Fuchs wrote: >> It's `java.net.SocketException: Unexpected end of file from server`. Does not include any CBT words so don't know if it's worth parsing. > > Thanks. Then it would be better to catch only `SocketException` here rather than `Exception`. I'll make it catch `IOException` ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Thu Jan 27 18:12:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 27 Jan 2022 18:12:47 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v12] In-Reply-To: <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <-WRoAT5DuS4OJEyvMkWuHEWewa51O_mGwk7KxsYP3uw=.8228878d-4ad8-4519-827f-a0d81e6bb662@github.com> Message-ID: On Thu, 27 Jan 2022 18:05:25 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: > > - test update > - Merge branch 'master' into spnego > - test update > - removed ^M from test > - Added unit test and comment update > - final review update (pre CSR) > - more updates > - fixed failing test issue and update for latest comments > - Merge branch 'master' into spnego > - added root cause to NamingException > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/ceb44101...59f703da LGTM! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7065 From ts.stadler at gmx.de Thu Jan 27 18:41:42 2022 From: ts.stadler at gmx.de (Tobias Stadler) Date: Thu, 27 Jan 2022 19:41:42 +0100 Subject: JarIndex not following the specification Message-ID: ?Hello everyone, According to https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html, sections in META-INF/INDEX.LIST are divided by blank lines. The write method of jdk.internal.util.jar.JarIndex does write those blank lines. But the read method begins a new section whenever it sees a line that ends with .jar. Does anybody know why JarIndex#read does not follow the specification? Is this a bug? E.g. some.jar META-INF META-INF/another.jar org Will be be read as two sections instead of just one. Also the package org will be mapped to META-INF/another.jar instead of some.jar. Best reagrds Tobias From daniel.fuchs at oracle.com Thu Jan 27 18:54:03 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 27 Jan 2022 18:54:03 +0000 Subject: JarIndex not following the specification In-Reply-To: References: Message-ID: Hi Tobias, Regardless of whether this is a bug or not, JarIndex has been disabled by default in JDK 18, in the hope to eventually remove it in the future. See https://bugs.openjdk.java.net/browse/JDK-8273473 best regards, -- daniel On 27/01/2022 18:41, Tobias Stadler wrote: > Hello everyone, > > According to https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html, sections in META-INF/INDEX.LIST are divided by blank lines. > > The write method of jdk.internal.util.jar.JarIndex does write those blank lines. But the read method begins a new section whenever it sees a line that ends with .jar. Does anybody know why JarIndex#read does not follow the specification? Is this a bug? > > E.g. > > some.jar > META-INF > META-INF/another.jar > org > > Will be be read as two sections instead of just one. Also the package org will be mapped to META-INF/another.jar instead of some.jar. > > Best reagrds > Tobias > From darcy at openjdk.java.net Thu Jan 27 18:54:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 27 Jan 2022 18:54:06 GMT Subject: RFR: JDK-8280745: Allow SuppressWarnings to be used in package declarations [v2] In-Reply-To: References: Message-ID: <6fV4kvFSY_scXnZ1vH_LwrYOlG2PjthT2016X_D8Wik=.2aa7a86e-3c2e-414a-ba8b-555d97bd0a93@github.com> > The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8280745 > > While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7239/files - new: https://git.openjdk.java.net/jdk/pull/7239/files/317e6a5c..653a14ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=00-01 Stats: 33 lines in 1 file changed: 26 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7239/head:pull/7239 PR: https://git.openjdk.java.net/jdk/pull/7239 From darcy at openjdk.java.net Thu Jan 27 18:58:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 27 Jan 2022 18:58:44 GMT Subject: RFR: JDK-8280745: Allow SuppressWarnings to be used in package declarations [v2] In-Reply-To: <6fV4kvFSY_scXnZ1vH_LwrYOlG2PjthT2016X_D8Wik=.2aa7a86e-3c2e-414a-ba8b-555d97bd0a93@github.com> References: <6fV4kvFSY_scXnZ1vH_LwrYOlG2PjthT2016X_D8Wik=.2aa7a86e-3c2e-414a-ba8b-555d97bd0a93@github.com> Message-ID: On Thu, 27 Jan 2022 18:54:06 GMT, Joe Darcy wrote: >> The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). >> >> Please also review the companion CSR: >> https://bugs.openjdk.java.net/browse/JDK-8280745 >> >> While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Furthering on a suggestion from Alex in the CSR review, I've reworked the change to remove the @Target meta-annotation from SuppressWarnings, which allows SuppressWarnings to be used in any declaration context. I've also synced the list of strings required to be recognized for suppressed warnings from JLS 9.6.4.5 @SuppressWarnings; the phrasing is such that any additions from JLS 9.6.4.5 will be implicitly included even if the javadoc is not updated. If, say, the jdk.compiler module listed the strings javac accepted for suppressed warnings, I'd like to that from the implNote, but until such a list is added, I just gave instructions from how to get a list. ------------- PR: https://git.openjdk.java.net/jdk/pull/7239 From naoto.sato at oracle.com Thu Jan 27 19:22:38 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 27 Jan 2022 11:22:38 -0800 Subject: Additional Date-Time Formats In-Reply-To: References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> Message-ID: <00218c0e-31ea-d8ea-efe3-6920c42ea0a1@oracle.com> Hi Stephen, On 1/27/22 1:00 AM, Stephen Colebourne wrote: > Hi, > This would be a useful addition. Some comments: > > There is no need for the method overload that takes Locale. The other > similar methods all operate using the locale of the formatter, and > have this Javadoc: > > * The locale is determined from the formatter. The formatter > returned directly by > * this method will use the {@link Locale#getDefault() default > FORMAT locale}. > * The locale can be controlled using {@link > DateTimeFormatter#withLocale(Locale) withLocale(Locale)} > * on the result of this method. > > And `appendLocalizedPattern` should not take a Locale either. Again , > it would use the locale of the formatter instance, calculating the > actual pattern on-demand when the formatter is run. That makes sense. Will revise the spec. Now come to think of it, I came up with the draft based on `ofPattern()` methods. One of them is a overload method that takes a Locale argument. Why is it so? > > The spec Javadoc doesn't explain what repeating the pattern letter > actually does/means. Is "M" the same as "MMMM"? That depends on the locale and the availability of the formats. For example, 'M' translates into these patterns in each locale with Gregorian calendar: https://unicode-org.github.io/cldr-staging/charts/40/by_type/date_&_time.gregorian.html#959cbb42bb2962f Naoto From robm at openjdk.java.net Thu Jan 27 20:37:55 2022 From: robm at openjdk.java.net (Rob McKenna) Date: Thu, 27 Jan 2022 20:37:55 GMT Subject: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3] In-Reply-To: References: <95CuJQqoVfJOEdYeRhgTJbLqdQwyyGvBlDR2WoyIsfg=.2230a07d-ad5f-457f-ac33-283e732cda25@github.com> Message-ID: On Tue, 25 Jan 2022 15:30:46 GMT, Mark Sheppard wrote: >> yes a redeclaration of timeout with a type long across the component would be a consistent approach, also > > so just to clarify, we're not taking the approach to homogenise the timeout declarations, throughout the component, to be of type long? > > which would see LdapClientFactory constructor take a long timeout and timeout member varaiables be redefined as long Not in this issue. I plan to file a follow up bug to make a slight change to the test. I would like to get this issue fixed ASAP and would appreciate the time to take a good look at the transition to a long timeout. (i.e. I'll handle it in that follow up issue) ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From darcy at openjdk.java.net Thu Jan 27 21:32:36 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 27 Jan 2022 21:32:36 GMT Subject: RFR: JDK-8280745: Allow SuppressWarnings to be used in package declarations [v3] In-Reply-To: References: Message-ID: > The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8280745 > > While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to CSR feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7239/files - new: https://git.openjdk.java.net/jdk/pull/7239/files/653a14ae..2339a085 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=01-02 Stats: 27 lines in 1 file changed: 9 ins; 8 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7239/head:pull/7239 PR: https://git.openjdk.java.net/jdk/pull/7239 From scolebourne at joda.org Thu Jan 27 22:34:08 2022 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 27 Jan 2022 22:34:08 +0000 Subject: Additional Date-Time Formats In-Reply-To: <00218c0e-31ea-d8ea-efe3-6920c42ea0a1@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <00218c0e-31ea-d8ea-efe3-6920c42ea0a1@oracle.com> Message-ID: On Thu, 27 Jan 2022 at 19:23, Naoto Sato wrote: > Now come to think of it, I came up with the draft based on `ofPattern()` > methods. One of them is a overload method that takes a Locale argument. > Why is it so? There is a case for the Locale on the static method (as a convenience, and to remind callers that the locale matters). But there is no case for it on the builder. > > The spec Javadoc doesn't explain what repeating the pattern letter > > actually does/means. Is "M" the same as "MMMM"? > > That depends on the locale and the availability of the formats. For > example, 'M' translates into these patterns in each locale with > Gregorian calendar: > > https://unicode-org.github.io/cldr-staging/charts/40/by_type/date_&_time.gregorian.html#959cbb42bb2962f As things stand, the Javadoc isn't a standalone spec. I don't know how much that matters, but I think there should be some indication in Javadoc as to why the letter should be repeated. Stephen From bpb at openjdk.java.net Thu Jan 27 22:43:14 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 27 Jan 2022 22:43:14 GMT Subject: RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly [v2] In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 00:20:07 GMT, Joe Darcy wrote: >> Update the java.lang.{Math, StrictMath} regression test helper library to accept method references. This allows the test programs to be DRY-er as the inputs to the method under test don't have to be repeated. The float test method were not updated due to limitations in type inference if both float and double methods with functional interface parameters are present. >> >> Also did some general tidying up for the test code. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Use consistent syntax for main method. > - Merge branch 'master' into JDK-8270476 > - Appease jcheck. > - Further refactoring. > - Update copyright year, remove author tags. > - JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly test/jdk/java/lang/Math/CubeRootTests.java line 48: > 46: int failures=0; > 47: > 48: double minus_input = -input; Unused variable? test/jdk/java/lang/StrictMath/Tests.java line 24: > 22: */ > 23: > 24: import java.util.function.*; Maybe list each interface separately instead of using "*"? ------------- PR: https://git.openjdk.java.net/jdk/pull/7216 From bpb at openjdk.java.net Thu Jan 27 22:53:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 27 Jan 2022 22:53:11 GMT Subject: RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly [v2] In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 00:20:07 GMT, Joe Darcy wrote: >> Update the java.lang.{Math, StrictMath} regression test helper library to accept method references. This allows the test programs to be DRY-er as the inputs to the method under test don't have to be repeated. The float test method were not updated due to limitations in type inference if both float and double methods with functional interface parameters are present. >> >> Also did some general tidying up for the test code. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Use consistent syntax for main method. > - Merge branch 'master' into JDK-8270476 > - Appease jcheck. > - Further refactoring. > - Update copyright year, remove author tags. > - JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly test/jdk/java/lang/Math/Tests.java line 24: > 22: */ > 23: > 24: import java.util.function.*; List all interfaces instead of "*"? ------------- PR: https://git.openjdk.java.net/jdk/pull/7216 From darcy at openjdk.java.net Thu Jan 27 23:01:51 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 27 Jan 2022 23:01:51 GMT Subject: RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly [v3] In-Reply-To: References: Message-ID: > Update the java.lang.{Math, StrictMath} regression test helper library to accept method references. This allows the test programs to be DRY-er as the inputs to the method under test don't have to be repeated. The float test method were not updated due to limitations in type inference if both float and double methods with functional interface parameters are present. > > Also did some general tidying up for the test code. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7216/files - new: https://git.openjdk.java.net/jdk/pull/7216/files/789782ce..30987b71 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7216&range=01-02 Stats: 7 lines in 3 files changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7216.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7216/head:pull/7216 PR: https://git.openjdk.java.net/jdk/pull/7216 From bpb at openjdk.java.net Thu Jan 27 23:01:54 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 27 Jan 2022 23:01:54 GMT Subject: RFR: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly [v2] In-Reply-To: References: Message-ID: <7BpnGaF91Rf7lAzuYDyoQDW5uKgGXFW8ErQo0VKIrck=.3a3fae1e-168d-4939-99e1-9d7e5cd6a3bd@github.com> On Wed, 26 Jan 2022 00:20:07 GMT, Joe Darcy wrote: >> Update the java.lang.{Math, StrictMath} regression test helper library to accept method references. This allows the test programs to be DRY-er as the inputs to the method under test don't have to be repeated. The float test method were not updated due to limitations in type inference if both float and double methods with functional interface parameters are present. >> >> Also did some general tidying up for the test code. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Use consistent syntax for main method. > - Merge branch 'master' into JDK-8270476 > - Appease jcheck. > - Further refactoring. > - Update copyright year, remove author tags. > - JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly Approved. Minor changes noted may be at integration. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7216 From darcy at openjdk.java.net Thu Jan 27 23:01:55 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 27 Jan 2022 23:01:55 GMT Subject: Integrated: JDK-8270476: Make floating-point test infrastructure more lambda and method reference friendly In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 21:40:15 GMT, Joe Darcy wrote: > Update the java.lang.{Math, StrictMath} regression test helper library to accept method references. This allows the test programs to be DRY-er as the inputs to the method under test don't have to be repeated. The float test method were not updated due to limitations in type inference if both float and double methods with functional interface parameters are present. > > Also did some general tidying up for the test code. This pull request has now been integrated. Changeset: 40a2ce20 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/40a2ce20334207b542d18f52e26bf418bf29c9ca Stats: 467 lines in 27 files changed: 121 ins; 147 del; 199 mod 8270476: Make floating-point test infrastructure more lambda and method reference friendly Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7216 From darcy at openjdk.java.net Thu Jan 27 23:27:54 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 27 Jan 2022 23:27:54 GMT Subject: RFR: JDK-8280744: Allow SuppressWarnings to be used in package declarations [v4] In-Reply-To: References: Message-ID: <6gUhlcm4iom2g4C9XN-8iD4v8krVQHbw792k-xqXHBY=.fea56d34-4aef-4d8e-b3f9-a52381db3f52@github.com> > The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8280745 > > While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Respond to review feedback. - Merge branch 'master' into JDK-8280744 - Respond to CSR feedback. - Respond to review feedback. - JDK-8280745: Allow SuppressWarnings to be used in package declarations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7239/files - new: https://git.openjdk.java.net/jdk/pull/7239/files/2339a085..7b04321c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=02-03 Stats: 2656 lines in 124 files changed: 1495 ins; 647 del; 514 mod Patch: https://git.openjdk.java.net/jdk/pull/7239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7239/head:pull/7239 PR: https://git.openjdk.java.net/jdk/pull/7239 From iris at openjdk.java.net Fri Jan 28 00:03:12 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 28 Jan 2022 00:03:12 GMT Subject: RFR: JDK-8280744: Allow SuppressWarnings to be used in package declarations [v4] In-Reply-To: <6gUhlcm4iom2g4C9XN-8iD4v8krVQHbw792k-xqXHBY=.fea56d34-4aef-4d8e-b3f9-a52381db3f52@github.com> References: <6gUhlcm4iom2g4C9XN-8iD4v8krVQHbw792k-xqXHBY=.fea56d34-4aef-4d8e-b3f9-a52381db3f52@github.com> Message-ID: On Thu, 27 Jan 2022 23:27:54 GMT, Joe Darcy wrote: >> The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). >> >> Please also review the companion CSR: >> https://bugs.openjdk.java.net/browse/JDK-8280745 >> >> While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8280744 > - Respond to CSR feedback. > - Respond to review feedback. > - JDK-8280745: Allow SuppressWarnings to be used in package declarations The current spec changes correspond to the approved CSR. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7239 From naoto at openjdk.java.net Fri Jan 28 00:08:21 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 28 Jan 2022 00:08:21 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking In-Reply-To: References: Message-ID: <1cfRNjI3cmzGOT_gioY8Gx0tFcPsFBEsxz5PClEVY7s=.e5c3c6fb-2602-4652-ada1-33577e60c139@github.com> On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote: > The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. > > Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). > > One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. Looks fine. Nit: some files need copyright year updates. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7237 From darcy at openjdk.java.net Fri Jan 28 00:30:32 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 28 Jan 2022 00:30:32 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking In-Reply-To: <1cfRNjI3cmzGOT_gioY8Gx0tFcPsFBEsxz5PClEVY7s=.e5c3c6fb-2602-4652-ada1-33577e60c139@github.com> References: <1cfRNjI3cmzGOT_gioY8Gx0tFcPsFBEsxz5PClEVY7s=.e5c3c6fb-2602-4652-ada1-33577e60c139@github.com> Message-ID: On Fri, 28 Jan 2022 00:04:34 GMT, Naoto Sato wrote: > Looks fine. Nit: some files need copyright year updates. Acknowledged; I'll run a copyright update script before pushing (I tend to run that close to pushing to avoid spurious, if minor, merge conflicts). Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7237 From darcy at openjdk.java.net Fri Jan 28 00:35:53 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 28 Jan 2022 00:35:53 GMT Subject: RFR: JDK-8280744: Allow SuppressWarnings to be used in package declarations [v5] In-Reply-To: References: Message-ID: > The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8280745 > > While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Reflow updated paragraphs. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7239/files - new: https://git.openjdk.java.net/jdk/pull/7239/files/7b04321c..d912b928 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7239&range=03-04 Stats: 24 lines in 1 file changed: 2 ins; 1 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/7239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7239/head:pull/7239 PR: https://git.openjdk.java.net/jdk/pull/7239 From duke at openjdk.java.net Fri Jan 28 00:36:01 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 28 Jan 2022 00:36:01 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with four additional commits since the last revision: - make sure setseed its initialized and throw - remove tabs - Change name of function from wrapRandom to wrap - Change variable name and wording in javadocs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/fbdf4969..c297d42f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=00-01 Stats: 51 lines in 2 files changed: 18 ins; 0 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Jan 28 00:42:09 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 28 Jan 2022 00:42:09 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: References: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> Message-ID: On Wed, 26 Jan 2022 17:43:09 GMT, Stuart Marks wrote: >> Is something like this better? >> /** >> * Returns a {@link java.util.Random} from this {@link java.util.RandomGenerator}. >> * The resulting Random acts in all respects except that setSeed is not available. >> * >> * @return {@link java.util.Random} >> */ > > Suggest: > >> Returns an instance of {@link java.util.Random} based on this {@code RandomGenerator}. >> If this generator is already an instance of {@code Random}, it is returned. Otherwise, this method >> returns an instance of {@code Random} that delegates all methods except `setSeed` to this >> generator. Its `setSeed` method always throws {@link UnsupportedOperationException}. > > (Note no link is necessary for RandomGenerator since we are in that class already.) Commited the change on df78e05e3e692e2189c9d318fbd4892a4b96a55f >> throwing UnsupportedOperationException was my first thought but when i call asRandom() it will always throw it, i could create something like what ThreadLocalRandom does (check if it initialized and throw) > > Yes, probably following ThreadLocalRandom is the right thing. Pretty clunky but I think it's necessary. ok so i made the change to check if its initialized and throw if the user tries to use setSeet() c297d42f4505b03780bd9ab2e169546fd6cffcb9 ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Jan 28 00:42:10 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 28 Jan 2022 00:42:10 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: <-N5NGoW-J3L_xDXtqQRf1STWa9c_R7g4dFd2m3d0PmA=.692742c1-c3ff-4e68-b9de-d16a5323fa25@github.com> References: <-N5NGoW-J3L_xDXtqQRf1STWa9c_R7g4dFd2m3d0PmA=.692742c1-c3ff-4e68-b9de-d16a5323fa25@github.com> Message-ID: On Wed, 26 Jan 2022 17:31:27 GMT, Stuart Marks wrote: >> Yasser Bazzi has updated the pull request incrementally with four additional commits since the last revision: >> >> - make sure setseed its initialized and throw >> - remove tabs >> - Change name of function from wrapRandom to wrap >> - Change variable name and wording in javadocs > > src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 41: > >> 39: @SuppressWarnings("serial") >> 40: public class RandomWrapper extends Random implements RandomGenerator { >> 41: private final RandomGenerator randomToWrap; > > Suggest renaming the field to "generator" and replacing subsequent calls to `this.randomToWrap.foo()` with `generator.foo()`. Changed to generator on this commit df78e05e3e692e2189c9d318fbd4892a4b96a55f > src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 47: > >> 45: } >> 46: >> 47: public static Random wrapRandom(RandomGenerator random) { > > Probably better if the method is just `wrap` since the class name is descriptive enough already. Commited this change on aadef6f465c0b776f4b8025e2655110b424c6801 ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From darcy at openjdk.java.net Fri Jan 28 00:48:13 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 28 Jan 2022 00:48:13 GMT Subject: Integrated: JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 21:22:58 GMT, Joe Darcy wrote: > The SuppressWarnings annotation type is declared have multiple targets, including modules; however, "package" is left off of its target list. As package-info file are another kind of declaration where a compiler could give warnings, allowing SuppressWarnings in that case is reasonable. Wanting SuppressWarnings in package-info file came up while working on doclint warnings (JDK-8280534). > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8280745 > > While the SuppressWarnings annotation does have a JLS section (9.6.4.5. @SuppressWarnings), the section doesn't mention the target list therefore doesn't appear to need to be updated. This pull request has now been integrated. Changeset: 78574057 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/78574057a4758fc3da5f39af77df09dc2232a9a1 Stats: 56 lines in 1 file changed: 37 ins; 12 del; 7 mod 8280744: Allow SuppressWarnings to be used in all declaration contexts Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7239 From duke at openjdk.java.net Fri Jan 28 00:55:12 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 28 Jan 2022 00:55:12 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 17:49:42 GMT, Stuart Marks wrote: > This will also need a regression test. It should have a case to ensure that `asRandom` returns `this` if it's already an instance of `Random`. Maybe also a simple case of shuffling a list, similar to the gist. Also see if there are some tests for Random already that this can be plugged into. Will be doing the tests as soon as i can, thanks for the review ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Jan 28 01:10:12 2022 From: duke at openjdk.java.net (liach) Date: Fri, 28 Jan 2022 01:10:12 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: References: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> Message-ID: On Fri, 28 Jan 2022 00:36:57 GMT, Yasser Bazzi wrote: >> Suggest: >> >>> Returns an instance of {@link java.util.Random} based on this {@code RandomGenerator}. >>> If this generator is already an instance of {@code Random}, it is returned. Otherwise, this method >>> returns an instance of {@code Random} that delegates all methods except `setSeed` to this >>> generator. Its `setSeed` method always throws {@link UnsupportedOperationException}. >> >> (Note no link is necessary for RandomGenerator since we are in that class already.) > > Commited the change on df78e05e3e692e2189c9d318fbd4892a4b96a55f Will we gradually phase out the `Random` class? If yes, we should put this conversion method in `Random` so that we don't break the newer API shall `Random` be retired. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From mchung at openjdk.java.net Fri Jan 28 01:54:16 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 28 Jan 2022 01:54:16 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote: > The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. > > Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). > > One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7237 From mandy.chung at oracle.com Fri Jan 28 01:54:19 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Jan 2022 17:54:19 -0800 Subject: Fix proposal for bug JDK-8221642 In-Reply-To: References: Message-ID: I see how NPE is thrown (from `AccessibleObject::setAccessible` and `trySetAccessible`).? The proper fix should follow the rule as the access check that it can set the accessible flag only on public members of a public type that is exported unconditionally. The fix is straight forward but involves spec change.? I'll post PR soon. Mandy On 1/27/22 8:45 AM, Mandy Chung wrote: > Hi Andreas, > > What methods are you calling that throws NPE?? Do you have the stack > trace to share? > > The spec of AccessibleObject was updated for JDK-8221530 if there is > no caller frame when calling from JNI: > > "The check when invoked by JNI code with no Java class on the stack > only succeeds if the member and the declaring class are public, and > the class is in a package that is exported to all modules." > > I think AccessibleObject::canAccess, setAccessible, trySetAccessible > should follow the same rule. > > Mandy > > On 1/27/22 2:19 AM, Andreas Rosenberg wrote: >> Hi, >> >> this is my first posting regarding to JDK contribution, so this may be the wrong place to ask. >> Please point me in the right direction in this case. >> >> We are using Java rather heavily via JNI on a custom application. For a long time we did stick to JRE 1.8 >> for various reasons. My task is to plan an upgrade to a more recent JDK version and while doing some >> test I encountered bugs related to this: JDK-8227491 (JNI - caller sensitive methods). >> >> We are parsing Java class files to auto gen the JNI code for our application, and are also using reflection. >> The workaround given is clumsy and needs manual intervention, so I was looking for a more elegant solution. >> >> The problem is: a caller sensitive method wants to determine the caller class for security checks. In case of >> a JNI call no Java stack frame exists, so the JVM function "jclass JVM_GetCallerClass(JNIEnv* env)" answers NULL >> which leads to NPEs. >> >> My idea is this: create an internal proxy class inside "java.base" that reflects this case >> (e.g. "java.lang.NativeCall" or "java.lang.NativeCode"). >> This class is final and implements nothing. >> >> Then "jclass JVM_GetCallerClass(JNIEnv* env)" (jvm.cpp) could be modified and instead of answering NULL >> in case of a JNI call, it should do this to answer the class proxy: >> >> return JVM_FindClassFromBootLoader(env, "java/lang/NativeCall"); >> >> This would have the following advantages: >> - JNI code could again simply call "caller sensitive methods" without the need to make an additional wrapper class >> - it would be more a expressive way on the Java side to detect "the callee is native code" than checking for null >> - it would fit better into the framework >> >> I already applied this fix on my own copy of the JDK 17 sources and it works pretty well for us. >> >> As there are probably security considerations involved, advice from experts is required. >> But from my understanding the Java security model is designed for the main app being writing in Java. >> In this case there are always Java stacks frames available as parents for caller sensitive methods, so >> the proposed fix would not affect the behavior. This assumes that "GetCallerClass" only answers >> NULL for the JNI case. This needs verification. >> >> If the main app is native code which uses JNI, the Java security model can only affect the Java part and >> as soon as an additional Java stack frame has been generated a regular Java class will be found and >> the "standard behavior" should apply again. >> >> Comments appreciated. >> >> It this fix looks reasonable, what are the steps to get it implemented and integrated into the official >> source tree? >> >> Best regards, >> Andy >> >> From darcy at openjdk.java.net Fri Jan 28 02:15:59 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 28 Jan 2022 02:15:59 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking [v2] In-Reply-To: References: Message-ID: > The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. > > Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). > > One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Use capabilities of JDK-8280744. - Merge branch 'master' into JDK-8280534 - Cover java.base. - JDK-8280534: Enable compile-time doclint reference checking ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7237/files - new: https://git.openjdk.java.net/jdk/pull/7237/files/70e9fb4a..d03401c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7237&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7237&range=00-01 Stats: 2743 lines in 129 files changed: 1556 ins; 659 del; 528 mod Patch: https://git.openjdk.java.net/jdk/pull/7237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7237/head:pull/7237 PR: https://git.openjdk.java.net/jdk/pull/7237 From aturbanov at openjdk.java.net Fri Jan 28 07:07:12 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 28 Jan 2022 07:07:12 GMT Subject: RFR: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. In-Reply-To: References: Message-ID: <7fp4XFwYL89kfGR5voz_FQ2yXx0w_8iK5EI32FqaVzI=.387c57e5-7e6b-4db3-979d-222460c5dbdf@github.com> On Thu, 20 Jan 2022 21:10:39 GMT, Andrey Turbanov wrote: > Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: > > ----------System.out:(12/489)---------- > --- Testing df > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > D: 59672 59672 0 100% /cygdrive/d > > > SecurityManager = null > C:/Programs/cygwin64: > df total= 299877003264 free = 0 usable = 248988995584 > getX total= 299877003264 free = 248988995584 usable = 248988995584 > :: > df total= 61104128 free = 0 usable = 0 > getX total= 0 free = 0 usable = 0 > ----------System.err:(23/1617)---------- > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) > at java.base/java.io.File.toPath(File.java:2396) > at GetXSpace.compare(GetXSpace.java:223) > at GetXSpace.testDF(GetXSpace.java:403) > at GetXSpace.main(GetXSpace.java:437) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > Parsing of df output is incorrect. It skips first symbols after matching of line. > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L160 > > It means that after matching first line: > > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > > > It skips first symbols of next line - symbol `D` and then proceeds to match _corrupted_ line: > > : 59672 59672 0 100% /cygdrive/d > > > Problems affects only Windows, because only in Windows case first group of matcher is used: > > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L155-L156 > > > Testing: > * Windows x64 - always failed before. No errors after fix > * Linux x64 Thank you for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/7170 From aturbanov at openjdk.java.net Fri Jan 28 07:07:12 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 28 Jan 2022 07:07:12 GMT Subject: Integrated: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 21:10:39 GMT, Andrey Turbanov wrote: > Test `test/java/io/File/GetXSpace.java` always failed on my machine with this output: > > ----------System.out:(12/489)---------- > --- Testing df > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > D: 59672 59672 0 100% /cygdrive/d > > > SecurityManager = null > C:/Programs/cygwin64: > df total= 299877003264 free = 0 usable = 248988995584 > getX total= 299877003264 free = 248988995584 usable = 248988995584 > :: > df total= 61104128 free = 0 usable = 0 > getX total= 0 free = 0 usable = 0 > ----------System.err:(23/1617)---------- > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) > at java.base/java.io.File.toPath(File.java:2396) > at GetXSpace.compare(GetXSpace.java:223) > at GetXSpace.testDF(GetXSpace.java:403) > at GetXSpace.main(GetXSpace.java:437) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:833) > > Parsing of df output is incorrect. It skips first symbols after matching of line. > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L160 > > It means that after matching first line: > > C:/Programs/cygwin64 292848636 49695320 243153316 17% / > > > It skips first symbols of next line - symbol `D` and then proceeds to match _corrupted_ line: > > : 59672 59672 0 100% /cygdrive/d > > > Problems affects only Windows, because only in Windows case first group of matcher is used: > > https://github.com/openjdk/jdk/blob/293fb46f7cd28f2a08055e3eb8ec9459d64e9688/test/jdk/java/io/File/GetXSpace.java#L155-L156 > > > Testing: > * Windows x64 - always failed before. No errors after fix > * Linux x64 This pull request has now been integrated. Changeset: 178ac746 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/178ac7465360729628521a0d555253b9fb2ad7bf Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7170 From raffaello.giulietti at gmail.com Fri Jan 28 09:07:43 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 28 Jan 2022 10:07:43 +0100 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec In-Reply-To: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> References: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> Message-ID: Hello, if I understand correctly, the issue addressed here (on Windows) is how to assemble a single command string from an array of argument strings to pass to CreateProcess() in a way that the individual argument strings can be fully recovered in the invoked program. Similarly when the command string is passed to an instance of cmd.exe. Are there known (non security critical) examples that do not work correctly JDK 18 or earlier? Greetings Raffaello On 2022-01-20 19:05, Roger Riggs wrote: > A JEP to Improve safety of process launch by ProcessBuilder and > Runtime.exec on Windows[1]. > > Argument encoding errors have been problematic on Windows systems due to > improperly quoted command arguments. > > The idea is to tighten up quoting and encoding of command line arguments. > > Comments appreciated,? Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8263697 From lancea at openjdk.java.net Fri Jan 28 11:48:13 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 28 Jan 2022 11:48:13 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 02:15:59 GMT, Joe Darcy wrote: >> The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. >> >> Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). >> >> One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Use capabilities of JDK-8280744. > - Merge branch 'master' into JDK-8280534 > - Cover java.base. > - JDK-8280534: Enable compile-time doclint reference checking Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7237 From duke at openjdk.java.net Fri Jan 28 13:35:13 2022 From: duke at openjdk.java.net (kabutz) Date: Fri, 28 Jan 2022 13:35:13 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7] In-Reply-To: References: Message-ID: <53BbZ-JCQC-VYY7_RWW5OXBZfo1186-pLZXzwZwF9Q8=.a02e7eb6-0805-4ccb-b594-4645d7d03fc2@github.com> On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote: >>> > embarrassingly parallelizable >>> >>> Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that. >> >> Ok, fair point, to avoid possible confusion I have removed "embarrassingly". I don't think we need to refer to other algorithms. > > Hi @PaulSandoz is there anything else that we need to do? Or is this in the hopper for Java 19 already? > @kabutz please see comments from Joe on the [CSR](https://bugs.openjdk.java.net/browse/JDK-8278886), which should be easy to address (i can update the CSR after you make changes). I'm working on some results for the question by Joe about the latency vs CPU usage for the parallelMultiply() vs multiply() methods. It wasn't so easy, because measuring a single thread is easier than all of the FJP threads. But I have a nice benchmark that I'm running now. I had to write my own harness and not use JMH, because I don't think that JMH can test at that level. I'm also measuring object allocation. Furthermore, I'm testing against all Java versions going back to Java 8, to make sure that we don't get any surprises. Here is my version: BigInteger.multiply() real 0m22.616s user 0m22.470s sys 0m0.008s mem 84.0GB BigInteger.parallelMultiply() real 0m6.283s user 1m3.200s sys 0m0.004s mem 84.0GB I will upload the results for all the Java versions later, and will also submit the benchmark. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From shade at openjdk.java.net Fri Jan 28 15:44:34 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 28 Jan 2022 15:44:34 GMT Subject: RFR: 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops Message-ID: Recent test regression after adding new cases in the test. Without compressed oops, ~1G elements `Object[]` array takes >8G of memory, which fails the test. The fix cuts it down to 512M when reference size is 8 bytes. Additionally, `ObjectAlignmentInBytes=32` is excessive for new test configs. Additional testing: - [x] Linux x86_64 fastdebug, default, affected test still passes - [x] Linux x86_32 fastdebug, default, affected test still passes - [x] Linux x86_64 fastdebug, `-XX:-UseCompressedOops`, affected test now passes ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/7269/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7269&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280889 Stats: 10 lines in 1 file changed: 1 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7269.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7269/head:pull/7269 PR: https://git.openjdk.java.net/jdk/pull/7269 From roger.riggs at oracle.com Fri Jan 28 15:48:56 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 28 Jan 2022 10:48:56 -0500 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec In-Reply-To: References: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> Message-ID: Hi Raffaello, For .exe executables, one example is an empty string in the list of arguments to ProcessBuilder. The empty string is not visible in the generated command line. For position sensitive commands, it appears the argument is dropped. An argument in ProcessBuilder with mismatched quotes can cause the argument to be joined with the next in the generated command line. A stray "\" at the end of an argument can cause the following character to be quoted, possibly joining the argument with the next. For .cmd executables, cmd.exe interprets more characters as argument separators and will split arguments. For example, an argument with a semi-colon or comma, (unquoted) will be split into two arguments when parsed by cmd.exe. The goal is to improve the integrity and robustness of the command encoding. Thanks, Roger On 1/28/22 4:07 AM, Raffaello Giulietti wrote: > Hello, > > if I understand correctly, the issue addressed here (on Windows) is > how to assemble a single command string from an array of argument > strings to pass to CreateProcess() in a way that the individual > argument strings can be fully recovered in the invoked program. > Similarly when the command string is passed to an instance of cmd.exe. > > Are there known (non security critical) examples that do not work > correctly JDK 18 or earlier? > > > Greetings > Raffaello > > > On 2022-01-20 19:05, Roger Riggs wrote: >> A JEP to Improve safety of process launch by ProcessBuilder and >> Runtime.exec on Windows[1]. >> >> Argument encoding errors have been problematic on Windows systems due to >> improperly quoted command arguments. >> >> The idea is to tighten up quoting and encoding of command line >> arguments. >> >> Comments appreciated,? Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8263697 From rriggs at openjdk.java.net Fri Jan 28 16:05:12 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 28 Jan 2022 16:05:12 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 00:36:01 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with four additional commits since the last revision: > > - make sure setseed its initialized and throw > - remove tabs > - Change name of function from wrapRandom to wrap > - Change variable name and wording in javadocs (For future reference: As tempting as it is to make other small improvements to the code such as missing but optional @ Overrides, it obscures the changes that are the subject of the PR.). src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 36: > 34: /** > 35: * Class used to wrap a {@link java.util.random.RandomGenerator} to > 36: * {@link java.util.Random} Missing period at end of sentence. src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 42: > 40: public class RandomWrapper extends Random implements RandomGenerator { > 41: private final RandomGenerator generator; > 42: private boolean initialized; "final" would be appropriate here. src/java.base/share/classes/jdk/internal/util/random/RandomWrapper.java line 59: > 57: /** > 58: * setSeed does not exist in {@link java.util.random.RandomGenerator} so can't > 59: * use it Missing period. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From michaelm at openjdk.java.net Fri Jan 28 16:58:55 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 28 Jan 2022 16:58:55 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v13] In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: spec update from CSR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7065/files - new: https://git.openjdk.java.net/jdk/pull/7065/files/59f703da..468e5345 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7065&range=11-12 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7065/head:pull/7065 PR: https://git.openjdk.java.net/jdk/pull/7065 From dfuchs at openjdk.java.net Fri Jan 28 17:24:22 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 28 Jan 2022 17:24:22 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v13] In-Reply-To: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> Message-ID: On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > spec update from CSR Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From andreas.rosenberg at apis.de Fri Jan 28 11:15:39 2022 From: andreas.rosenberg at apis.de (Andreas Rosenberg) Date: Fri, 28 Jan 2022 11:15:39 +0000 Subject: Fix proposal for bug JDK-8221642 In-Reply-To: References: Message-ID: Hi Mandy, thanks for looking at my problem. Yes, "setAccessible" is one of the problems, but our main issue is related to "ResourceBundle". I've created a small example that shows the problem: https://github.com/anrose00/JniSensitiveCaller Any comments on my proposal would be great. Andreas From: Mandy Chung Sent: Freitag, 28. Januar 2022 02:54 To: Andreas Rosenberg Cc: hotspot-dev at openjdk.java.net; 'core-libs-dev' Subject: Re: Fix proposal for bug JDK-8221642 I see how NPE is thrown (from `AccessibleObject::setAccessible` and `trySetAccessible`). The proper fix should follow the rule as the access check that it can set the accessible flag only on public members of a public type that is exported unconditionally. The fix is straight forward but involves spec change. I'll post PR soon. Mandy On 1/27/22 8:45 AM, Mandy Chung wrote: Hi Andreas, What methods are you calling that throws NPE? Do you have the stack trace to share? The spec of AccessibleObject was updated for JDK-8221530 if there is no caller frame when calling from JNI: "The check when invoked by JNI code with no Java class on the stack only succeeds if the member and the declaring class are public, and the class is in a package that is exported to all modules." I think AccessibleObject::canAccess, setAccessible, trySetAccessible should follow the same rule. Mandy On 1/27/22 2:19 AM, Andreas Rosenberg wrote: Hi, this is my first posting regarding to JDK contribution, so this may be the wrong place to ask. Please point me in the right direction in this case. We are using Java rather heavily via JNI on a custom application. For a long time we did stick to JRE 1.8 for various reasons. My task is to plan an upgrade to a more recent JDK version and while doing some test I encountered bugs related to this: JDK-8227491 (JNI - caller sensitive methods). We are parsing Java class files to auto gen the JNI code for our application, and are also using reflection. The workaround given is clumsy and needs manual intervention, so I was looking for a more elegant solution. The problem is: a caller sensitive method wants to determine the caller class for security checks. In case of a JNI call no Java stack frame exists, so the JVM function "jclass JVM_GetCallerClass(JNIEnv* env)" answers NULL which leads to NPEs. My idea is this: create an internal proxy class inside "java.base" that reflects this case (e.g. "java.lang.NativeCall" or "java.lang.NativeCode"). This class is final and implements nothing. Then "jclass JVM_GetCallerClass(JNIEnv* env)" (jvm.cpp) could be modified and instead of answering NULL in case of a JNI call, it should do this to answer the class proxy: return JVM_FindClassFromBootLoader(env, "java/lang/NativeCall"); This would have the following advantages: - JNI code could again simply call "caller sensitive methods" without the need to make an additional wrapper class - it would be more a expressive way on the Java side to detect "the callee is native code" than checking for null - it would fit better into the framework I already applied this fix on my own copy of the JDK 17 sources and it works pretty well for us. As there are probably security considerations involved, advice from experts is required. But from my understanding the Java security model is designed for the main app being writing in Java. In this case there are always Java stacks frames available as parents for caller sensitive methods, so the proposed fix would not affect the behavior. This assumes that "GetCallerClass" only answers NULL for the JNI case. This needs verification. If the main app is native code which uses JNI, the Java security model can only affect the Java part and as soon as an additional Java stack frame has been generated a regular Java class will be found and the "standard behavior" should apply again. Comments appreciated. It this fix looks reasonable, what are the steps to get it implemented and integrated into the official source tree? Best regards, Andy From aixtools at felt.demon.nl Fri Jan 28 14:07:54 2022 From: aixtools at felt.demon.nl (Michael Felt) Date: Fri, 28 Jan 2022 15:07:54 +0100 Subject: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected In-Reply-To: <4cd329f0-766b-3f50-da29-c1908a0f1bd1@oracle.com> References: <4cd329f0-766b-3f50-da29-c1908a0f1bd1@oracle.com> Message-ID: <054d01d81450$71fe2590$55fa70b0$@felt.demon.nl> Thanks Alan - for opening the ticket. (Open my eyes). Still need to know if I am expected to repond to the ticket, and if so - how. -----Original Message----- From: Alan Bateman Sent: Saturday, 22 January 2022 11:00 To: Thomas St?fe ; Michael Felt Cc: ppc-aix-port-dev ; Java Core Libs Subject: Re: Pull Request: 7013: AIX: InetAddress.getByName(addr) does not work as expected On 22/01/2022 08:40, Thomas St?fe wrote: > Hi Micheal, > > welcome, and thank you for your contribution! > > I opened a bug id for you to track this: > https://bugs.openjdk.java.net/browse/JDK-8280498 . I can sponsor this > patch for you. > > You need one reviewer, I think. I don't have the cycles right now to > think this through. I cc core-libs dev since this is a networking > issue and one of their tests. > The networking tests are maintained on net-dev so if there is a PR then it should go to that list. -Alan From minqi at openjdk.java.net Fri Jan 28 17:47:08 2022 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 28 Jan 2022 17:47:08 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 08:59:49 GMT, Alan Bateman wrote: >> Please review, >> When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. >> The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. >> >> Tests: tier1,4,7 in test >> Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. >> >> Thanks >> Yumin > > I think this looks okay but I think @JimLaskey and/or @sundararajana should look at this because it creates a dependency on a JVM_* function. I'm trying to think if there are any interop issues when using jrtfs. Jim/Sundar can correct me but I think we are okay there because a tool on say JDK 8 (or 11 or 17) that accesses a JDK 19 run-time image will use the BasicImageReader and won't use libjimage in the target VM. Thanks to @AlanBateman, @JimLaskey or @sundararajana Could you have a look and comment? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From mchung at openjdk.java.net Fri Jan 28 17:57:36 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 28 Jan 2022 17:57:36 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack Message-ID: `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. ------------- Commit messages: - Fix typo - 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack Changes: https://git.openjdk.java.net/jdk/pull/7271/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7271&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8221642 Stats: 193 lines in 3 files changed: 166 ins; 19 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7271/head:pull/7271 PR: https://git.openjdk.java.net/jdk/pull/7271 From iris at openjdk.java.net Fri Jan 28 18:12:11 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 28 Jan 2022 18:12:11 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 02:15:59 GMT, Joe Darcy wrote: >> The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. >> >> Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). >> >> One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Use capabilities of JDK-8280744. > - Merge branch 'master' into JDK-8280534 > - Cover java.base. > - JDK-8280534: Enable compile-time doclint reference checking Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7237 From naoto.sato at oracle.com Fri Jan 28 18:58:19 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 28 Jan 2022 10:58:19 -0800 Subject: Additional Date-Time Formats In-Reply-To: References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <00218c0e-31ea-d8ea-efe3-6920c42ea0a1@oracle.com> Message-ID: <5bef91c6-b6e8-9e0d-69c7-1bfaad653023@oracle.com> Updated the CSR based on your inputs. On 1/27/22 2:34 PM, Stephen Colebourne wrote: > On Thu, 27 Jan 2022 at 19:23, Naoto Sato wrote: >> Now come to think of it, I came up with the draft based on `ofPattern()` >> methods. One of them is a overload method that takes a Locale argument. >> Why is it so? > > There is a case for the Locale on the static method (as a convenience, > and to remind callers that the locale matters). But there is no case > for it on the builder. Eliminated the overload with locale. Instead, added a static method DateTimeFormatterBuilder.getLocalizedDateTimePattern() that take "requestedTemplate". Also, renamed `appendLocalizedPattern` to `appendLocalized` to make it an overload method to the existing one. > >>> The spec Javadoc doesn't explain what repeating the pattern letter >>> actually does/means. Is "M" the same as "MMMM"? >> >> That depends on the locale and the availability of the formats. For >> example, 'M' translates into these patterns in each locale with >> Gregorian calendar: >> >> https://unicode-org.github.io/cldr-staging/charts/40/by_type/date_&_time.gregorian.html#959cbb42bb2962f > > As things stand, the Javadoc isn't a standalone spec. I don't know how > much that matters, but I think there should be some indication in > Javadoc as to why the letter should be repeated. Added a description that explains the number of pattern letters. They follow the same presentation rule as in the pattern chart. Naoto From duke at openjdk.java.net Fri Jan 28 18:59:56 2022 From: duke at openjdk.java.net (kabutz) Date: Fri, 28 Jan 2022 18:59:56 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v9] In-Reply-To: References: Message-ID: > BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. > > The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. > > We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. > > Some benchmark results, run on my 1-6-2 server: > > > Benchmark (n) Mode Cnt Score Error Units > BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op > BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op > BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op > BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op > BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op > BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op > > > We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. kabutz has updated the pull request incrementally with one additional commit since the last revision: Benchmark for testing the effectiveness of BigInteger.parallelMultiply() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6409/files - new: https://git.openjdk.java.net/jdk/pull/6409/files/25e8c082..fc7b844a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=07-08 Stats: 322 lines in 1 file changed: 322 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6409/head:pull/6409 PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Fri Jan 28 19:07:14 2022 From: duke at openjdk.java.net (kabutz) Date: Fri, 28 Jan 2022 19:07:14 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v9] In-Reply-To: References: Message-ID: <9lT4l0k6ne9HRhgOwC0shZoz-s0jiBfoUCKLpVIDCco=.a118b244-d037-4daa-a991-9b6850c49498@github.com> On Fri, 28 Jan 2022 18:59:56 GMT, kabutz wrote: >> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. >> >> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. >> >> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. >> >> Some benchmark results, run on my 1-6-2 server: >> >> >> Benchmark (n) Mode Cnt Score Error Units >> BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op >> BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op >> BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op >> BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op >> BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op >> BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op >> >> >> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Benchmark for testing the effectiveness of BigInteger.parallelMultiply() I have added a benchmark for checking performance difference between sequential and parallel multiply of very large Mersenne primes using BigInteger. We want to measure real time, user time, system time and the amount of memory allocated. To calculate this, we create our own thread factory for the common ForkJoinPool and then use that to measure user time, cpu time and bytes allocated. We use reflection to discover all methods that match "*ultiply", and use them to multiply two very large Mersenne primes together. ### Results on a 1-6-2 machine running Ubuntu linux Memory allocation increased from 83.9GB to 84GB, for both the sequential and parallel versions. This is an increase of just 0.1%. On this machine, the parallel version was 3.8x faster in latency (real time), but it used 2.7x more CPU resources. Testing multiplying Mersenne primes of 2^57885161-1 and 2^82589933-1 #### openjdk version "18-internal" 2022-03-15 BigInteger.parallelMultiply() real 0m6.288s user 1m3.010s sys 0m0.027s mem 84.0GB BigInteger.multiply() real 0m23.682s user 0m23.530s sys 0m0.004s mem 84.0GB #### openjdk version "1.8.0_302" BigInteger.multiply() real 0m25.657s user 0m25.390s sys 0m0.001s mem 83.9GB #### openjdk version "9.0.7.1" BigInteger.multiply() real 0m24.907s user 0m24.700s sys 0m0.001s mem 83.9GB #### openjdk version "10.0.2" 2018-07-17 BigInteger.multiply() real 0m24.632s user 0m24.380s sys 0m0.004s mem 83.9GB #### openjdk version "11.0.12" 2021-07-20 LTS BigInteger.multiply() real 0m22.114s user 0m21.930s sys 0m0.001s mem 83.9GB #### openjdk version "12.0.2" 2019-07-16 BigInteger.multiply() real 0m23.015s user 0m22.830s sys 0m0.000s mem 83.9GB #### openjdk version "13.0.9" 2021-10-19 BigInteger.multiply() real 0m23.548s user 0m23.350s sys 0m0.005s mem 83.9GB #### openjdk version "14.0.2" 2020-07-14 BigInteger.multiply() real 0m22.918s user 0m22.530s sys 0m0.131s mem 83.9GB #### openjdk version "15.0.5" 2021-10-19 BigInteger.multiply() real 0m22.038s user 0m21.750s sys 0m0.003s mem 83.9GB #### openjdk version "16.0.2" 2021-07-20 BigInteger.multiply() real 0m23.049s user 0m22.760s sys 0m0.006s mem 83.9GB #### openjdk version "17" 2021-09-14 BigInteger.multiply() real 0m22.580s user 0m22.310s sys 0m0.001s mem 83.9GB ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From mandy.chung at oracle.com Fri Jan 28 19:07:58 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 28 Jan 2022 11:07:58 -0800 Subject: Fix proposal for bug JDK-8221642 In-Reply-To: References: Message-ID: <56902d1a-2683-3097-436a-ded5838f4620@oracle.com> Your proposal is essentially for all JNI code with no caller frame to default to java.base, which gets all permissions.? It means that it could break encapsulation to access any members.? Arguably one could consider JNI have superpower.? In addition, default to java.base may not make sense for some Java APIs, ResouroceBundle::getBundle(String bundlename) is one example.? It uses the caller class's loader to load the resource bundle.?? Default to java.base means it defaults to the bootstrap loader which can't find the resource bundle on the class path for example.?? For the ResourceBundle case, it seems that the unnamed module defined by the system class loader might be an appropriate default. The proper way is to examine each caller-sensitive method and investigate what makes sense when invoked by JNI code with no caller frame.? JDK-8177155 is the RFE for such task. System::getLogger, Logger::getLogger, and core reflection API are looked at but more to follow up. I created https://bugs.openjdk.java.net/browse/JDK-8280902 to follow up the ResourceBundle::getBundle issue. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8177155 On 1/28/22 3:15 AM, Andreas Rosenberg wrote: > > Hi Mandy, > > thanks for looking at my problem. Yes, "setAccessible" is one of the > problems, > > but our main issue is related to "ResourceBundle". > > I've created a small example that shows the > problem:https://github.com/anrose00/JniSensitiveCaller > > > Any comments on my proposal would be great. > > Andreas > > *From:*Mandy Chung > *Sent:* Freitag, 28. Januar 2022 02:54 > *To:* Andreas Rosenberg > *Cc:* hotspot-dev at openjdk.java.net; 'core-libs-dev' > > *Subject:* Re: Fix proposal for bug JDK-8221642 > > I see how NPE is thrown (from `AccessibleObject::setAccessible` and > `trySetAccessible`). The proper fix should follow the rule as the > access check that it can set the accessible flag only on public > members of a public type that is exported unconditionally. > > The fix is straight forward but involves spec change.? I'll post PR soon. > > Mandy > > On 1/27/22 8:45 AM, Mandy Chung wrote: > > Hi Andreas, > > What methods are you calling that throws NPE?? Do you have the > stack trace to share? > > The spec of AccessibleObject was updated for JDK-8221530 if there > is no caller frame when calling from JNI: > > "The check when invoked by JNI code with no Java class on the > stack only succeeds if the member and the declaring class are > public, and the class is in a package that is exported to all > modules." > > I think AccessibleObject::canAccess, setAccessible, > trySetAccessible should follow the same rule. > > Mandy > > On 1/27/22 2:19 AM, Andreas Rosenberg wrote: > > Hi, > > this is my first posting regarding to JDK contribution, so this may be the wrong place to ask. > > Please point me in the right direction in this case. > > We are using Java rather heavily via JNI on a custom application. For a long time we did stick to JRE 1.8 > > for various reasons. My task is to plan an upgrade to a more recent JDK version and while doing some > > test I encountered bugs related to this: JDK-8227491(JNI - caller sensitive methods). > > We are parsing Java class files to auto gen the JNI code for our application, and are also using reflection. > > The workaround given is clumsy and needs manual intervention, so I was looking for a more elegant solution. > > The problem is: a caller sensitive method wants to determine the caller class for security checks. In case of > > a JNI call no Java stack frame exists, so the JVM function "jclass JVM_GetCallerClass(JNIEnv* env)" answers NULL > > which leads to NPEs. > > My idea is this: create an internal proxy class inside "java.base" that reflects this case > > (e.g. "java.lang.NativeCall" or "java.lang.NativeCode"). > > This class is final and implements nothing. > > Then "jclass JVM_GetCallerClass(JNIEnv* env)" (jvm.cpp) could be modified and instead of answering NULL > > in case of a JNI call, it should do this to answer the class proxy: > > return JVM_FindClassFromBootLoader(env, "java/lang/NativeCall"); > > This would have the following advantages: > > - JNI code could again simply call "caller sensitive methods" without the need to make an additional wrapper class > > - it would be more a expressive way on the Java side to detect "the callee is native code" than checking for null > > - it would fit better into the framework > > I already applied this fix on my own copy of the JDK 17 sources and it works pretty well for us. > > As there are probably security considerations involved, advice from experts is required. > > But from my understanding the Java security model is designed for the main app being writing in Java. > > In this case there are always Java stacks frames available as parents for caller sensitive methods, so > > the proposed fix would not affect the behavior. This assumes that "GetCallerClass" only answers > > NULL for the JNI case. This needs verification. > > If the main app is native code which uses JNI, the Java security model can only affect the Java part and > > as soon as an additional Java stack frame has been generated a regular Java class will be found and > > the "standard behavior" should apply again. > > Comments appreciated. > > It this fix looks reasonable, what are the steps to get it implemented and integrated into the official > > source tree? > > Best regards, > > Andy > From raffaello.giulietti at gmail.com Fri Jan 28 19:14:51 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 28 Jan 2022 20:14:51 +0100 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec In-Reply-To: References: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> Message-ID: <025c6750-6d5f-31dc-897b-c2211fed3635@gmail.com> Hi Roger, I'm trying the following (ugly) code on JDK 17/Win, where Args.exe does nothing else than writing out its argv[], redirecting to a log file. public static void main(String[] args) throws IOException, InterruptedException { String[] command = { "C:\\Users\\alpha\\Args.exe", "", "a", "", "b", "", }; var processBuilder = new ProcessBuilder(command); processBuilder.redirectOutput(new File("C:\\Users\\alpha\\my.log")); var process = processBuilder.start(); Thread.sleep(2_000); System.out.println("process.exitValue() = " + process.exitValue()); } Here's the log file argv[0] = [C:\Users\alpha\Args.exe] argv[1] = [] argv[2] = [a] argv[3] = [] argv[4] = [b] argv[5] = [] so empty args seem to work correctly, at least in this plain example. Have you specific examples that behave incorrectly? I'm asking because I'd like to setup a simple set of rules to solve the issue on Windows altogether. On 2022-01-28 16:48, Roger Riggs wrote: > Hi Raffaello, > > For .exe executables, one example is an empty string in the list of > arguments to ProcessBuilder. > The empty string is not visible in the generated command line. For > position sensitive commands, it appears the argument is dropped. > An argument in ProcessBuilder with mismatched quotes can cause the > argument to be joined with the next in the generated command line. > A stray "\" at the end of an argument can cause the following character > to be quoted, possibly joining the argument with the next. > > For .cmd executables, cmd.exe interprets more characters as argument > separators and will split arguments. > For example, an argument with a semi-colon or comma, (unquoted) will be > split into two arguments when parsed by cmd.exe. > The goal is to improve the integrity and robustness of the command > encoding. > > Thanks, Roger > > > On 1/28/22 4:07 AM, Raffaello Giulietti wrote: >> Hello, >> >> if I understand correctly, the issue addressed here (on Windows) is >> how to assemble a single command string from an array of argument >> strings to pass to CreateProcess() in a way that the individual >> argument strings can be fully recovered in the invoked program. >> Similarly when the command string is passed to an instance of cmd.exe. >> >> Are there known (non security critical) examples that do not work >> correctly JDK 18 or earlier? >> >> >> Greetings >> Raffaello >> >> >> On 2022-01-20 19:05, Roger Riggs wrote: >>> A JEP to Improve safety of process launch by ProcessBuilder and >>> Runtime.exec on Windows[1]. >>> >>> Argument encoding errors have been problematic on Windows systems due to >>> improperly quoted command arguments. >>> >>> The idea is to tighten up quoting and encoding of command line >>> arguments. >>> >>> Comments appreciated,? Roger >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8263697 > From smarks at openjdk.java.net Fri Jan 28 19:15:12 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 28 Jan 2022 19:15:12 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: References: <5Qowenxfkc3pTR0jIzgy3lInCCD5PiBRl-IpfB11yH4=.6ab8b880-03c3-4c06-b225-d81f42e8cd35@github.com> Message-ID: <-eya7RBhLf6ojOwX_BD6Pfe13-6stojrVAeqxoBJigM=.603d9640-cd93-4627-8a20-e3c7454ecae5@github.com> On Fri, 28 Jan 2022 01:06:47 GMT, liach wrote: >> Commited the change on df78e05e3e692e2189c9d318fbd4892a4b96a55f > > Will we gradually phase out the `Random` class? If yes, we should put this conversion method in `Random` so that we don't break the newer API shall `Random` be retired. I don't think Random will ever be removed, so this probably isn't an issue. There is the overall question of which factoring is preferable: adding a default method on RandomGenerator, as is done here, or an alternative of adding a static utility to Random, something like: // Random.java public static Random from(RandomGenerator generator) { ... } This makes the call site a bit longer and adds a level of nesting: Collections.shuffle(list, Random.from(RandomGenerator.of("L64X128MixRandom"))); compared to the default method approach: Collections.shuffle(list, RandomGenerator.of("L64X128MixRandom").asRandom()); I believe this allows the wrapper class to be placed in java.util, or even as a nested class of Random, instead of having to be a new top-level class in jdk.internal. Another consideration is whether the adapter should be on the "new" thing or on the "old" thing. There's a little bit of precedent to put adapters on the "old" thing so that the "new" thing doesn't get polluted with the old. For example, consider Enumeration::asIterator. (Even though the adaptation is going the other way in that case, there are still alternative factorings that place the adapter on the new instead of the old.) I don't think any of this is compelling but it's worth a discussion. Regardless of where the adapter ends up, the "other" class should have a note and a link that refers to the adapter. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From roger.riggs at oracle.com Fri Jan 28 20:26:35 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 28 Jan 2022 15:26:35 -0500 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec In-Reply-To: <025c6750-6d5f-31dc-897b-c2211fed3635@gmail.com> References: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> <025c6750-6d5f-31dc-897b-c2211fed3635@gmail.com> Message-ID: <31feedab-f01d-875e-3926-4dec95ae9843@oracle.com> Hi Raffaello, My mistake, the problem with empty args was fixed in 17 as well as some of the problems with escaping of double-quotes.? The default legacy mode does not check for unbalanced quotes possible merging of arguments.? The simplest case are for .exe execution, in which the argument parsing by applications allows a more reliable encoding. The command parsing by cmd.exe is less flexible and has more issues. Setting the system property jdk.lang.Process.allowAmbiguousCommands=false applies some additional checks. But it is not the default. It is a goal to reduce the number of modes and simplify the code in the Windows ProcessImpl. I'm all in favor of solving the problem on Windows, suggestions welcome. But also a consideration is not breaking (too many) existing applications. Thanks, Roger On 1/28/22 2:14 PM, Raffaello Giulietti wrote: > Hi Roger, > > I'm trying the following (ugly) code on JDK 17/Win, where Args.exe > does nothing else than writing out its argv[], redirecting to a log file. > > ??? public static void main(String[] args) throws IOException, > InterruptedException { > ??????? String[] command = { > ??????????????? "C:\\Users\\alpha\\Args.exe", > ??????????????? "", > ??????????????? "a", > ??????????????? "", > ??????????????? "b", > ??????????????? "", > ??????? }; > ??????? var processBuilder = new ProcessBuilder(command); > ??????? processBuilder.redirectOutput(new > File("C:\\Users\\alpha\\my.log")); > ??????? var process = processBuilder.start(); > ??????? Thread.sleep(2_000); > ??????? System.out.println("process.exitValue() = " + > process.exitValue()); > ??? } > > > Here's the log file > > argv[0] = [C:\Users\alpha\Args.exe] > argv[1] = [] > argv[2] = [a] > argv[3] = [] > argv[4] = [b] > argv[5] = [] > > so empty args seem to work correctly, at least in this plain example. > > Have you specific examples that behave incorrectly? > I'm asking because I'd like to setup a simple set of rules to solve > the issue on Windows altogether. > > > > > > On 2022-01-28 16:48, Roger Riggs wrote: >> Hi Raffaello, >> >> For .exe executables, one example is an empty string in the list of >> arguments to ProcessBuilder. >> The empty string is not visible in the generated command line. For >> position sensitive commands, it appears the argument is dropped. >> An argument in ProcessBuilder with mismatched quotes can cause the >> argument to be joined with the next in the generated command line. >> A stray "\" at the end of an argument can cause the following >> character to be quoted, possibly joining the argument with the next. >> >> For .cmd executables, cmd.exe interprets more characters as argument >> separators and will split arguments. >> For example, an argument with a semi-colon or comma, (unquoted) will >> be split into two arguments when parsed by cmd.exe. >> The goal is to improve the integrity and robustness of the command >> encoding. >> >> Thanks, Roger >> >> >> On 1/28/22 4:07 AM, Raffaello Giulietti wrote: >>> Hello, >>> >>> if I understand correctly, the issue addressed here (on Windows) is >>> how to assemble a single command string from an array of argument >>> strings to pass to CreateProcess() in a way that the individual >>> argument strings can be fully recovered in the invoked program. >>> Similarly when the command string is passed to an instance of cmd.exe. >>> >>> Are there known (non security critical) examples that do not work >>> correctly JDK 18 or earlier? >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> On 2022-01-20 19:05, Roger Riggs wrote: >>>> A JEP to Improve safety of process launch by ProcessBuilder and >>>> Runtime.exec on Windows[1]. >>>> >>>> Argument encoding errors have been problematic on Windows systems >>>> due to >>>> improperly quoted command arguments. >>>> >>>> The idea is to tighten up quoting and encoding of command line >>>> arguments. >>>> >>>> Comments appreciated,? Roger >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8263697 >> From rriggs at openjdk.java.net Fri Jan 28 21:08:23 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 28 Jan 2022 21:08:23 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled Message-ID: During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility between the classloaders of the source of the serialized stream and the classloader being used for deserialization. When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. This allows the application to handle the exception consistently with other errors during deserialization. ------------- Commit messages: - 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled Changes: https://git.openjdk.java.net/jdk/pull/7274/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7274&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280642 Stats: 13 lines in 2 files changed: 5 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7274/head:pull/7274 PR: https://git.openjdk.java.net/jdk/pull/7274 From naoto at openjdk.java.net Fri Jan 28 23:45:09 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 28 Jan 2022 23:45:09 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 21:02:23 GMT, Roger Riggs wrote: > During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces > `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. > If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. > When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility > between the classloaders of the source of the serialized stream and the classloader being used for deserialization. > When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch > the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. > This allows the application to handle the exception consistently with other errors during deserialization. Looks good. In the CSR, I see some `InvalidAccessError` which should be `IllegalAccessError`. src/java.base/share/classes/java/io/ObjectInputStream.java line 1999: > 1997: resolveEx = ex; > 1998: } catch (IllegalAccessError err) { > 1999: IOException ice = new InvalidObjectException(err.getMessage()); Would the variable be `ioe`? ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7274 From mchung at openjdk.java.net Fri Jan 28 23:58:06 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 28 Jan 2022 23:58:06 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 21:02:23 GMT, Roger Riggs wrote: > During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces > `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. > If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. > When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility > between the classloaders of the source of the serialized stream and the classloader being used for deserialization. > When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch > the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. > This allows the application to handle the exception consistently with other errors during deserialization. `ObjectInputStream::readObject` does not specify that `InvalidObjectException` may be thrown. Have you considered throwing `InvalidClassException` be an alternative? i.e. extend `InvalidClassException` to report failure in creating the proxy class during deserialization. ------------- PR: https://git.openjdk.java.net/jdk/pull/7274 From rriggs at openjdk.java.net Sat Jan 29 00:21:08 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 29 Jan 2022 00:21:08 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 23:54:54 GMT, Mandy Chung wrote: > `ObjectInputStream::readObject` does not specify that `InvalidObjectException` may be thrown. > Have you considered throwing `InvalidClassException` be an alternative? i.e. extend `InvalidClassException` to report failure in creating the proxy class during deserialization. There are other checks related to the Proxy interfaces that throw InvalidObjectException. InvalidClassException was a close second. The throwing of `IllegalAccessException` is not described for `readObject` and `InvalidObjectException` is a subclass of `IOException` that acts as a catch-all. ------------- PR: https://git.openjdk.java.net/jdk/pull/7274 From sspitsyn at openjdk.java.net Sat Jan 29 01:11:11 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 29 Jan 2022 01:11:11 GMT Subject: RFR: 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote: > Recent test regression after adding new cases in the test. Without compressed oops, ~1G elements `Object[]` array takes >8G of memory, which fails the test. The fix cuts it down to 512M when reference size is 8 bytes. Additionally, `ObjectAlignmentInBytes=32` is excessive for new test configs. > > Additional testing: > - [x] Linux x86_64 fastdebug, default, affected test still passes > - [x] Linux x86_32 fastdebug, default, affected test still passes > - [x] Linux x86_64 fastdebug, `-XX:-UseCompressedOops`, affected test now passes Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7269 From mchung at openjdk.java.net Sat Jan 29 01:37:05 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 29 Jan 2022 01:37:05 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 21:02:23 GMT, Roger Riggs wrote: > During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces > `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. > If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. > When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility > between the classloaders of the source of the serialized stream and the classloader being used for deserialization. > When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch > the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. > This allows the application to handle the exception consistently with other errors during deserialization. `readProxyDesc` throws a mix of `InvalidClassException` and `InvalidObjectException`. I'm not close to the spec of this area and let others to comment which one would be appropriate for this case. In general, wrapping IAE with an existing exception is a reasonable solution. IMO, it'd be helpful to clarify this in the javadoc and document this specific exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/7274 From duke at openjdk.java.net Sat Jan 29 16:13:46 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sat, 29 Jan 2022 16:13:46 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v3] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: - fix missing periods - Use final on initialized variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/c297d42f..ef48bdbd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sat Jan 29 16:13:47 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sat, 29 Jan 2022 16:13:47 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 16:01:56 GMT, Roger Riggs wrote: > (For future reference: As tempting as it is to make other small improvements to the code such as missing but optional @ Overrides, it obscures the changes that are the subject of the PR.). Oh sorry about that, my IDE probably did the changes and it went unnoticed by me, should i revert the offending commit and recommit only the appropriate changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From tvaleev at openjdk.java.net Sat Jan 29 16:38:31 2022 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sat, 29 Jan 2022 16:38:31 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown Message-ID: See the bug description for details. I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. I added a simple test to ensure that at least two threads are actually used when parallelizing Stream.iterate source. More testing ideas are welcome. ------------- Commit messages: - JDK-8280915 Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown Changes: https://git.openjdk.java.net/jdk/pull/7279/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280915 Stats: 128 lines in 2 files changed: 96 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/7279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7279/head:pull/7279 PR: https://git.openjdk.java.net/jdk/pull/7279 From smarks at openjdk.java.net Sat Jan 29 19:42:10 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 29 Jan 2022 19:42:10 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v2] In-Reply-To: References: Message-ID: On Sat, 29 Jan 2022 16:10:28 GMT, Yasser Bazzi wrote: > Oh sorry about that, my IDE probably did the changes and it went unnoticed by me, should i revert the offending commit and recommit only the appropriate changes? Just add a new commit that undoes the unwanted changes. Please don't rebase and force-push (if you were thinking of doing that) because it disrupts the historical comments and incremental diffs. Note that when this is eventually integrated, all the intermediate commits will be "squashed" and a single consolidated commit will be pushed into the JDK mainline. By the way, I'm still thinking about the API factoring issue, and I'm leaning toward having a static factory method on Random instead of a default on RandomGenerator. Still open for discussion though. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From jlaskey at openjdk.java.net Sat Jan 29 21:02:10 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Sat, 29 Jan 2022 21:02:10 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v3] In-Reply-To: References: Message-ID: On Sat, 29 Jan 2022 16:13:46 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - fix missing periods > - Use final on initialized variable I agree with Stuart. This should be added to Random not RandomGenerator. That leaves room in the distant future to deprecate Random without leaving dangly bits on the interface. This also makes sense from an API perspective. RandomGenerator shouldn't force an unnecessary burden on an implementation even as a default. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From tvaleev at openjdk.java.net Sun Jan 30 05:10:42 2022 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sun, 30 Jan 2022 05:10:42 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v2] In-Reply-To: References: Message-ID: > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. > > I added a simple test to ensure that at least two threads are actually used when parallelizing Stream.iterate source. More testing ideas are welcome. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Stabilize test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7279/files - new: https://git.openjdk.java.net/jdk/pull/7279/files/489e95b2..2713d5be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7279/head:pull/7279 PR: https://git.openjdk.java.net/jdk/pull/7279 From tvaleev at openjdk.java.net Sun Jan 30 09:00:46 2022 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sun, 30 Jan 2022 09:00:46 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v3] In-Reply-To: References: Message-ID: > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. > > I added a simple test to ensure that at least two threads are actually used when parallelizing Stream.iterate source. More testing ideas are welcome. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Another testing approach: check splits via collector ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7279/files - new: https://git.openjdk.java.net/jdk/pull/7279/files/2713d5be..726e73e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=01-02 Stats: 14 lines in 1 file changed: 1 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7279/head:pull/7279 PR: https://git.openjdk.java.net/jdk/pull/7279 From dcubed at openjdk.java.net Sun Jan 30 14:25:04 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 30 Jan 2022 14:25:04 GMT Subject: RFR: 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote: > Recent test regression after adding new cases in the test. Without compressed oops, ~1G elements `Object[]` array takes >8G of memory, which fails the test. The fix cuts it down to 512M when reference size is 8 bytes. Additionally, `ObjectAlignmentInBytes=32` is excessive for new test configs. > > Additional testing: > - [x] Linux x86_64 fastdebug, default, affected test still passes > - [x] Linux x86_32 fastdebug, default, affected test still passes > - [x] Linux x86_64 fastdebug, `-XX:-UseCompressedOops`, affected test now passes Thumbs up. Thanks for fixing this issue so quickly. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7269 From alanb at openjdk.java.net Sun Jan 30 16:10:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 30 Jan 2022 16:10:07 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote: > `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. > > The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From brian.goetz at oracle.com Sun Jan 30 17:00:51 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 30 Jan 2022 12:00:51 -0500 Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown In-Reply-To: References: Message-ID: <21584cd5-5d5e-7d05-d224-34c6acadaa69@oracle.com> Are you proposing dropping SIZED from the spliterator for arrays?? This would undermine all the array-based optimizations (e.g., toArray), which seems a bad trade.? I realize the splitting heuristics are frustrating for a number of use cases, but this seems like throwing the baby out with the bathwater. (Loom is coming, and that is a good time to revisit streams support for blocking operations, which is a big part of what people complain about with parallel streams.) On 1/29/2022 11:38 AM, Tagir F.Valeev wrote: > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. > > I added a simple test to ensure that at least two threads are actually used when parallelizing Stream.iterate source. More testing ideas are welcome. > > ------------- > > Commit messages: > - JDK-8280915 Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown > > Changes:https://git.openjdk.java.net/jdk/pull/7279/files > Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=00 > Issue:https://bugs.openjdk.java.net/browse/JDK-8280915 > Stats: 128 lines in 2 files changed: 96 ins; 0 del; 32 mod > Patch:https://git.openjdk.java.net/jdk/pull/7279.diff > Fetch: git fetchhttps://git.openjdk.java.net/jdk pull/7279/head:pull/7279 > > PR:https://git.openjdk.java.net/jdk/pull/7279 From dholmes at openjdk.java.net Sun Jan 30 22:02:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 30 Jan 2022 22:02:12 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote: > `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. > > The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 260: > 258: *

    If this method is invoked by JNI code > 259: * with no caller class on the stack, the {@code accessible} flag can > 260: * only set if the member and the declaring class are public, and s/only set/only be set/ ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From dholmes at openjdk.java.net Sun Jan 30 22:09:09 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 30 Jan 2022 22:09:09 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote: > `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. > > The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. Hi Mandy, There is no spec change here as you note, but the behavioural change also makes this warrant a CSR request IMO. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From amaembo at gmail.com Mon Jan 31 02:13:08 2022 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 31 Jan 2022 09:13:08 +0700 Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown In-Reply-To: <21584cd5-5d5e-7d05-d224-34c6acadaa69@oracle.com> References: <21584cd5-5d5e-7d05-d224-34c6acadaa69@oracle.com> Message-ID: Hello, Brian! On Mon, Jan 31, 2022 at 12:01 AM Brian Goetz wrote: > > Are you proposing dropping SIZED from the spliterator for arrays? This would undermine all the array-based optimizations (e.g., toArray), which seems a bad trade. I realize the splitting heuristics are frustrating for a number of use cases, but this seems like throwing the baby out with the bathwater. No, c'mon, I would never do this. Moreover, this behavior is covered by dozens of tests. As you can see, my change doesn't break any of the existing tests. What I'm proposing is dropping SIZED from the very-very specific arrays that are chopped out of iterators/spliterators of unknown size. Nothing else is affected. For this particular case, SIZED-ness of arrays is never used. When a top-level spliterator is neither SIZED, nor SUBSIZED (its size is completely unknown), the fact that some subspliterators are SIZED never helped to perform any optimization. We remove SIZED only in this case. So it's not a bad trade and not throwing the baby out with the bathwater. > are frustrating for a number of use cases It's quite a common use case, and people actually complain. For example: https://stackoverflow.com/q/62653471/4856258 - here a topic starter stumbled upon this problem. The answer was to specify the size explicitly but it's also possible that size is not known in advance https://youtrack.jetbrains.com/issue/IDEA-287488 - here user complains that replacing IntStream.iterate(seed, update).takeWhile(condition) with a seemingly equivalent IntStream.iterate(seed, condition, update) undermines the parallelism. We could handle this at IntelliJ IDEA side but an inspection like "Using shorter and simpler iterate() instead of seemingly equivalent iterate().takeWhile() undermines the parallelism" does not sound great and it covers only iterate() source. With best regards, Tagir Valeev. > > (Loom is coming, and that is a good time to revisit streams support for blocking operations, which is a big part of what people complain about with parallel streams.) > > On 1/29/2022 11:38 AM, Tagir F.Valeev wrote: > > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. > > I added a simple test to ensure that at least two threads are actually used when parallelizing Stream.iterate source. More testing ideas are welcome. > > ------------- > > Commit messages: > - JDK-8280915 Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown > > Changes: https://git.openjdk.java.net/jdk/pull/7279/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8280915 > Stats: 128 lines in 2 files changed: 96 ins; 0 del; 32 mod > Patch: https://git.openjdk.java.net/jdk/pull/7279.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/7279/head:pull/7279 > > PR: https://git.openjdk.java.net/jdk/pull/7279 > > From alanb at openjdk.java.net Mon Jan 31 07:33:09 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 31 Jan 2022 07:33:09 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: <5oq08wJ2rvtNUr3257NdldJ9Td-LFJrAkA1qYyw79Lw=.6c8d95b7-6596-4ff9-9413-82c37638f935@github.com> On Sun, 30 Jan 2022 22:06:20 GMT, David Holmes wrote: > There is no spec change here as you note, but the behavioural change also makes this warrant a CSR request IMO. It's in draft: https://bugs.openjdk.java.net/browse/JDK-8280831, I assume Mandy will finalize shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From dholmes at openjdk.java.net Mon Jan 31 07:46:14 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 Jan 2022 07:46:14 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote: > `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. > > The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. Apologies as I somehow missed the CSR info above. ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From shade at openjdk.java.net Mon Jan 31 08:53:10 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 31 Jan 2022 08:53:10 GMT Subject: RFR: 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote: > Recent test regression after adding new cases in the test. Without compressed oops, ~1G elements `Object[]` array takes >8G of memory, which fails the test. The fix cuts it down to 512M when reference size is 8 bytes. Additionally, `ObjectAlignmentInBytes=32` is excessive for new test configs. > > Additional testing: > - [x] Linux x86_64 fastdebug, default, affected test still passes > - [x] Linux x86_32 fastdebug, default, affected test still passes > - [x] Linux x86_64 fastdebug, `-XX:-UseCompressedOops`, affected test now passes Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7269 From shade at openjdk.java.net Mon Jan 31 08:53:10 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 31 Jan 2022 08:53:10 GMT Subject: Integrated: 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote: > Recent test regression after adding new cases in the test. Without compressed oops, ~1G elements `Object[]` array takes >8G of memory, which fails the test. The fix cuts it down to 512M when reference size is 8 bytes. Additionally, `ObjectAlignmentInBytes=32` is excessive for new test configs. > > Additional testing: > - [x] Linux x86_64 fastdebug, default, affected test still passes > - [x] Linux x86_32 fastdebug, default, affected test still passes > - [x] Linux x86_64 fastdebug, `-XX:-UseCompressedOops`, affected test now passes This pull request has now been integrated. Changeset: 251351f4 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/251351f49498ea39150b38860b8f73232fbaf05d Stats: 10 lines in 1 file changed: 1 ins; 3 del; 6 mod 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops Reviewed-by: sspitsyn, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/7269 From Alan.Bateman at oracle.com Mon Jan 31 10:39:22 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 31 Jan 2022 10:39:22 +0000 Subject: Fix proposal for bug JDK-8221642 In-Reply-To: References: <56902d1a-2683-3097-436a-ded5838f4620@oracle.com> Message-ID: On 31/01/2022 09:21, Andreas Rosenberg wrote: > Hi Mandy, > > thanks for your comments. Yes, the correct solution is to examine each caller sensitive method. Surely my idea is not > perfect, as the problem with the ResourceBundle and the bootstrap loader shows. I had the hope that cases like this > could be solved by implementing a "proxy module object" that could define the correct behavior for such cases (e.g. the > correct class loader). As far as I understood, the #getModule() call could be used for this. > At least the class loader issue could probably be solved this way, just as an idea. I'm not very familiar with all the aspects > of module usage, but this way you had at least a kind of definition in Java, how native code should be seen > regarding module usage. > > My search for "@CallerSensitive" gave me 149 hits in java files, so this is quite a task to examine all. My fear is that > we my run into another exception in a few month and the fixes for such problems will not arrive in a few days and > we are facing the same problem again. So a global solution would be preferable. Of course you are worried about > strange side effects or maybe even security /safety issues, but my hope was that somebody here had the expertise > to give a good estimation on this. > > Regarding permissions: if you don't have any Java stack frames on the stack, that means a native application is using > Java code as a kind of library (e.g. we use it to read/write MS Excel via Apache POI). In such cases the native app > must care about that. I could imagine, that there could be use cases that the native app wants to limit permissions > for a certain Java component (e.g. a WebView that may load data from external sites). In such cases you must > define permissions for the component, but this should work as soon as there is at least one additional Java stack > frame on the stack. Right? Moving this to core-libs-dev as that is where most of the @CS methods are. There are about 25 API classes in java.base that have @CS methods, most of these are reflection or related. So I don't think it's too bad. A good starting point out would be a test (maybe based on the existing exeCallerAccessTest) to make it easy to exercise each of these methods to check their behavior. As Mandy pointed out, there are for implications for access control and security to have an intermediate frame that reports its class in java.base and is full privileged so care is required. An intermediate frame of a class generated into an unnamed module may be an alternative to explore as that would limit access to public members of public classes that are in packages exported unconditionally. -Alan From mchung at openjdk.java.net Mon Jan 31 17:55:54 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 31 Jan 2022 17:55:54 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack [v2] In-Reply-To: References: Message-ID: > `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. > > The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7271/files - new: https://git.openjdk.java.net/jdk/pull/7271/files/0f57385d..eb5efab4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7271&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7271&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7271/head:pull/7271 PR: https://git.openjdk.java.net/jdk/pull/7271 From mchung at openjdk.java.net Mon Jan 31 17:55:56 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 31 Jan 2022 17:55:56 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack [v2] In-Reply-To: References: Message-ID: On Sun, 30 Jan 2022 21:59:19 GMT, David Holmes wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo > > src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 260: > >> 258: *

    If this method is invoked by JNI code >> 259: * with no caller class on the stack, the {@code accessible} flag can >> 260: * only set if the member and the declaring class are public, and > > s/only set/only be set/ Thanks for catching this. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From mchung at openjdk.java.net Mon Jan 31 17:57:28 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 31 Jan 2022 17:57:28 GMT Subject: RFR: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote: > `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. > > The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. Right, I have the CSR to cover the behavioral change. I called out the spec change in this patch is a spec clarification as this fix can be considered to backport without the spec change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From rriggs at openjdk.java.net Mon Jan 31 20:01:39 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 31 Jan 2022 20:01:39 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled [v2] In-Reply-To: References: Message-ID: > During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces > `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. > If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. > When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility > between the classloaders of the source of the serialized stream and the classloader being used for deserialization. > When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch > the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. > This allows the application to handle the exception consistently with other errors during deserialization. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Review feedback recommends using InvalidClassException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7274/files - new: https://git.openjdk.java.net/jdk/pull/7274/files/7c8ba46a..23240feb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7274&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7274&range=00-01 Stats: 9 lines in 2 files changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7274/head:pull/7274 PR: https://git.openjdk.java.net/jdk/pull/7274 From mchung at openjdk.java.net Mon Jan 31 21:32:10 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 31 Jan 2022 21:32:10 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jan 2022 20:01:39 GMT, Roger Riggs wrote: >> During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces >> `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. >> If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. >> When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility >> between the classloaders of the source of the serialized stream and the classloader being used for deserialization. >> When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch >> the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. >> This allows the application to handle the exception consistently with other errors during deserialization. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback recommends using InvalidClassException LGTM ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7274 From rriggs at openjdk.java.net Mon Jan 31 21:32:10 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 31 Jan 2022 21:32:10 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jan 2022 20:01:39 GMT, Roger Riggs wrote: >> During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces >> `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. >> If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. >> When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility >> between the classloaders of the source of the serialized stream and the classloader being used for deserialization. >> When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch >> the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. >> This allows the application to handle the exception consistently with other errors during deserialization. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback recommends using InvalidClassException The CSR has been updated to reflect the use of InvalidClassException, please review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7274 From naoto at openjdk.java.net Mon Jan 31 22:26:12 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 31 Jan 2022 22:26:12 GMT Subject: RFR: 8280642: IllegalAccessError thrown by ObjectInputStream.resolveProxyClass is not handled [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jan 2022 20:01:39 GMT, Roger Riggs wrote: >> During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces >> `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. >> If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. >> When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility >> between the classloaders of the source of the serialized stream and the classloader being used for deserialization. >> When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch >> the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. >> This allows the application to handle the exception consistently with other errors during deserialization. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback recommends using InvalidClassException Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7274 From darcy at openjdk.java.net Mon Jan 31 22:37:31 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 31 Jan 2022 22:37:31 GMT Subject: RFR: JDK-8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix Message-ID: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> The original fix to JDK-8280550 contained a typo where r rather than bound was used as the first argument to nextAfter; this PR corrects that issue. ------------- Commit messages: - JDK-8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix Changes: https://git.openjdk.java.net/jdk/pull/7292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280950 Stats: 41 lines in 2 files changed: 39 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7292/head:pull/7292 PR: https://git.openjdk.java.net/jdk/pull/7292 From bpb at openjdk.java.net Mon Jan 31 23:05:07 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 31 Jan 2022 23:05:07 GMT Subject: RFR: JDK-8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix In-Reply-To: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> References: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> Message-ID: On Mon, 31 Jan 2022 22:31:03 GMT, Joe Darcy wrote: > The original fix to JDK-8280550 contained a typo where r rather than bound was used as the first argument to nextAfter; this PR corrects that issue. Looks all right modulo the copyright year. test/jdk/java/util/Random/RandomNextDoubleBoundary.java line 71: > 69: RandomGenerator rg = new RandomGenerator() { > 70: @Override > 71: public double nextDouble() { Bad indentation. test/jdk/java/util/Random/RandomNextDoubleBoundary.java line 76: > 74: > 75: @Override > 76: public long nextLong() { Bad indentation. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7292 From darcy at openjdk.java.net Mon Jan 31 23:12:57 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 31 Jan 2022 23:12:57 GMT Subject: RFR: JDK-8280534: Enable compile-time doclint reference checking [v3] In-Reply-To: References: Message-ID: > The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. > > Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). > > One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8280534 - Use capabilities of JDK-8280744. - Merge branch 'master' into JDK-8280534 - Cover java.base. - JDK-8280534: Enable compile-time doclint reference checking ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7237/files - new: https://git.openjdk.java.net/jdk/pull/7237/files/d03401c6..a0b37495 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7237&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7237&range=01-02 Stats: 1473 lines in 53 files changed: 585 ins; 557 del; 331 mod Patch: https://git.openjdk.java.net/jdk/pull/7237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7237/head:pull/7237 PR: https://git.openjdk.java.net/jdk/pull/7237 From jlaskey at openjdk.java.net Mon Jan 31 23:19:08 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 31 Jan 2022 23:19:08 GMT Subject: RFR: JDK-8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix In-Reply-To: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> References: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> Message-ID: On Mon, 31 Jan 2022 22:31:03 GMT, Joe Darcy wrote: > The original fix to JDK-8280550 contained a typo where r rather than bound was used as the first argument to nextAfter; this PR corrects that issue. LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7292 From darcy at openjdk.java.net Mon Jan 31 23:26:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 31 Jan 2022 23:26:10 GMT Subject: Integrated: JDK-8280534: Enable compile-time doclint reference checking In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote: > The changes in this PR on top of the out-for-review changes in https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint checking to be enabled in all JDK modules. > > Typically, a @SuppressWarnings("doclint:refernce") annotation is added to declaration with javadoc blocks that have already had distinguished cross-module links added (JDK-8280492). > > One exception is in src/java.base/share/classes/java/net/package-info.java where the cross-module link was (for now) removed. Currently the SuppressWarnings annotation type is not declared to allow its annotations to be applied to package declarations. I'll look into amending that, but in the mean time, I think it is beneficial for the JDK build, and the base module in particular, to have compile-time doclint protections turned on. This pull request has now been integrated. Changeset: 4dbebb62 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/4dbebb62aa264adda8d96a06f608ef9d13155a26 Stats: 28 lines in 21 files changed: 21 ins; 0 del; 7 mod 8280534: Enable compile-time doclint reference checking Reviewed-by: serb, naoto, mchung, lancea, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7237