Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v4]
> During annotation parsing, the parser assumes that a declared property is of > an array type if the parsed annotation property is defined as an array. In > this case, the component type is `null`, and a `NullPointerException` is > thrown. This change discovers the mismatch and throws an > `AnnotationTypeMismatchException`. Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException - Changes: - all: https://git.openjdk.java.net/jdk/pull/3940/files - new: https://git.openjdk.java.net/jdk/pull/3940/files/4e14cbb9..e804eb38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940
Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3]
On Thu, 10 Jun 2021 04:17:37 GMT, David Holmes wrote: >> Rafael Winterhalter has refreshed the contents of this pull request, and >> previous commits have been removed. The incremental views will show >> differences compared to the previous content of the PR. > > test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArityTypeMismatchTest.java > line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > > Copyright year is wrong. Thanks, I corrected the year. - PR: https://git.openjdk.java.net/jdk/pull/3940
Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3]
On Thu, 10 Jun 2021 00:15:24 GMT, Joe Darcy wrote: > Please add an overview to test before integrating; thanks. Sorry, I missed that one. Not sure what you mean by *overview*? - PR: https://git.openjdk.java.net/jdk/pull/3940
Re: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v4]
> If a type is changed from a type that can be a member of an annotation which > is used in an array, changing it to a type that cannot be an array member > will be treated as if the type is an annotation type. As a result, no > exception proxy is created and the type is returned as if it was correctly > defined. Rafael Winterhalter 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 one additional commit since the last revision: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions - Changes: - all: https://git.openjdk.java.net/jdk/pull/3925/files - new: https://git.openjdk.java.net/jdk/pull/3925/files/c812a4c4..b51dafbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=02-03 Stats: 1236 lines in 63 files changed: 823 ins; 166 del; 247 mod Patch: https://git.openjdk.java.net/jdk/pull/3925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3925/head:pull/3925 PR: https://git.openjdk.java.net/jdk/pull/3925
Re: RFR: 8268113: Re-use Long.hashCode() where possible [v7]
> There is a few JDK classes duplicating the contents of Long.hashCode() for > hash code calculation. They should explicitly delegate to Long.hashCode(). Сергей Цыпанов 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: - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - 8268113: Inline local vars where reasonable - 8268113: Delegate to Double.hashCode() - 8268113: Re-use Long.hashCode() where possible - Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/3a7b5515..f1c8cc7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=05-06 Stats: 4631 lines in 103 files changed: 3649 ins; 401 del; 581 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309
RFR: 8267448: Add "ulimit -a" to environment.html
Hi all, could you please review this small patch that does $subj? Thanks, -- Igor attn: @plummercj - Commit messages: - 8267448 Changes: https://git.openjdk.java.net/jdk/pull/4451/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4451&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267448 Stats: 15 lines in 3 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4451.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4451/head:pull/4451 PR: https://git.openjdk.java.net/jdk/pull/4451
Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v5]
> During annotation parsing, the parser assumes that a declared property is of > an array type if the parsed annotation property is defined as an array. In > this case, the component type is `null`, and a `NullPointerException` is > thrown. This change discovers the mismatch and throws an > `AnnotationTypeMismatchException`. Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions - Changes: https://git.openjdk.java.net/jdk/pull/3940/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=04 Stats: 242 lines in 3 files changed: 240 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940
Re: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v3]
On Wed, 9 Jun 2021 23:59:45 GMT, Joe Darcy wrote: > To aid future maintainers, please add a short summary comment with an outline > of what the test is doing before integrating. I added a comment to the test to explain what is done in it. - PR: https://git.openjdk.java.net/jdk/pull/3925
Re: RFR: 8268124: Update java.lang to use switch expressions [v6]
> Hi, > > Could someone please review my code for updating the code in the `java.lang` > packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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: - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: moved cases into separate lines in DirectMethodHandleDescImpl part II - 8268124: moved cases onto separate lines in DirectMethodHandleDescImpl - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: small refactoring; fixed misplaced comment and added missing lambda operator - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: Update java.lang to use switch expressions - Changes: - all: https://git.openjdk.java.net/jdk/pull/4312/files - new: https://git.openjdk.java.net/jdk/pull/4312/files/df5b34e5..c7c11939 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=04-05 Stats: 4673 lines in 106 files changed: 3649 ins; 412 del; 612 mod Patch: https://git.openjdk.java.net/jdk/pull/4312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4312/head:pull/4312 PR: https://git.openjdk.java.net/jdk/pull/4312
Integrated: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled
On Mon, 7 Jun 2021 16:38:01 GMT, Jorn Vernee wrote: > Hi, > > ~This is part 2 of a two part upstreaming process of the patch mentioned in > the subject line. The patch was split into 2 in order to document 2 separate > specification changes that arose from a change in the implementation, with 2 > separate CSRs. The first patch can be found here: > https://github.com/openjdk/jdk/pull/4395~ > > This patch adds uniform exception handling for exceptions thrown during FLA > upcalls. Currently, these exceptions are either handled similarly to the VMs > `CATCH` macro, or ignored after which control returns to unsuspecting native > code, until control returns to Java, which will then handle the exception. > The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and > instead the VM exits with a fatal error. The latter is bad because an upcall > completing abruptly and returning to native code which has no idea an > exception occurred is unsafe, in the sense that invariants about the state of > the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases > (see `SharedUtils::handleUncaughtException`), which prints the exception > stack trace, and then unconditionally exits the VM, which is the only safe > course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall > itself, for instance by translating the exception into an error code that is > then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: > https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn This pull request has now been integrated. Changeset: ab01cb54 Author:Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/ab01cb547dd87f76017e9b079ab68495c38ffc90 Stats: 229 lines in 8 files changed: 224 ins; 0 del; 5 mod 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled Reviewed-by: psandoz, mcimadamore - PR: https://git.openjdk.java.net/jdk/pull/4396
Re: RFR: 8268469: Update java.time to use switch expressions [v2]
> Hi, > > Could someone please review my code for updating the code in the `java.time` > packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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 remote-tracking branch 'origin/master' into JDK-8268469 - 8268469: Update java.time to use switch expressions - Changes: - all: https://git.openjdk.java.net/jdk/pull/4433/files - new: https://git.openjdk.java.net/jdk/pull/4433/files/e6d76af2..2abbea11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=00-01 Stats: 1167 lines in 61 files changed: 779 ins; 153 del; 235 mod Patch: https://git.openjdk.java.net/jdk/pull/4433.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4433/head:pull/4433 PR: https://git.openjdk.java.net/jdk/pull/4433
Re: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled [v5]
On Tue, 8 Jun 2021 19:25:36 GMT, Paul Sandoz wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Suggest try/catch Throwable in upcallStub javadoc > > test/jdk/java/foreign/TestUpcallException.java line 70: > >> 68: Process process = new ProcessBuilder() >> 69: .command( >> 70: Paths.get(Utils.TEST_JDK) > > You might find `jdk.test.lib.JDKToolLauncher` useful. Thanks for the suggestion (forgot to reply earlier). I think I copied the current way to find `java` from another test. I'll look at using JDKToolLauncher next time. - PR: https://git.openjdk.java.net/jdk/pull/4396
Re: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available
On Thu, 22 Apr 2021 14:07:20 GMT, Сергей Цыпанов
wrote:
> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found
> out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like
> `baseName.replace('.', '/') + '/' + name` are not compiled into
> `invokedynamic`-based code, but into one using `StringBuilder`. This happens
> due to some bootstraping issues.
>
> However the code like
>
> private String getSimpleName0() {
> if (isArray()) {
> return getComponentType().getSimpleName() + "[]";
> }
> //...
> }
>
> can be improved via replacement of `+` with `String.concat()` call.
>
> I've used this benchmark to measure impact:
>
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
> private final Class arrayClass = Object[].class;
> private Method descriptorString;
>
> @Setup
> public void setUp() throws NoSuchMethodException {
> //fore some reason compiler doesn't allow me to call
> Class.descriptorString() directly
> descriptorString = Class.class.getDeclaredMethod("descriptorString");
> }
>
> @Benchmark
> public Object descriptorString() throws Exception {
> return descriptorString.invoke(arrayClass);
> }
>
> @Benchmark
> public Object typeName() {
> return arrayClass.getTypeName();
> }
> }
>
> and got those results
>
>Mode Cnt Score
> Error Units
> descriptorString avgt 6091.480 ±
> 1.839 ns/op
> descriptorString:·gc.alloc.rate.norm avgt 60 404.008 ±
> 4.033B/op
> descriptorString:·gc.churn.G1_Eden_Space avgt 60 2791.866 ±
> 181.589 MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 401.702 ±
> 26.047B/op
> descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻³
> B/op
> descriptorString:·gc.count avgt 60 205.000
> counts
> descriptorString:·gc.time avgt 60 216.000
> ms
>
> patched
>Mode Cnt Score
> Error Units
> descriptorString avgt 6065.016 ±
> 3.446 ns/op
> descriptorString:·gc.alloc.rateavgt 60 2844.240 ±
> 115.719 MB/sec
> descriptorString:·gc.alloc.rate.norm avgt 60 288.006 ±
> 0.001B/op
> descriptorString:·gc.churn.G1_Eden_Space avgt 60 2832.996 ±
> 206.939 MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 286.955 ±
> 17.853B/op
> descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻³
> B/op
> descriptorString:·gc.count avgt 60 208.000
> counts
> descriptorString:·gc.time avgt 60 228.000
> ms
> -
> typeName avgt 6034.273 ±
> 0.480 ns/op
> typeName:·gc.alloc.rateavgt 60 3265.356 ±
> 45.113 MB/sec
> typeName:·gc.alloc.rate.norm avgt 60 176.004 ±
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space avgt 60 3268.454 ±
> 134.458 MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm avgt 60 176.109 ±
> 6.595B/op
> typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻⁴
> B/op
> typeName:·gc.count avgt 60 240.000
> counts
> typeName:·gc.time avgt 60 255.000
> ms
>
> patched
>
> typeName avgt 6015.787 ±
> 0.214 ns/op
> typeName:·gc.alloc.rateavgt 60 2577.554 ±
> 32.339 MB/sec
> typeName:·gc.alloc.rate.norm avgt 6064.001 ±
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space avgt 60 2574.039 ±
> 147.774 MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm avgt 6063.895 ±
> 3.511B/op
> typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻⁴
> B/op
> typeName:·gc.count avgt 60 189.000
> counts
> typeName:·gc.time avgt 60 199.000
>
Re: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v4]
On Thu, 10 Jun 2021 08:29:46 GMT, Rafael Winterhalter wrote: >> If a type is changed from a type that can be a member of an annotation which >> is used in an array, changing it to a type that cannot be an array member >> will be treated as if the type is an annotation type. As a result, no >> exception proxy is created and the type is returned as if it was correctly >> defined. > > Rafael Winterhalter has updated the pull request with a new target base due > to a merge or a rebase. The pull request now contains one commit: > > 8266766: Arrays of types that cannot be an annotation member do not yield > exceptions Marked as reviewed by jfranck (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3925
Re: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available [v2]
> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found
> out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like
> `baseName.replace('.', '/') + '/' + name` are not compiled into
> `invokedynamic`-based code, but into one using `StringBuilder`. This happens
> due to some bootstraping issues.
>
> However the code like
>
> private String getSimpleName0() {
> if (isArray()) {
> return getComponentType().getSimpleName() + "[]";
> }
> //...
> }
>
> can be improved via replacement of `+` with `String.concat()` call.
>
> I've used this benchmark to measure impact:
>
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
> private final Class arrayClass = Object[].class;
> private Method descriptorString;
>
> @Setup
> public void setUp() throws NoSuchMethodException {
> //fore some reason compiler doesn't allow me to call
> Class.descriptorString() directly
> descriptorString = Class.class.getDeclaredMethod("descriptorString");
> }
>
> @Benchmark
> public Object descriptorString() throws Exception {
> return descriptorString.invoke(arrayClass);
> }
>
> @Benchmark
> public Object typeName() {
> return arrayClass.getTypeName();
> }
> }
>
> and got those results
>
>Mode Cnt Score
> Error Units
> descriptorString avgt 6091.480 ±
> 1.839 ns/op
> descriptorString:·gc.alloc.rate.norm avgt 60 404.008 ±
> 4.033B/op
> descriptorString:·gc.churn.G1_Eden_Space avgt 60 2791.866 ±
> 181.589 MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 401.702 ±
> 26.047B/op
> descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻³
> B/op
> descriptorString:·gc.count avgt 60 205.000
> counts
> descriptorString:·gc.time avgt 60 216.000
> ms
>
> patched
>Mode Cnt Score
> Error Units
> descriptorString avgt 6065.016 ±
> 3.446 ns/op
> descriptorString:·gc.alloc.rateavgt 60 2844.240 ±
> 115.719 MB/sec
> descriptorString:·gc.alloc.rate.norm avgt 60 288.006 ±
> 0.001B/op
> descriptorString:·gc.churn.G1_Eden_Space avgt 60 2832.996 ±
> 206.939 MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 286.955 ±
> 17.853B/op
> descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻³
> B/op
> descriptorString:·gc.count avgt 60 208.000
> counts
> descriptorString:·gc.time avgt 60 228.000
> ms
> -
> typeName avgt 6034.273 ±
> 0.480 ns/op
> typeName:·gc.alloc.rateavgt 60 3265.356 ±
> 45.113 MB/sec
> typeName:·gc.alloc.rate.norm avgt 60 176.004 ±
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space avgt 60 3268.454 ±
> 134.458 MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm avgt 60 176.109 ±
> 6.595B/op
> typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻⁴
> B/op
> typeName:·gc.count avgt 60 240.000
> counts
> typeName:·gc.time avgt 60 255.000
> ms
>
> patched
>
> typeName avgt 6015.787 ±
> 0.214 ns/op
> typeName:·gc.alloc.rateavgt 60 2577.554 ±
> 32.339 MB/sec
> typeName:·gc.alloc.rate.norm avgt 6064.001 ±
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space avgt 60 2574.039 ±
> 147.774 MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm avgt 6063.895 ±
> 3.511B/op
> typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻⁴
> B/op
> typeName:·gc.count avgt 60 189.000
> counts
> typeName:·gc.time avgt 60 199.000
> ms
>
> I think this patch is likely to improve reflecti
Windows aarch64 (build debug) constantly fails
Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code I see this message in the log Compiling 2 files for BUILD_JVMTI_TOOLS LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' make[3]: *** [gensrc/GensrcAdlc.gmk:63: /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/hotspot/variant-server/tools/adlc/adlc.exe] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [make/Main.gmk:248: hotspot-server-gensrc] Error 2 ERROR: Build failed for target 'default (hotspot)' in configuration 'windows-aarch64' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_tools_adlc_objs_BUILD_ADLC_link: LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' * All command lines available in /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:315: main] Error 2 make: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:186: default] Error 2 Error: Process completed with exit code 1. Here's the link to particular run https://github.com/stsypanov/jdk/runs/2792324849 What can I do with this? Regards, Sergey Tsypanov
Integrated: 8268124: Update java.lang to use switch expressions
On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` > packages to make use of the switch expressions? > > Kind regards, > Patrick This pull request has now been integrated. Changeset: d43c8a74 Author:Patrick Concannon URL: https://git.openjdk.java.net/jdk/commit/d43c8a74b33692b3628c3c9c6c472ab1cf1fdeac Stats: 558 lines in 22 files changed: 6 ins; 136 del; 416 mod 8268124: Update java.lang to use switch expressions Reviewed-by: naoto, darcy, mchung, iris, lancea, dfuchs - PR: https://git.openjdk.java.net/jdk/pull/4312
Integrated: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions
On Fri, 7 May 2021 18:58:02 GMT, Rafael Winterhalter wrote: > If a type is changed from a type that can be a member of an annotation which > is used in an array, changing it to a type that cannot be an array member > will be treated as if the type is an annotation type. As a result, no > exception proxy is created and the type is returned as if it was correctly > defined. This pull request has now been integrated. Changeset: 09243822 Author:Rafael Winterhalter Committer: Joel Borggrén-Franck URL: https://git.openjdk.java.net/jdk/commit/09243822ebcca611b04f94ece5afba183723cf74 Stats: 143 lines in 2 files changed: 141 ins; 1 del; 1 mod 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Reviewed-by: darcy, jfranck - PR: https://git.openjdk.java.net/jdk/pull/3925
Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v5]
On Thu, 10 Jun 2021 08:36:42 GMT, Rafael Winterhalter wrote: >> During annotation parsing, the parser assumes that a declared property is of >> an array type if the parsed annotation property is defined as an array. In >> this case, the component type is `null`, and a `NullPointerException` is >> thrown. This change discovers the mismatch and throws an >> `AnnotationTypeMismatchException`. > > Rafael Winterhalter has updated the pull request with a new target base due > to a merge or a rebase. The pull request now contains two commits: > > - 8266791: Annotation property which is compiled as an array property but > changed to a single element throws NullPointerException > - 8266766: Arrays of types that cannot be an annotation member do not yield > exceptions Marked as reviewed by jfranck (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3940
Integrated: 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N]
On Wed, 9 Jun 2021 10:33:34 GMT, Maurizio Cimadamore wrote: > This tests fails intermittently but very rarely, on Windows it seems. The > subtest in question is `testLockSharedMultiThread`. This test is spawning a > number of threads, each of which: > > * increments a counter atomically > * acquire scope > * waits some time > * release scope > * decrement counter (in finally block) > > The main test thread tries (while the counter value is > 0) to repeatedly > close the scope, and asserts that if the scope closes successfully, then the > counter value should be exactly zero. > > Looking at the test closely, I realized there's an issue: the order in which > counter is incremented and scope is acquired is wrong. As such it is possible > for counter to be increased, but then for subsequent acquire to fail (e.g. if > segment is already closed). This would lead to the main test thread to fail, > as it would appear as if the segment has been closed successfully, but the > counter value is not zero. > > The fix is to only increment the counter after a successful acquire. I have > also tweaked the test so that it keeps trying closing the scope, even if the > counter value reaches zero permanently (e.g. all other threads have > completed). This pull request has now been integrated. Changeset: f4b31701 Author:Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/f4b3170197ca517b4816f863af053f019ce0f181 Stats: 15 lines in 1 file changed: 6 ins; 3 del; 6 mod 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] Reviewed-by: dfuchs - PR: https://git.openjdk.java.net/jdk/pull/4427
Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v6]
> During annotation parsing, the parser assumes that a declared property is of > an array type if the parsed annotation property is defined as an array. In > this case, the component type is `null`, and a `NullPointerException` is > thrown. This change discovers the mismatch and throws an > `AnnotationTypeMismatchException`. Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException - Changes: https://git.openjdk.java.net/jdk/pull/3940/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=05 Stats: 99 lines in 2 files changed: 99 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940
Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3]
On Thu, 10 Jun 2021 08:11:42 GMT, Rafael Winterhalter wrote: >> Please add an overview to test before integrating; thanks. > >> Please add an overview to test before integrating; thanks. > > Sorry, I missed that one. Not sure what you mean by *overview*? I was not > sure if there's an official tag for something like this but added a > description as a comment. @raphw Please do not force push to your branch after a PR is under review. It makes it difficult for reviewers to see incremental diffs. - PR: https://git.openjdk.java.net/jdk/pull/3940
Re: RFR: 8267630: Start of release updates for JDK 18 [v11]
> 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into 8267630 - Update copyright year. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a95e64cc...51f51814 - Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=10 Stats: 5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175
Re: RFR: 8267630: Start of release updates for JDK 18 [v11]
On Thu, 10 Jun 2021 14:42:24 GMT, Joe Darcy wrote: >> 8267630: Start of release updates for JDK 18 > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into 8267630 > - Update copyright year. > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - ... and 15 more: > https://git.openjdk.java.net/jdk/compare/a95e64cc...51f51814 Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4175
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3]
On Tue, 8 Jun 2021 23:42:13 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing review comments. Adding notes about isMIME parameter for other
>> architectures; clarifying decodeBlock comments.
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 4555:
>
>> 4553: void Assembler::evpmaddubsw(XMMRegister dst, XMMRegister src1,
>> XMMRegister src2, int vector_len) {
>> 4554: assert(VM_Version::supports_avx512bw(), "");
>> 4555: InstructionAttr attributes(vector_len, /* rex_w */ false, /*
>> legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true);
>
> This instruction is also supported on AVX platforms. The assert check could
> be as follows:
> assert(vector_len == AVX_128bit? VM_Version::supports_avx() :
> vector_len == AVX_256bit? VM_Version::supports_avx2() :
> vector_len == AVX_512bit? VM_Version::supports_avx512bw() : 0,
> "");
> Accordingly the instruction could be named as vpmaddubsw.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5688:
>
>> 5686: address base64_vbmi_lookup_lo_addr() {
>> 5687: __ align(64, (unsigned long) __ pc());
>> 5688: StubCodeMark mark(this, "StubRoutines", "lookup_lo");
>
> It will be good to add base64 to the StubCodeMark name for this and all the
> tables.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5983:
>
>> 5981: // calculate length from offsets
>> 5982: __ movq(length, end_offset);
>> 5983: __ subq(length, start_offset);
>
> These are 32bit, so movl, subl instead of movq, subq. Similar for all length
> relates instructions below.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5987:
>
>> 5985:
>> 5986: // If AVX512 VBMI not supported, just compile non-AVX code
>> 5987: if(VM_Version::supports_avx512_vbmi()) {
>
> Need to also check for VM_Version::supports_avx512bw() support.
> Could you please check if VM_Version::supports_avx512dq is needed as well?
Done. No need for avx512dq.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6134:
>
>> 6132: __ subq(length, 64);
>> 6133: __ addq(source, 64);
>> 6134: __ addq(dest, 48);
>
> All address related instructions here and below could use addptr, subptr etc.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6273:
>
>> 6271:
>> 6272: __ shrq(length, 2);// Multiple of 4 bytes only - length is #
>> 4-byte chunks
>> 6273: __ cmpq(length, 0);
>
> Should these be shrl, cmpl?
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6278:
>
>> 6276: // Set up src and dst pointers properly
>> 6277: __ addq(source, start_offset); // Initial offset
>> 6278: __ addq(dest, dp);
>
> The convention is to use addptr for pointers.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6284:
>
>> 6282: __ shll(isURL, 8);// index into decode table based on isURL
>> 6283: __ lea(decode_table,
>> ExternalAddress(StubRoutines::x86::base64_decoding_table_addr()));
>> 6284: __ addq(decode_table, isURL);
>
> addptr here.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6297:
>
>> 6295: __ orl(byte1, byte4);
>> 6296:
>> 6297: __ incrementq(source, 4);
>
> addptr here.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6317:
>
>> 6315: __ load_signed_byte(byte4, Address(source, RegisterOrConstant(),
>> Address::times_1, 3));
>> 6316: __ load_signed_byte(byte3, Address(decode_table, byte3,
>> Address::times_1, 0));
>> 6317: __ load_signed_byte(byte4, Address(decode_table, byte4,
>> Address::times_1, 0));
>
> You could use Address(base, offset) form directly here and other places: e.g.
> Address (source, 1) instead of Address(source, RegisterOrConstant(),
> Address::times_1, 1).
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6329:
>
>> 6327: __ subq(dest, rax); // Number of bytes converted
>> 6328: __ movq(rax, dest);
>> 6329: __ pop(rbx);
>
> subptr, movptr here.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7627:
>
>> 7625: StubRoutines::x86::_right_shift_mask =
>> base64_right_shift_mask_addr();
>> 7626: StubRoutines::_base64_encodeBlock =
>> generate_base64_encodeBlock();
>> 7627: if (VM_Version::supports_avx512_vbmi()) {
>
> Need to add avx512bw check here also.
Done.
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7628:
>
>> 7626: StubRoutines::_base64_encodeBlock =
>> generate_base64_encodeBlock();
>> 7627: if (VM_Version::supports_avx512_vbmi()) {
>> 7628: StubRoutines::x86::_lookup_lo = base64_vbmi_lookup_lo_addr();
>
> It would be good to add base64 to these names.
Done.
-
PR: https://git.openjdk.java.net/jdk/pull/4368
Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v4]
> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. > Also allows for performance improvement for non-AVX-512 enabled platforms. > Due to the nature of MIME-encoded inputs, modify the intrinsic signature to > accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide > the intrinsic information as to whether MIME decoding was being done. This > allows for the intrinsic to bypass the expensive setup of zmm registers from > AVX tables, knowing there may be invalid Base64 characters every 76 > characters or so. A change was also made here removing the restriction that > the intrinsic must return an even multiple of 3 bytes decoded. This > implementation handles the pad characters at the end of the string and will > return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop > iteration, then in chunks of 64 bytes, followed by end fixup decoding. The > non-AVX code is an assembly-optimized version of the java DecodeBlock and > behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance > by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers > are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using > this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 2 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 5 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 2 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 5 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 2 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 5 | 1409.41 | 1114.16 | 1.26 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments. 1. Modified evpmaddubsw. Assert for avx512bw, renamed to vpmaddubsw. 2. Added base64 to StubCodeMark names and associated variables. 3. Added avx512bw check at top of vbmi loop. No need for avx512dq. 4. Fixed all length references (addq=>addl, addq=>addptr, etc.). 5. Converted to Address(base, offset) where appropriate. Compiles, and smoke-tested. - Changes: - all: https://git.openjdk.java.net/jdk/pull/4368/files - new: https://git.openjdk.java.net/jdk/pull/4368/files/d66e32e3..247f2245 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=02-03 Stats: 104 lines in 5 files changed: 4 ins; 0 del; 100 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368
Integrated: 8267630: Start of release updates for JDK 18
On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 This pull request has now been integrated. Changeset: b018c450 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/b018c450e5e4737ccd08ed505fd06cee16c42648 Stats: 5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod 8267630: Start of release updates for JDK 18 8267632: Add source 18 and target 18 to javac 8267631: Add SourceVersion.RELEASE_18 Reviewed-by: iris, erikj, dholmes - PR: https://git.openjdk.java.net/jdk/pull/4175
Withdrawn: 8267448: Add "ulimit -a" to environment.html
On Thu, 10 Jun 2021 06:26:53 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that does $subj? > > Thanks, > -- Igor > > attn: @plummercj This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4451
Re: RFR: 8267448: Add "ulimit -a" to environment.html
On Thu, 10 Jun 2021 06:26:53 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that does $subj? > > Thanks, > -- Igor > > attn: @plummercj closing in favor of openjdk/jdk17#2 - PR: https://git.openjdk.java.net/jdk/pull/4451
Re: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote: > Looks like the test does not verify the cases specified by `valueOf(int > refKind, boolean isInterface)`. > i.e. For most values of refKind, there is an exact match regardless of the > value of isInterface except `REF_invokeStatic` and `REF_invokeSpecial`. > > Do you mind adding those cases? hum, the spec for `valueOf(int refKind, boolean isInterface)` is incorrect, the behavior does depends on the value of `isInterface` for example: `Kind.valueOf(1, false)` returns GETTER while `Kind.valueOf(1, true)` fails with `java.lang.IllegalArgumentException` will fix the implementation of `valueOf(int refKind, boolean isInterface)` for it to match its spec - PR: https://git.openjdk.java.net/jdk/pull/4416
Integrated: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes
On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik wrote: > EFH is improved to process cores and get mixed stack traces with jhsdb and > native stack traces with gdb/lldb. It might be useful because hs_err doesn't > contain info about all threads, sometimes it is even not generated. This pull request has now been integrated. Changeset: 8c8422e0 Author:Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/8c8422e0f8886d9bbfca29fd228368f88bf46f2c Stats: 159 lines in 12 files changed: 130 ins; 7 del; 22 mod 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes Reviewed-by: iignatyev - PR: https://git.openjdk.java.net/jdk/pull/4234
Re: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]
> Please review this PR which is just syncing the implementation of > DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the > method's spec is that if the value of the `refKind` parameter is: > MethodHandleInfo.REF_invokeInterface, then > DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a > value of `true` for its second argument, currently it is invoked with `false` > regardless of the value of the `refKind` parameter > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/4416/files - new: https://git.openjdk.java.net/jdk/pull/4416/files/ea47769d..a5e1c8e5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4416&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4416&range=00-01 Stats: 19 lines in 2 files changed: 16 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4416/head:pull/4416 PR: https://git.openjdk.java.net/jdk/pull/4416
Re: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressing review changes
>
> test/jdk/java/lang/constant/MethodHandleDescTest.java line 362:
>
>> 360: public void testKind() {
>> 361: for (Kind k : Kind.values()) {
>> 362: assertEquals(Kind.valueOf(k.refKind),
>> Kind.valueOf(k.refKind, k.refKind == MethodHandleInfo.REF_invokeInterface));
>
> Looks like the test does not verify the cases specified by `valueOf(int
> refKind, boolean isInterface)`.
> i.e. For most values of refKind, there is an exact match regardless of the
> value of isInterface except `REF_invokeStatic` and `REF_invokeSpecial`.
>
> Do you mind adding those cases?
@mlchung I have updated the PR with another commit, thanks for your comments
-
PR: https://git.openjdk.java.net/jdk/pull/4416
Withdrawn: 8268349: Provide more detail in JEP 411 warning messages
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either > enabled at startup or installed at runtime. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4400
Re: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]
On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote:
>> Please review this PR which is just syncing the implementation of
>> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
>> method's spec is that if the value of the `refKind` parameter is:
>> MethodHandleInfo.REF_invokeInterface, then
>> DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a
>> value of `true` for its second argument, currently it is invoked with
>> `false` regardless of the value of the `refKind` parameter
>>
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional
> commit since the last revision:
>
> addressing review changes
src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java line
143:
> 141: }
> 142: if (kind.refKind == refKind &&
> 143: (refKind != REF_invokeStatic || refKind !=
> REF_invokeSpecial || kind.isInterface == isInterface)){
It reads to me that the static initializer tries to set up the table such that
`valueOf(refKind, isInterface)` should find the proper kind to return except
this:
// There is not a specific Kind for interfaces
if (kind == VIRTUAL) kind = INTERFACE_VIRTUAL;
This changes the entry for `REF_invokeVirtual` to kind `INTERFACE_VIRTUAL`. Do
you know why?If this entry is set to VIRTUAL, then each refKind has two
entries in the table corresponding to the correct result for `valueOf`.
-
PR: https://git.openjdk.java.net/jdk/pull/4416
Re: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]
On Thu, 10 Jun 2021 23:23:23 GMT, Vicente Romero wrote:
>> test/jdk/java/lang/constant/MethodHandleDescTest.java line 362:
>>
>>> 360: public void testKind() {
>>> 361: for (Kind k : Kind.values()) {
>>> 362: assertEquals(Kind.valueOf(k.refKind),
>>> Kind.valueOf(k.refKind, k.refKind == MethodHandleInfo.REF_invokeInterface));
>>
>> Looks like the test does not verify the cases specified by `valueOf(int
>> refKind, boolean isInterface)`.
>> i.e. For most values of refKind, there is an exact match regardless of the
>> value of isInterface except `REF_invokeStatic` and `REF_invokeSpecial`.
>>
>> Do you mind adding those cases?
>
> @mlchung I have updated the PR with another commit, thanks for your comments
It may be better to create a new JBS issue to fix this bug as it may take more
time to investigate.
-
PR: https://git.openjdk.java.net/jdk/pull/4416
Re: Windows aarch64 (build debug) constantly fails
Hi, On 10/06/2021 8:58 pm, Сергей Цыпанов wrote: Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code I see this message in the log Compiling 2 files for BUILD_JVMTI_TOOLS LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' Yes this has been failing in Github actions for some time now. It appears to be a misconfigured Visual Studio installation. However there seems to be no way to report a problem in this regard so we seem to be stuck unless someone knows how to bring such issues to the attention of the Github support team ? Cheers, David - make[3]: *** [gensrc/GensrcAdlc.gmk:63: /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/hotspot/variant-server/tools/adlc/adlc.exe] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [make/Main.gmk:248: hotspot-server-gensrc] Error 2 ERROR: Build failed for target 'default (hotspot)' in configuration 'windows-aarch64' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_tools_adlc_objs_BUILD_ADLC_link: LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' * All command lines available in /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:315: main] Error 2 make: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:186: default] Error 2 Error: Process completed with exit code 1. Here's the link to particular run https://github.com/stsypanov/jdk/runs/2792324849 What can I do with this? Regards, Sergey Tsypanov
Re: Windows aarch64 (build debug) constantly fails
Hello David, On 11/06/21 11:41 am, David Holmes wrote: Hi, On 10/06/2021 8:58 pm, Сергей Цыпанов wrote: Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code I see this message in the log Compiling 2 files for BUILD_JVMTI_TOOLS LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' Yes this has been failing in Github actions for some time now. It appears to be a misconfigured Visual Studio installation. However there seems to be no way to report a problem in this regard so we seem to be stuck unless someone knows how to bring such issues to the attention of the Github support team ? Unrelated to JDK project, last time when I had run into a Github actions issue, I had reported it as a issue at https://github.com/actions/virtual-environments and they were pretty responsive and helpful about it. -Jaikiran
Re: Windows aarch64 (build debug) constantly fails
On 11/06/2021 4:27 pm, Jaikiran Pai wrote: Hello David, On 11/06/21 11:41 am, David Holmes wrote: Hi, On 10/06/2021 8:58 pm, Сергей Цыпанов wrote: Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code I see this message in the log Compiling 2 files for BUILD_JVMTI_TOOLS LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' Yes this has been failing in Github actions for some time now. It appears to be a misconfigured Visual Studio installation. However there seems to be no way to report a problem in this regard so we seem to be stuck unless someone knows how to bring such issues to the attention of the Github support team ? Unrelated to JDK project, last time when I had run into a Github actions issue, I had reported it as a issue at https://github.com/actions/virtual-environments and they were pretty responsive and helpful about it. Thanks Jaikiran I'll give that a go. David -Jaikiran
