Integrated: JDK-8278953: Clarify Class.getDeclaredConstructor specification
On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy wrote: > Cleanup and regularization of the specs of the four > get[Declared]Constructor[s] methods. This pull request has now been integrated. Changeset: 51796728 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/517967284cf607c0137e088a33ab5eb98d59542d Stats: 20 lines in 1 file changed: 11 ins; 4 del; 5 mod 8278953: Clarify Class.getDeclaredConstructor specification Reviewed-by: mchung, alanb - PR: https://git.openjdk.java.net/jdk/pull/6897
Re: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor specification
On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy wrote: > Cleanup and regularization of the specs of the four > get[Declared]Constructor[s] methods. CSR filed and approved: https://bugs.openjdk.java.net/browse/JDK-8279046 - PR: https://git.openjdk.java.net/jdk/pull/6897
Re: [jdk18] RFR: JDK-8278967 rmiregistry fails to start because SecurityManager is disabled
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks wrote: > Enable the security manager in rmiregistry's launcher arguments. I think there's little to worry about with custom configurations of the `rmiregistry` tool. What somebody might do is to enable a customized security manager using properties... of course they'd also have to ensure that the customized SM is somewhere in the classpath as well, by adding more command line options. That seems fairly unlikely to me. Anyone who wants to run an RMI registry service in some specialized configuration would probably just set things up themselves and then use the `LocateRegistry.createRegistry` API instead of trying to tinker with the `rmiregistry` command. If `rmiregistry` enables the SM using properties, then yes we can probably change the code to assert that the SM is running instead of conditionally enabling it like it does now. Next headache is that `tools/launcher/VersionCheck.jtr` fails because it sees the warning messages instead of the version string. (Argh!) Interestingly this test passes even though `rmiregistry` currently fails to operate normally, because it runs well enough to print its version string, but not well enough to start up a registry service. (Double argh!) The warnings policy is a separate issue being discussed elsewhere. - PR: https://git.openjdk.java.net/jdk18/pull/45
Re: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor specification
On Mon, 20 Dec 2021 20:48:35 GMT, Alan Bateman wrote: > This looks okay, just wondering if expanded NoSuchMethodException description > warrants a CSR. Hmm. I don't think a CSR is strictly necessary as the additional conditions are arguably implied by the rest of the spec, but I can run a quick CSR for this. I have not written new regression tests for this fix, but quickly checked in jshell that the expected exceptions are indeed thrown. - PR: https://git.openjdk.java.net/jdk/pull/6897
Re: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor specification
On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy wrote: > Cleanup and regularization of the specs of the four > get[Declared]Constructor[s] methods. This looks okay, just wondering if expanded NoSuchMethodException description warrants a CSR. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6897
Re: RFR: JDK-8278953: Clarify Class.getDeclaredConstructor specification
On Mon, 20 Dec 2021 18:23:46 GMT, Joe Darcy wrote: > Cleanup and regularization of the specs of the four > get[Declared]Constructor[s] methods. LGTM - Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6897
RFR: JDK-8278953: Clarify Class.getDeclaredConstructor specification
Cleanup and regularization of the specs of the four get[Declared]Constructor[s] methods. - Commit messages: - JDK-8278953: Clarify Class.getDeclaredConstructor specification Changes: https://git.openjdk.java.net/jdk/pull/6897/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6897&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278953 Stats: 20 lines in 1 file changed: 11 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6897.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6897/head:pull/6897 PR: https://git.openjdk.java.net/jdk/pull/6897
Re: RFR: JDK-8276302: Locale.filterTags methods ignore actual weight when matching "*" (as if it is 1)
On Fri, 10 Dec 2021 00:02:31 GMT, Daniel Le wrote:
> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
>
> Fix the bug and add regression test cases for it as well as existing
> behavior.
Thanks for the fix. Looks good overall. Some minor comments follow. Also for
the test case,
- add the bug id `8276302` to the `@bug` tag.
- modify the copyright year to 2021.
src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 131:
> 129:
> 130: if (!caseInsensitiveMatch(list, lowerCaseTag)
> 131: && !shouldIgnoreFilterBasicMatch(zeroRanges,
> lowerCaseTag)) {
Is there any reason to flip the evaluation order of the `if` statement?
src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 157:
> 155: * returning all the tags, remove those which are matching the range
> with
> 156: * quality weight q=0.
> 157: */
Please keep the comments in the modified code (except the `*` part). Although
it's OK to remove this method as it eliminates extra `ArrayList` allocation,
please keep the comments in the modified code (except the `*` part).
src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 161:
> 159: List zeroRange, Collection tags) {
> 160: if (zeroRange.isEmpty()) {
> 161: tags = removeDuplicates(tags);
Can `removeDuplicates()` now be removed? There seems to be no usage.
src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 167:
> 165: List matchingTags = new ArrayList<>();
> 166: for (String tag : tags) {
> 167: // change to lowercase for case-insensitive matching
Applies to this comment.
src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 171:
> 169: if (!shouldIgnoreFilterBasicMatch(zeroRange, lowerCaseTag)
> 170: && !caseInsensitiveMatch(matchingTags,
> lowerCaseTag)) {
> 171: matchingTags.add(tag); // preserving the case of the
> input tag
And this comment, too.
-
PR: https://git.openjdk.java.net/jdk/pull/6789
Re: possible bug in jdeps as ToolProvider
Yes this bug is known and tracked by JDK-8277681. The proper solution
should make each JdepsTask to maintain its own map of multi-versioned
entries rather than a global nameToVersion map for the running VM as
described in
JDK-8277681.
Mandy
On 12/18/21 7:47 PM, Raymond Augé wrote:
Hello everyone,
At Alan's request [3] I'm posting this here. Alan mentions this is likely a
manifestation of JDK-8277681 [4]. From the description I would agree.
Here is a copy of the original message for posterity.
---
I believe I have found a small bug in jdeps tool when used as ToolProvider.
I am invoking the jdeps impl via the ToolProvider API as follows (this code
is also available here [2]):
try (final StringWriter stdout = new StringWriter();
final StringWriter stderr = new StringWriter();
final PrintWriter pwout = new PrintWriter(stdout);
final PrintWriter pwerr = new PrintWriter(stderr)) {
return (ToolProvider.findFirst("jdeps").orElseThrow().run(pwout, pwerr,
args) == 0) ?
stdout.toString() :
"Error: ".concat(stderr.toString());
}
catch (Throwable t) {
t.printStackTrace();
return "Error: " + t.getMessage();
}
However repeat invocations result in the following exception:
java.lang.Error: java.util.concurrent.ExecutionException:
com.sun.tools.jdeps.MultiReleaseException
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
at
jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
at
jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
[snip]
Caused by: java.util.concurrent.ExecutionException:
com.sun.tools.jdeps.MultiReleaseException
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
... 24 more
Caused by: com.sun.tools.jdeps.MultiReleaseException
at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
at
jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
at
jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
at
jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
In order to get around the error I do the following:
public static final Field field;
public static final Map map;
static {
try {
Class clazz = Class.forName("com.sun.tools.jdeps.VersionHelper");
field = clazz.getDeclaredField("nameToVersion");
field.setAccessible(true);
map = (Map)field.get(null);
}
catch (ReflectiveOperationException e) {
throw new RuntimeException(e);
}
}
and tack a finally to the end of the try above:
finally {
map.clear();
}
Now, additionally to be able to do that, I need to add an `--add-opens`:
--add-opens jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED
I believe the solution is to clear the map in [1] when jdeps finishes.
Finally, I would send a PR myself except I do not (yet) have an OCA and the
solution seems simple enough if someone can confirm that this is indeed a
bug.
Ray
[1]
https://github.com/openjdk/jdk/blob/master/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java
[2]https://gist.github.com/rotty3000/d9feec79a66f14c2360fee9b9a1b2852
[3]
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006291.html
[4]https://bugs.openjdk.java.net/browse/JDK-8277681
RFR: 8273322: Enhance macro logic optimization for masked logic operations.
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.maskedLogicOperationsI
RFR: 8276694: Pattern trailing unescaped backslash causes internal error
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. - Commit messages: - 8276694: Pattern trailing unescaped backslash causes internal error Changes: https://git.openjdk.java.net/jdk/pull/6891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6891&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276694 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6891/head:pull/6891 PR: https://git.openjdk.java.net/jdk/pull/6891
