From maurizio.cimadamore at oracle.com Tue Feb 1 12:48:49 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 1 Feb 2022 12:48:49 +0000 Subject: changes to the foreign preview API Message-ID: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> Hi, as we've just integrated our first changeset which moves the Foreign Function & Memory API into java.base (as a preview API), I'd like to expand a bit more on the kind of API changes you might expect in the upcoming weeks. Disclaimer: these changes will only apply to the "foreign-preview" branch, so they won't affect the branch we currently use to generate EA binaries (in case we need to apply quick fixes there). First, you can expect us playing with the package name some more; java.lang.foreign is really nothing more than an opening position, and it is likely that we will move to a package hierarchy where the Memory Access API and the Foreign Linker API live in two different packages (e.g. java.X vs. java.X.invoke, for some value of X). Secondly, on the renaming front, as anticipated in [1], we are also planning a biggie rename from ResourceScope to MemorySession. This renaming comes from the consideration that, currently there isn't always a 1:1 relationship between a resource scope and a lexical scope (for instance in case where a resource scope is stored in a field). We feel that the MemorySession name is both more neutral w.r.t. suggesting any correspondence with lexical scope and, at the same time more specific (what's a "resource" ?). We will also bring back the SegmentAllocator interface on MemorySession - which means that you can just use methods on SegmentAllocator on a MemorySession instance, which on the balance, works quite well, and makes client code a bit more concise. The other change we'd like to make is to remove the scope() accessors from all the resources (MemorySegment, NativeSymbol, VaList). This comes from a desire to make the API more principled: only the owner of a scope/session should have the "right" to close it. In fact, we have spent significant API estate (e.g. ResourceScope::whileAlive) just from preventing random clients to shut down scopes. We now believe a better approach would be to simply make the scope associated e.g. with a memory segment inaccessible. In other words, a resource scope/memory session becomes a _capability_: it is up to the owner of the scope/session to decide who to share that capability with. Once a client has a scope, it can close that scope, but also affect the scope by registering cleanup actions, or allocating on that scope. Conversely, if a client only has a segment, there's no way for that client to affect the owning scope/session in a meaninful (and possibly, harmful) way. Because of this, our plan is to drop API points to keep scopes/sessions alive for longer than their creators intended. Internally, the API will still make concurrent memory access safe, as well as protect segment from being closed while in the middle of a native call (or an async ByteBuffer IO operation). In fact, we think that the cases that are secured by the memory/linker API internals already constitute the vast majority of cases in which it makes sense to reach for a mechanism to keep a scope/session open. If needs be, this leaves us space to add other API methods in the future, such adding a simple higher-order funtion to execute an action on a resource while keeping its scope open, or, more generally, to add a scope dependency mechanism such as that described in [2]. Finally, we would like to tweak the policy of the --enable-native-access flag, as follows (this change was first discussed in [3]): * when the flag is specified, we keep existing behavior. This means getting an exception on every unsafe access, if the accessing module not listed in the flag; * when flag is not specified, access to unsafe functioalities is allowed, with runtime warning. The new, more-tolerant behavior in the absence of flag would facilitate migration away from JNI in cases where altering the set of command line options might be difficult. This mode would also help us (later) migrate JNI to require a similar opt-in too, effectively putting both JNI and Panama on the same grounds. The new mode is transitional and won't be supported forever: in a future release, this mode will be disabled and the new flag will be required _always_. This would give us more time to improve the support for the --enable-native-access flag in cases where e.g. it is currently problematic to alter the command line options and/or to introduce a better way to propagate native dependencies across modules. This should pretty much cover it. With the exception of renaming of classes and packages, we expect most of the idiomatic Panama code (such as that in our jextract examples [4]) to remain indeed very similar to its Java 18 counterpart. Cheers Maurizio [1] - https://inside.java/2021/09/16/finalizing-the-foreign-apis/ [2] - https://inside.java/2021/05/28/taming-resource-scopes/ [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-January/016011.html [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md From jvernee at openjdk.java.net Tue Feb 1 13:32:20 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 13:32:20 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning In-Reply-To: <5ImNrFj2rBNHHN84_Ij50EYkpCWapACF8NNo_30L75k=.d6a3b8b2-d32b-458d-b207-02fc7d71d78f@github.com> References: <5ImNrFj2rBNHHN84_Ij50EYkpCWapACF8NNo_30L75k=.d6a3b8b2-d32b-458d-b207-02fc7d71d78f@github.com> Message-ID: <2knrdyxJZMAaj4eIWEHH_SMIZabTDQ8RwsSLu6stfUY=.b817367f-570a-459f-aee9-220d7521f5d7@github.com> On Mon, 31 Jan 2022 19:31:41 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. >> >> The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. >> >> The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: >> - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. >> - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. >> - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. >> >> Thanks, >> Jorn > > src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 110: > >> 108: order == ByteOrder.BIG_ENDIAN ? "B" : "b", >> 109: bitSize(), >> 110: carrier == MemoryAddress.class ? "MA" : carrier.descriptorString())); > > I have thought separately about that. I think I'd like to change this so that we drop the `b` and we replace it with a one letter descriptor (as per descriptor string), and use `a` for `MemoryAddress`. Then, as for `b` we use upper case for bigg-endian, and lower-case for little endian. That way the toString representation is compact in all cases (while with this patch it blows up on MemoryAddress). Good suggestion. I went with this scheme since it seemed more extensible if we wanted to add more carriers in the future. But, it's not like the toString format is specified, so I guess we can change it up later if needed. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/635 From mcimadamore at openjdk.java.net Tue Feb 1 15:01:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Feb 2022 15:01:46 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning In-Reply-To: References: Message-ID: On Mon, 31 Jan 2022 17:55:29 GMT, Jorn Vernee wrote: > Hi, > > This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. > > The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. > > The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: > - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. > - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. > - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. > > Thanks, > Jorn Overall looks a very solid change. It is now easier to look at the code and understand what kind of bytecode will be generared for a given downcall/upcall. I've left some optional comments around the code, but I didn't really found anything wrong with the new code. Other misc comments: * SharedUtils::wrapWithAllocator seems unused * some of the combinators (for IMR and acquire/release) are still present in SharedUtils * there is a lot of coupling between the specializer internal state and the recipe execution (in VMLoad/VMStore especially, but also in others) - this is made clearer by the rewrite, but I appreciate that even the old code had an element of this src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 637: > 635: } > 636: > 637: /** This class seems to still have a `specialize method` src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 64: > 62: import static jdk.internal.org.objectweb.asm.Opcodes.*; > 63: > 64: public class Specializer { Maybe a less generic name would be better? Like BindingSpecializer? src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 260: > 258: if (callingSequence.allocationSize() != 0) { > 259: emitConst(callingSequence.allocationSize()); > 260: mv.visitMethodInsn(INVOKESTATIC, BINDING_CONTEXT_INTRN, OF_BOUNDED_ALLOCATOR_NAME, OF_BOUNDED_ALLOCATOR_DESC, false); In this, and other instructions, I wonder if it would be more readable to have helper routine, and rely on class literal/strings more e.g. instead of: mv.visitMethodInsn(INVOKESTATIC, BINDING_CONTEXT_INTRN, OF_BOUNDED_ALLOCATOR_NAME, OF_BOUNDED_ALLOCATOR_DESC, false); something like: emitInvokeStatic(Binding.Context.class, "ofBoundedAllocator", OF_BOUNDED_ALLOCATOR_DESC); src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 399: > 397: for (Binding binding : bindings) { > 398: switch (binding.tag()) { > 399: case VM_STORE -> emitVMStore((Binding.VMStore) binding); I note that we depart from the previous model of having virtual calls on the Binding instance which does the right thing. That's fine, I guess there's a lot of coupling (esp. in VMLoad/VMStore) with the specializer state. src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 452: > 450: } > 451: > 452: private void emitLoadInteralAllocator() { Typo: loadInterNalAllocator src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 600: > 598: > 599: // operand/srcSegment is on the stack > 600: // copy(MemorySegment srcSegment, long srcOffset, MemorySegment dstSegment, long dstOffset, long bytes) I found those comments confusing, as they almost look like commented out code :-) ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Tue Feb 1 16:12:36 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 16:12:36 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 14:48:09 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. >> >> The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. >> >> The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: >> - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. >> - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. >> - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. >> >> Thanks, >> Jorn > > src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 260: > >> 258: if (callingSequence.allocationSize() != 0) { >> 259: emitConst(callingSequence.allocationSize()); >> 260: mv.visitMethodInsn(INVOKESTATIC, BINDING_CONTEXT_INTRN, OF_BOUNDED_ALLOCATOR_NAME, OF_BOUNDED_ALLOCATOR_DESC, false); > > In this, and other instructions, I wonder if it would be more readable to have helper routine, and rely on class literal/strings more e.g. instead of: > > mv.visitMethodInsn(INVOKESTATIC, BINDING_CONTEXT_INTRN, OF_BOUNDED_ALLOCATOR_NAME, OF_BOUNDED_ALLOCATOR_DESC, false); > > something like: > > > emitInvokeStatic(Binding.Context.class, "ofBoundedAllocator", OF_BOUNDED_ALLOCATOR_DESC); That's a good idea. I think we can use DirectMethodHandleDesc to describe the method we want to call > src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 399: > >> 397: for (Binding binding : bindings) { >> 398: switch (binding.tag()) { >> 399: case VM_STORE -> emitVMStore((Binding.VMStore) binding); > > I note that we depart from the previous model of having virtual calls on the Binding instance which does the right thing. That's fine, I guess there's a lot of coupling (esp. in VMLoad/VMStore) with the specializer state. Yeah, there's a dependency on the specializer state. But, I also personally like that the code is not interspersed with other code like class definitions and code for interpretation/verification, like in the Binding classes. I find that it reads a little bit easier. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Tue Feb 1 17:42:21 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 17:42:21 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. > > The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. > > The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: > - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. > - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. > - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Address review comments - Change ValueLayout toString ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/635/files - new: https://git.openjdk.java.net/panama-foreign/pull/635/files/22641e26..af981a6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=635&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=635&range=00-01 Stats: 1874 lines in 8 files changed: 860 ins; 1006 del; 8 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/635/head:pull/635 PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Tue Feb 1 17:42:23 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 17:42:23 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v2] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 13:26:04 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address review comments >> - Change ValueLayout toString > > src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 637: > >> 635: } >> 636: >> 637: /** > > This class seems to still have a `specialize method` Good catch, forgot to remove those > src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 64: > >> 62: import static jdk.internal.org.objectweb.asm.Opcodes.*; >> 63: >> 64: public class Specializer { > > Maybe a less generic name would be better? Like BindingSpecializer? Done. > src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 452: > >> 450: } >> 451: >> 452: private void emitLoadInteralAllocator() { > > Typo: loadInterNalAllocator Good catch > src/java.base/share/classes/jdk/internal/foreign/abi/Specializer.java line 600: > >> 598: >> 599: // operand/srcSegment is on the stack >> 600: // copy(MemorySegment srcSegment, long srcOffset, MemorySegment dstSegment, long dstOffset, long bytes) > > I found those comments confusing, as they almost look like commented out code :-) I tried to make the comments a bit more clear. It's intended as a mental note of the signature of the method that is being invoked in the bytecode below. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Tue Feb 1 18:42:10 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 18:42:10 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v3] In-Reply-To: References: Message-ID: > Hi, > > This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. > > The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. > > The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: > - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. > - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. > - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Except class instances directly instead of internal names. Remove unused constants ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/635/files - new: https://git.openjdk.java.net/panama-foreign/pull/635/files/af981a6d..6510e2b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=635&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=635&range=01-02 Stats: 55 lines in 1 file changed: 2 ins; 22 del; 31 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/635/head:pull/635 PR: https://git.openjdk.java.net/panama-foreign/pull/635 From mcimadamore at openjdk.java.net Tue Feb 1 18:42:12 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Feb 2022 18:42:12 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v2] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 17:42:21 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. >> >> The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. >> >> The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: >> - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. >> - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. >> - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments > - Change ValueLayout toString Marked as reviewed by mcimadamore (Committer). src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 662: > 660: } > 661: > 662: private void emitInvokeStatic(String ownerInternalName, String methodName, String descriptor) { Any reason as to why using a String for the owner instead of Class - you want to avoid multiple computations, I guess? Having a class literal in the clients is much more readable IMHO than having a string constant. That said, maybe we can find a compromise :-) Why not naming the INTRN constants in a regular way, so that it's clear what they refer to? e.g. JAVA_LANG_INVOKE_MEMORYLAYOUT or, if we are ok dropping the package, just: MEMORY_LAYOUT E.g. drop the INTRN suffix - that should make things more readable. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Tue Feb 1 18:42:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 18:42:12 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v2] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 18:34:55 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address review comments >> - Change ValueLayout toString > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 662: > >> 660: } >> 661: >> 662: private void emitInvokeStatic(String ownerInternalName, String methodName, String descriptor) { > > Any reason as to why using a String for the owner instead of Class - you want to avoid multiple computations, I guess? Having a class literal in the clients is much more readable IMHO than having a string constant. > > That said, maybe we can find a compromise :-) > > Why not naming the INTRN constants in a regular way, so that it's clear what they refer to? > e.g. > > JAVA_LANG_INVOKE_MEMORYLAYOUT > > or, if we are ok dropping the package, just: > > > MEMORY_LAYOUT > > > E.g. drop the INTRN suffix - that should make things more readable. Wasn't done yet :) (forgot to apply that part of the suggestion) These methods now take a class literal, and I've removed the unneeded INTRN constants ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Tue Feb 1 18:47:18 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 18:47:18 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v4] In-Reply-To: References: Message-ID: <2dXkZ41k1kIstbyXjLveImcOT2c4Iwry33pKb7XIiag=.34977282-a220-4799-8d15-baec526b0d9e@github.com> > Hi, > > This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. > > The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. > > The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: > - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. > - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. > - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Remove spurious import ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/635/files - new: https://git.openjdk.java.net/panama-foreign/pull/635/files/6510e2b1..46963301 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=635&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=635&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/635/head:pull/635 PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Tue Feb 1 18:47:19 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Feb 2022 18:47:19 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v3] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 18:42:10 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. >> >> The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. >> >> The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: >> - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. >> - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. >> - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Except class instances directly instead of internal names. Remove unused constants src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 32: > 30: import java.lang.invoke.VarHandle; > 31: import java.nio.ByteOrder; > 32: import java.util.Locale; Spurious import Suggestion: ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/635 From mcimadamore at openjdk.java.net Tue Feb 1 19:19:29 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Feb 2022 19:19:29 GMT Subject: [foreign-preview] RFR: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning [v4] In-Reply-To: <2dXkZ41k1kIstbyXjLveImcOT2c4Iwry33pKb7XIiag=.34977282-a220-4799-8d15-baec526b0d9e@github.com> References: <2dXkZ41k1kIstbyXjLveImcOT2c4Iwry33pKb7XIiag=.34977282-a220-4799-8d15-baec526b0d9e@github.com> Message-ID: On Tue, 1 Feb 2022 18:47:18 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. >> >> The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. >> >> The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: >> - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. >> - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. >> - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Remove spurious import Nice! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/635 From notzed at gmail.com Wed Feb 2 01:30:28 2022 From: notzed at gmail.com (Michael Zucchi) Date: Wed, 2 Feb 2022 12:00:28 +1030 Subject: changes to the foreign preview API In-Reply-To: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> References: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> Message-ID: <05455b75-adf5-6ad8-91e9-7b24e6588723@gmail.com> On 1/2/22 23:18, Maurizio Cimadamore wrote: > The other change we'd like to make is to remove the scope() accessors > from all the resources (MemorySegment, NativeSymbol, VaList). This > comes from a desire to make the API more principled: only the owner of > a scope/session should have the "right" to close it. In fact, we have > spent significant API estate (e.g. ResourceScope::whileAlive) just > from preventing random clients to shut down scopes. We now believe a > better approach would be to simply make the scope associated e.g. with > a memory segment inaccessible. In other words, a resource scope/memory > session becomes a _capability_: it is up to the owner of the > scope/session to decide who to share that capability with. Once a > client has a scope, it can close that scope, but also affect the scope > by registering cleanup actions, or allocating on that scope. > Conversely, if a client only has a segment, there's no way for that > client to affect the owning scope/session in a meaninful (and > possibly, harmful) way There's some cases where this will be a bit inconvenient. A simple example would be something like: struct a { ?int c; }; struct b { ? struct a *a; }; Where 'a'? is created/managed by 'b'.? The java side might be: ?class b { ? MemorySegment segment; ? b(MemorySegment seg) { ??? segment=seg; ? } ?? a getA() { ????? MemoryAddress addr = varhandle$a.get(segment); ????? return new a(MemorySegment.ofAddress(addr, a.layout.byteSize(), segment.scope()); ?? } } You don't really want to have to track and pass the scope to the accessor each time.? The alternative is to add a scope field to 'b', but then it also needs to be passed to every constructor of such a class. ?Michael From notzed at gmail.com Wed Feb 2 01:34:28 2022 From: notzed at gmail.com (Michael Zucchi) Date: Wed, 2 Feb 2022 12:04:28 +1030 Subject: resource scopes and close actions Message-ID: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> Morning, I was hoping to use resource scopes to auto-cleanup native-allocated resources, but it looks like it's going to be a bit messy because segments get closed before their close actions are invoked. Is this the intended behaviour or a side-effect of 'no particular order'? For some api's it doesn't matter as they don't use api-allocated public structures (e.g. opencl) and the same approach is fine using MemoryAddress, but for others it's an issue (e.g. ffmpeg) where the obvious mapping is to use a segment and varhandles. Probably as a workaround - if i want to have this feature at any rate because i'm not sure if it's a good idea yet - i'll just save a copy of the address before it's turned into a segment and pass that to any close function instead. I've only really started looking at seeing how to 'scope' things 'properly' but it feels a bit clumsy and sort of not worth it because it has to be worked around all the time either with hacks like this or resorting to simply using the global scope which effectively does nothing. ?Z From maurizio.cimadamore at oracle.com Wed Feb 2 10:50:47 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 Feb 2022 10:50:47 +0000 Subject: resource scopes and close actions In-Reply-To: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> Message-ID: <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> Hi Michael, I understand the concern. Running close actions _after_ the scope is closed (and so segments associated with it are inaccessible) is a sort of a forced move: you need to run the close actions when you are 100% sure that nobody else is accessing the scope. Otherwise you might have a race between a close action attempting to free some resource and another thread attempting to access it. The result is that, as you have noticed, adding close actions is mostly useful when working with APIs that turn raw MemoryAddress into segments manually (MemorySegment::ofAddress). Can you please share a problematic case with ffmpeg? Thanks Maurizio On 02/02/2022 01:34, Michael Zucchi wrote: > > Morning, > > I was hoping to use resource scopes to auto-cleanup native-allocated > resources, but it looks like it's going to be a bit messy because > segments get closed before their close actions are invoked. > > Is this the intended behaviour or a side-effect of 'no particular order'? > > For some api's it doesn't matter as they don't use api-allocated > public structures (e.g. opencl) and the same approach is fine using > MemoryAddress, but for others it's an issue (e.g. ffmpeg) where the > obvious mapping is to use a segment and varhandles. > > Probably as a workaround - if i want to have this feature at any rate > because i'm not sure if it's a good idea yet - i'll just save a copy > of the address before it's turned into a segment and pass that to any > close function instead. > > I've only really started looking at seeing how to 'scope' things > 'properly' but it feels a bit clumsy and sort of not worth it because > it has to be worked around all the time either with hacks like this or > resorting to simply using the global scope which effectively does > nothing. > > ?Z > > From jvernee at openjdk.java.net Wed Feb 2 12:42:38 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Feb 2022 12:42:38 GMT Subject: [foreign-preview] Integrated: 8278414: Replace binding recipe customization using MH combinators with bytecode spinning In-Reply-To: References: Message-ID: On Mon, 31 Jan 2022 17:55:29 GMT, Jorn Vernee wrote: > Hi, > > This patch removes the binding recipe specialization using MethodHandle combinators in the linker implementation, and replaces it with specialization by spinning a class using the ASM bytecode API. > > The main reason for doing this is simplicity of the implementation, as well as finer-grained control over the classes that are generated. > > The meat of this PR is in `jdk.internal.foreign.abi.Specializer`, but there are some spin-off changes in this PR as well: > - MethodHandles are really good at sharing classes, so to get comparable performance, this PR also adds a cache behind CLinker::downcallHandle. Due to this, I've also created an AbstractLinker base class for all linker implementations, which contains the cache as well as other shared code. > - CallingSequence is used to steer the class generation. I've added some predicates to this class to check whether the CS is for downcall or upcall. As well as splitting the methodType() accessor into callerMethodType() and calleeMethodType(), reflecting the 2 method types in play during generation (one of the 2 was being computed ad-hoc during specialization previously). This is also responsible for most of the test changes. I've added some javadoc to CS which hopefully adequately explains these accessors. > - I've slightly changed the toString output of ValueLayout to include carrier types as well, in order to be able to use FunctionDescriptor.toString() as a file name in case we want to dump the generated classes to disc. This avoids conflicts between e.g. long and double, which previously were both stringified as b64. > > Thanks, > Jorn This pull request has now been integrated. Changeset: 55a7e6c4 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/55a7e6c4cd65048efb1f6de4a3fed7a1348a73ad Stats: 1629 lines in 19 files changed: 1110 ins; 410 del; 109 mod 8278414: Replace binding recipe customization using MH combinators with bytecode spinning Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/635 From jvernee at openjdk.java.net Wed Feb 2 12:52:48 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Feb 2022 12:52:48 GMT Subject: [foreign-preview] RFR: 8280721: Rewrite binding of foreign classes to use javaClasses.h/cpp [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch is a refactoring of the binding between the VM and several Java classes using by the linker. > > The usual way of creating such mappings is by declaring a C++ companion class in javaClasses.(h/c)pp, but because the bound Javas classes were previously in an incubator module, that wasn't possible. > > Now that we have moved to java.base, we can create the missing C++ companion classes, and remove the code that did ad-hoc lookup of field offsets in the constructor of the ForeignGlobals class in the VM. > > Additionally, this patch also removes 2 proxy classes (VMStorageProxy and ABIDescriptorProxy) that are no longer needed. As well as move NativeEntryPoint from the jdk.internal.invoke package to the jdk.internal.foreign package, since it was the only class in that package. > > Thanks, > Jorn Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'foreign-preview' into Move_Internal_Invoke - Remove unimplemented NativeCallConv::print_on - Add direct javaClasses bindings for panama foreign classes - Remove jdk.internal.invoke package ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/634/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=634&range=01 Stats: 616 lines in 27 files changed: 314 ins; 243 del; 59 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/634.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/634/head:pull/634 PR: https://git.openjdk.java.net/panama-foreign/pull/634 From maurizio.cimadamore at oracle.com Wed Feb 2 13:10:30 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 Feb 2022 13:10:30 +0000 Subject: changes to the foreign preview API In-Reply-To: <05455b75-adf5-6ad8-91e9-7b24e6588723@gmail.com> References: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> <05455b75-adf5-6ad8-91e9-7b24e6588723@gmail.com> Message-ID: <535e4258-daca-cca8-575d-538de5066a69@oracle.com> Hi, the example you mention is a trade off we have considered. The problem with the status quo, where scope is freely accessible in all resources, is that there is no way to control that a scope will not be closed by _clients_ of a library. For example you might want to allocate a big segment, and give chunks of that segment to clients, in response to certain requests. If a client can effectively bring the entire world down by doing `segment.scope().close()`, that doesn't seem like a great place to be either; that scope manages the lifecycle of the library, not that of the client. There are other things a client can do that are questionable, such as registering a never-terminating close action on a scope that is owned by some other actor, which will effectively render the scope uncloseable, and result in a memory leak. So, the thinking here is that there are clients that _produce_ resources (those clients will have a scope) and clients that _consume_ resources (those clients will only have e.g. a segment). The former are of course unrestricted in what they can do - but in a way, if they mess up their own scope, it's their business. The latter, being only consumers, cannot really alter the lifecycle of the resource they are dealing with in any way. Your example is tricky because it does both: it is a client of a memory segment (it need to read bytes from the segment), but it is also a producer of segments (it wraps a raw pointer into a _new_ segment). The latter part is worth stressing: I think you are making the `getA()` accessor simpler than it actually is: that accessor is reading a pointer from a segment; that pointer will point to _another_ memory region (which could be completely unrelated from that of the original segment), and returns a _new_ segment, backed by this new region. Now, in the general case, there is no guarantee that the two regions will share the same lifecycle (although that can sometimes be the case). In which case, the options you listed seem morally correct: either you tweak the `getA()` accessor to also accept a scope (that of the returned segment), or you upgrade the whole class to be not just a _consumer_, but also a _producer_ of segments. This means that the struct will need its own scope, either passed from outside, or created within. For the records, I think passing a scope to the accessor might not be as bad; first, the application allocating these structs classes probably have a scope handy to pass. Secondly, accepting a scope also opens up the possibility of controlling the lifecycle of the returned struct some more - e.g. ``` B b = ... try (var scope = ResourceScope.newConfinedScope()) { ?? A a = b.getA(scope); ?? ... } // a's segment cannot be dereferenced here ``` Summing up, I think the change can be a little inconvenient, but only in cases where the API wants to assert that the scope of the returned segment is _really_ the same as the current one (we have this problem with `VaList::copy`, for instance). But in the general case of a struct that has a pointer to some other struct, if an API wants to create a segment out of a raw pointer, there is a choice to make when it comes to the lifecycle of the returned segment. Ideally, that choice has to be reflected by the API in some way. The fact that the proposed changes makes that choice bubble up some more is, IMHO, a good thing. Maurizio On 02/02/2022 01:30, Michael Zucchi wrote: > On 1/2/22 23:18, Maurizio Cimadamore wrote: >> The other change we'd like to make is to remove the scope() accessors >> from all the resources (MemorySegment, NativeSymbol, VaList). This >> comes from a desire to make the API more principled: only the owner >> of a scope/session should have the "right" to close it. In fact, we >> have spent significant API estate (e.g. ResourceScope::whileAlive) >> just from preventing random clients to shut down scopes. We now >> believe a better approach would be to simply make the scope >> associated e.g. with a memory segment inaccessible. In other words, a >> resource scope/memory session becomes a _capability_: it is up to the >> owner of the scope/session to decide who to share that capability >> with. Once a client has a scope, it can close that scope, but also >> affect the scope by registering cleanup actions, or allocating on >> that scope. Conversely, if a client only has a segment, there's no >> way for that client to affect the owning scope/session in a meaninful >> (and possibly, harmful) way > > There's some cases where this will be a bit inconvenient. > > A simple example would be something like: > > struct a { > ?int c; > }; > > struct b { > ? struct a *a; > }; > > Where 'a'? is created/managed by 'b'.? The java side might be: > > ?class b { > ? MemorySegment segment; > > ? b(MemorySegment seg) { > ??? segment=seg; > ? } > ?? a getA() { > ????? MemoryAddress addr = varhandle$a.get(segment); > ????? return new a(MemorySegment.ofAddress(addr, a.layout.byteSize(), > segment.scope()); > ?? } > } > > You don't really want to have to track and pass the scope to the > accessor each time.? The alternative is to add a scope field to 'b', > but then it also needs to be passed to every constructor of such a class. > > ?Michael > From jboes at openjdk.java.net Wed Feb 2 16:30:47 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 2 Feb 2022 16:30:47 GMT Subject: [foreign-preview] RFR: 8281147: Other tests that use the foreign API are missing --enable-preview Message-ID: This change adds the --enable-preview flag to tests in other areas (jdk.incubator.vector, java.util.stream) that use the (to be previewed) foreign API, as well as cleaning up the use of a no longer needed proxy class. ------------- Commit messages: - add --enable-Preview to other tests that use the foreign API Changes: https://git.openjdk.java.net/panama-foreign/pull/636/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=636&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281147 Stats: 41 lines in 33 files changed: 34 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/636.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/636/head:pull/636 PR: https://git.openjdk.java.net/panama-foreign/pull/636 From youngty1997 at gmail.com Wed Feb 2 17:04:47 2022 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 2 Feb 2022 11:04:47 -0600 Subject: changes to the foreign preview API In-Reply-To: <05455b75-adf5-6ad8-91e9-7b24e6588723@gmail.com> References: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> <05455b75-adf5-6ad8-91e9-7b24e6588723@gmail.com> Message-ID: +1 This change, like others before it, makes it harder to create higher level APIs or make it more awkward to use them. Can you please stop making life hell for anyone who wants to write or use a higher level API using Panama? Unless I'm missing something, the same basic idea could be achieved by making sliced segments have the global scope instead of inheriting the parent's scope. Unless I'm missing something, please do that instead. On 2/1/22 7:30 PM, Michael Zucchi wrote: > On 1/2/22 23:18, Maurizio Cimadamore wrote: >> The other change we'd like to make is to remove the scope() accessors >> from all the resources (MemorySegment, NativeSymbol, VaList). This >> comes from a desire to make the API more principled: only the owner >> of a scope/session should have the "right" to close it. In fact, we >> have spent significant API estate (e.g. ResourceScope::whileAlive) >> just from preventing random clients to shut down scopes. We now >> believe a better approach would be to simply make the scope >> associated e.g. with a memory segment inaccessible. In other words, a >> resource scope/memory session becomes a _capability_: it is up to the >> owner of the scope/session to decide who to share that capability >> with. Once a client has a scope, it can close that scope, but also >> affect the scope by registering cleanup actions, or allocating on >> that scope. Conversely, if a client only has a segment, there's no >> way for that client to affect the owning scope/session in a meaninful >> (and possibly, harmful) way > > There's some cases where this will be a bit inconvenient. > > A simple example would be something like: > > struct a { > ?int c; > }; > > struct b { > ? struct a *a; > }; > > Where 'a'? is created/managed by 'b'.? The java side might be: > > ?class b { > ? MemorySegment segment; > > ? b(MemorySegment seg) { > ??? segment=seg; > ? } > ?? a getA() { > ????? MemoryAddress addr = varhandle$a.get(segment); > ????? return new a(MemorySegment.ofAddress(addr, a.layout.byteSize(), > segment.scope()); > ?? } > } > > You don't really want to have to track and pass the scope to the > accessor each time.? The alternative is to add a scope field to 'b', > but then it also needs to be passed to every constructor of such a class. > > ?Michael > From mcimadamore at openjdk.java.net Wed Feb 2 22:59:20 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Feb 2022 22:59:20 GMT Subject: [foreign-preview] RFR: 8281147: Other tests that use the foreign API are missing --enable-preview In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 16:25:52 GMT, Julia Boes wrote: > This change adds the --enable-preview flag to tests in other areas (jdk.incubator.vector, java.util.stream) that use the (to be previewed) foreign API, as well as cleaning up the use of a no longer needed proxy class. Marked as reviewed by mcimadamore (Committer). test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java line 26: > 24: /* > 25: * @test > 26: * @enablePreview Can we do the same trick you did for the stream API test, and add a new TEST.properties file in this folder and enable preview there? Or, I assume you tried and that didn't work? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/636 From notzed at gmail.com Thu Feb 3 03:25:13 2022 From: notzed at gmail.com (Michael Zucchi) Date: Thu, 3 Feb 2022 13:55:13 +1030 Subject: resource scopes and close actions In-Reply-To: <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> Message-ID: A simple case is AVFormatContext. Once you open a file you want to scan the stream list which is stored as an AVStream **.? Both need to be segments to use the varhandle api to access fields. typedef struct AVFormatContext { ?... ??? unsigned int nb_streams; ??? /** ???? * A list of all streams in the file. New streams are created with ???? * avformat_new_stream(). ???? * ???? * - demuxing: streams are created by libavformat in avformat_open_input(). ???? *???????????? If AVFMTCTX_NOHEADER is set in ctx_flags, then new streams may also ???? *???????????? appear in av_read_frame(). ???? * - muxing: streams are created by the user before avformat_write_header(). ???? * ???? * Freed by libavformat in avformat_free_context(). ???? */ ??? AVStream **streams; ?... }; An example public field of AVStream: typedef struct AVStream { ?... ??? /** ???? * This is the fundamental unit of time (in seconds) in terms ???? * of which frame timestamps are represented. ???? * ???? * decoding: set by libavformat ???? * encoding: May be set by the caller before avformat_write_header() to ???? *?????????? provide a hint to the muxer about the desired timebase. In ???? *?????????? avformat_write_header(), the muxer will overwrite this field ???? *?????????? with the timebase that will actually be used for the timestamps ???? *?????????? written into the file (which may or may not be related to the ???? *?????????? user-provided one, depending on the format). ???? */ ??? AVRational time_base; ... }; So my current code generator uses a MemorySegment as the sole 'holder' for each non-anonymous type, this allows the base constructor just takes that and i have factory methods which can create the segment from an address. public class AVFormatContext { ? final MemorySegment segment; ? AVFormatContext(MemorySegment segment) { ? ? this.segment = segment; ? } ? public AVFormatContext create(MemorySegment segment) { ??? return new ... ?} ? public AVFormatContext create(MemoryAddress addr, ResourceScope scope) { ??? return create(MemorySegment.ofAddress(addr, layout.byteSize(), scope); ?} } Then for the **streams accessor I return a typed List implementation, it invokes a BiFunction to create instances. ??? public HandleArray getStreams() { ?? ???? return HandleArray.createArray((MemoryAddress)streams$VH.get(segment()), getNumStreams(), AVStream::create, segment.scope()); ?? ?} AVRational is an inline struct so that that also needs it's own segment, so again the scope gets passed down to getTimeBase() (implicitly though, via a sliceHandle).? So that's that part, it just tracks the same scope through the process, but this is more of an issue in relation to the other email.? For writing streams you have to create the streams array and write entries to it as well, so care would have to be taken to use the same scope for everything that is manually created. The factory for an AVFormatContext takes an explicit scope parameter because it's the root 'allocation' if you will, and I was just experimenting with adding an auto-close feature to it. ??? static final MethodHandle avformat_open_input$FH = Memory.downcall("avformat_open_input", FunctionDescriptor.of(Memory.INT, Memory.POINTER, Memory.POINTER, Memory.POINTER, Memory.POINTER)); ?? ?public static AVFormatContext openInput(String url, AVInputFormat fmt, HandleArray options, ResourceScope scope$) { ?? ???? MemoryAddress ps; ?? ???? int result$; ?? ???? try (Frame frame$ = Memory.createFrame()) { ?? ???? ??? PointerArray ps$h = PointerArray.createArray(1, frame$); ?? ???? ??? result$ = (int)avformat_open_input$FH.invokeExact((jdk.incubator.foreign.Addressable)Memory.address(ps$h), (jdk.incubator.foreign.Addressable)frame$.copy(url), (jdk.incubator.foreign.Addressable)Memory.address(fmt), (jdk.incubator.foreign.Addressable)Memory.address(options)); ?? ???? ??? ps = ps$h.get(0); ?? ???? ??? if (result$ == 0) { ?? ???? ??? ??? AVFormatContext res$ = AVFormatContext.create(ps, scope$); ?? ???? ??? ??? scope$.addCloseAction(() -> close(ps)); ?? ???? ??? ??? return res$; ?? ???? ??? } ?? ???? } catch (Throwable t) { ?? ???? ??? throw new RuntimeException(t); ?? ???? } ?? ???? throw new RuntimeException("error="+result$); ?? ?} ??? public static void close(MemoryAddress s) {...} So it's only a minor inconvenience - it needs to keep another copy of the MemoryAddress (ps) around, and it needs to have a static 'close' function that takes a MemoryAddress rather than a static or objectfunction that uses 'segment'.? The former is just a wasteful copy and the latter pollutes the api a bit.? ffmpeg avformat_close_input actually takes an AVFormatContext ** and so can be invoked multiple times safely, so another explicit close function would be useful as well but that's another matter. Anyway i'm still trying to work out how to fit this all in, i'm passing around scopes because MemorySegment.ofAddress() needs it and now i'm trying to work out how to fit them to the lifecycle of objects.?? This was the first attempt at utilising the facilities for some benefit. But it seems very difficult to get right and somewhat clumsy to use and only provides a very marginal increase in live-ness safety because you can always turn a MemoryAddress into a MemorySegment in another scope.? And ideally it's not something? you'd expose to the api user.? With JNI there were other more straightforward mechanisms to manage the java<>c lifecycle matching (e.g. nulling out the pointer), ones that could be hidden from the library user. I'm starting to think of changing to use globalScope() and to mostly pretend ResourceScope doesn't exist.? For handle-based apis (anonymous pointers) like OpenCL it's already effectively the case anyway. On 2/2/22 21:20, Maurizio Cimadamore wrote: > Hi Michael, > I understand the concern. Running close actions _after_ the scope is > closed (and so segments associated with it are inaccessible) is a sort > of a forced move: you need to run the close actions when you are 100% > sure that nobody else is accessing the scope. Otherwise you might have > a race between a close action attempting to free some resource and > another thread attempting to access it. > > The result is that, as you have noticed, adding close actions is > mostly useful when working with APIs that turn raw MemoryAddress into > segments manually (MemorySegment::ofAddress). > > Can you please share a problematic case with ffmpeg? > > Thanks > Maurizio > > On 02/02/2022 01:34, Michael Zucchi wrote: >> >> Morning, >> >> I was hoping to use resource scopes to auto-cleanup native-allocated >> resources, but it looks like it's going to be a bit messy because >> segments get closed before their close actions are invoked. >> >> Is this the intended behaviour or a side-effect of 'no particular >> order'? >> >> For some api's it doesn't matter as they don't use api-allocated >> public structures (e.g. opencl) and the same approach is fine using >> MemoryAddress, but for others it's an issue (e.g. ffmpeg) where the >> obvious mapping is to use a segment and varhandles. >> >> Probably as a workaround - if i want to have this feature at any rate >> because i'm not sure if it's a good idea yet - i'll just save a copy >> of the address before it's turned into a segment and pass that to any >> close function instead. >> >> I've only really started looking at seeing how to 'scope' things >> 'properly' but it feels a bit clumsy and sort of not worth it because >> it has to be worked around all the time either with hacks like this >> or resorting to simply using the global scope which effectively does >> nothing. >> >> ?Z >> >> From jboes at openjdk.java.net Thu Feb 3 10:39:34 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 3 Feb 2022 10:39:34 GMT Subject: [foreign-preview] RFR: 8281147: Other tests that use the foreign API are missing --enable-preview In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 22:55:49 GMT, Maurizio Cimadamore wrote: >> This change adds the --enable-preview flag to tests in other areas (jdk.incubator.vector, java.util.stream) that use the (to be previewed) foreign API, as well as cleaning up the use of a no longer needed proxy class. > > test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java line 26: > >> 24: /* >> 25: * @test >> 26: * @enablePreview > > Can we do the same trick you did for the stream API test, and add a new TEST.properties file in this folder and enable preview there? Or, I assume you tried and that didn't work? Let's refrain from adding a properties file, given that there?s a template file already that defines test configuration (where I added `@enablePreview`), test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/636 From mcimadamore at openjdk.java.net Thu Feb 3 11:18:32 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Feb 2022 11:18:32 GMT Subject: [foreign-preview] RFR: 8281147: Other tests that use the foreign API are missing --enable-preview In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 16:25:52 GMT, Julia Boes wrote: > This change adds the --enable-preview flag to tests in other areas (jdk.incubator.vector, java.util.stream) that use the (to be previewed) foreign API, as well as cleaning up the use of a no longer needed proxy class. Marked as reviewed by mcimadamore (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/636 From maurizio.cimadamore at oracle.com Thu Feb 3 11:31:20 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Feb 2022 11:31:20 +0000 Subject: resource scopes and close actions In-Reply-To: References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> Message-ID: <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> Thanks, this is informative. Your approach seems generally correct. Since you create all the structures when you open the file (openInput method) it obviously makes sense for all the intermediate structs and arrays to share the same lifecycle/scope. Right now that is possible thanks to the scope() accessor; if we take that away it gets harder, I get that. But let's deal with that issue in a separate thread. > static final MethodHandle avformat_open_input$FH = > Memory.downcall("avformat_open_input", > FunctionDescriptor.of(Memory.INT, Memory.POINTER, Memory.POINTER, > Memory.POINTER, Memory.POINTER)); > ?? ?public static AVFormatContext openInput(String url, AVInputFormat > fmt, HandleArray options, ResourceScope scope$) { > ?? ???? MemoryAddress ps; > ?? ???? int result$; > ?? ???? try (Frame frame$ = Memory.createFrame()) { > ?? ???? ??? PointerArray ps$h = PointerArray.createArray(1, frame$); > ?? ???? ??? result$ = > (int)avformat_open_input$FH.invokeExact((jdk.incubator.foreign.Addressable)Memory.address(ps$h), > (jdk.incubator.foreign.Addressable)frame$.copy(url), > (jdk.incubator.foreign.Addressable)Memory.address(fmt), > (jdk.incubator.foreign.Addressable)Memory.address(options)); > ?? ???? ??? ps = ps$h.get(0); > ?? ???? ??? if (result$ == 0) { > ?? ???? ??? ??? AVFormatContext res$ = AVFormatContext.create(ps, > scope$); > ?? ???? ??? ??? scope$.addCloseAction(() -> close(ps)); > ?? ???? ??? ??? return res$; > ?? ???? ??? } > ?? ???? } catch (Throwable t) { > ?? ???? ??? throw new RuntimeException(t); > ?? ???? } > ?? ???? throw new RuntimeException("error="+result$); > ?? ?} > > ??? public static void close(MemoryAddress s) {...} > > So it's only a minor inconvenience - it needs to keep another copy of > the MemoryAddress (ps) around, and it needs to have a static 'close' > function that takes a MemoryAddress rather than a static or > objectfunction that uses 'segment'.? The former is just a wasteful > copy and the latter pollutes the api a bit.? ffmpeg > avformat_close_input actually takes an AVFormatContext ** and so can > be invoked multiple times safely, so another explicit close function > would be useful as well but that's another matter. > So, this is the main factory for AVFormatContext, and it takes a scope - that seems to make sense to me. When the user closes the scope, some native function will be called to release the memory that has been allocated so far. I'm not sure I see the issues you mention though: with respect to duplication, you refer to the fact that you have to keep a MemoryAddress (local!) variable around? Not to dismiss the concern, but that doesn't seem _that_ terrible. As for the close(MemoryAddress), yes, something like that would be needed, but why is it a public method? Couldn't it just be some private method somewhere? I guess I'm a bit fuzzy as to where your API boundaries are. It seems to me that you want your clients to deal in AVFormatContext, AVRational and friends, and you don't really want them to think (too much) about scope, segments and addresses - which I think is a fine move. But if that's the case, why having a close(MemoryAddress) in the API? > Anyway i'm still trying to work out how to fit this all in, i'm > passing around scopes because MemorySegment.ofAddress() needs it and > now i'm trying to work out how to fit them to the lifecycle of > objects.?? This was the first attempt at utilising the facilities for > some benefit. I think having at least one scope does make sense. After all it is possible for a client to create an AVFormatContext, get an AVStream out of it and keep hold of it for too long (e.g. after the AVFormatContext has been released). In which case, if the client tries to access that AVStream you will have a JVM crash. If, on the other hand, the AVStream is backed by the same scope as the AVFormatContext, clients can't cause crashes in this particular way: once the AVFormatContext has been closed, nothing associated with its scope will be accessible. Which seems like an important invariant in your API? Also, I'm not 100% clear on how you handle writes; if the user sets a custom AVStream on your array, clearly you can have a problem if the lifecycle of the custom AVStream doesn't match that of the enclosing AVFormatContext (which seems to be another reason to keep track of lifecycles?) > > But it seems very difficult to get right and somewhat clumsy to use > and only provides a very marginal increase in live-ness safety because > you can always turn a MemoryAddress into a MemorySegment in another > scope.? And ideally it's not something? you'd expose to the api user.? > With JNI there were other more straightforward mechanisms to manage > the java<>c lifecycle matching (e.g. nulling out the pointer), ones > that could be hidden from the library user. It is true that if you have a MemoryAddress you can always turn it into something - but here you are writing an high-level API - again, I'm not 100% sure as to what the boundaries of your API are. If your API wraps segments and addresses, then a user, ideally, will not be able to circumvent scopes by creating a segment backed by same address but a different scope. If, on the other hand, your struct abstractions also expose segments and addresses, there is a chance for users to break away from scope restrictions, but they will always need a restricted operation to do so. So, assuming your API is the only "privileged" part running in your system, the user can't mess with scopes, even if it can sees the addresses. > > I'm starting to think of changing to use globalScope() and to mostly > pretend ResourceScope doesn't exist.? For handle-based apis (anonymous > pointers) like OpenCL it's already effectively the case anyway. Of course that decision is up to you. Using globalScope() might be a fine alternative in many cases where native lifecycle is just too hard to track correctly. In this case, it seems to be that you have a clear point where the file is openened, so it seems like there's a clear "scope" associated to the whole set of structures you create, and it would be a bit sad to throw that info away. But it all depends on what are the requirements of your API, and how much you want protect clients from crashing when accessing already freed resources. Is temporal safety important to you? If it is, use MemorySegment and scopes and propagate them and check them as/where needed (and, of course, the API should not make it impossible to do so, but that's a separate discussion); if not, just use MemoryAddress and global scopes (in case you need to temporarily turn an address into a segment). Maurizio > > > On 2/2/22 21:20, Maurizio Cimadamore wrote: >> Hi Michael, >> I understand the concern. Running close actions _after_ the scope is >> closed (and so segments associated with it are inaccessible) is a >> sort of a forced move: you need to run the close actions when you are >> 100% sure that nobody else is accessing the scope. Otherwise you >> might have a race between a close action attempting to free some >> resource and another thread attempting to access it. >> >> The result is that, as you have noticed, adding close actions is >> mostly useful when working with APIs that turn raw MemoryAddress into >> segments manually (MemorySegment::ofAddress). >> > > >> Can you please share a problematic case with ffmpeg? >> >> Thanks >> Maurizio >> >> On 02/02/2022 01:34, Michael Zucchi wrote: >>> >>> Morning, >>> >>> I was hoping to use resource scopes to auto-cleanup native-allocated >>> resources, but it looks like it's going to be a bit messy because >>> segments get closed before their close actions are invoked. >>> >>> Is this the intended behaviour or a side-effect of 'no particular >>> order'? >>> >>> For some api's it doesn't matter as they don't use api-allocated >>> public structures (e.g. opencl) and the same approach is fine using >>> MemoryAddress, but for others it's an issue (e.g. ffmpeg) where the >>> obvious mapping is to use a segment and varhandles. >>> >>> Probably as a workaround - if i want to have this feature at any >>> rate because i'm not sure if it's a good idea yet - i'll just save a >>> copy of the address before it's turned into a segment and pass that >>> to any close function instead. >>> >>> I've only really started looking at seeing how to 'scope' things >>> 'properly' but it feels a bit clumsy and sort of not worth it >>> because it has to be worked around all the time either with hacks >>> like this or resorting to simply using the global scope which >>> effectively does nothing. >>> >>> ?Z >>> >>> > From jboes at openjdk.java.net Thu Feb 3 13:22:33 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 3 Feb 2022 13:22:33 GMT Subject: [foreign-preview] Integrated: 8281147: Other tests that use the foreign API are missing --enable-preview In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 16:25:52 GMT, Julia Boes wrote: > This change adds the --enable-preview flag to tests in other areas (jdk.incubator.vector, java.util.stream) that use the (to be previewed) foreign API, as well as cleaning up the use of a no longer needed proxy class. This pull request has now been integrated. Changeset: 24e45f63 Author: Julia Boes URL: https://git.openjdk.java.net/panama-foreign/commit/24e45f638469abafc598ac43b3fd09731e30a270 Stats: 41 lines in 33 files changed: 34 ins; 1 del; 6 mod 8281147: Other tests that use the foreign API are missing --enable-preview Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/636 From jboes at openjdk.java.net Thu Feb 3 16:23:00 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 3 Feb 2022 16:23:00 GMT Subject: [foreign-preview] RFR: 8280596: ScopedMemoryAccess_closeScope: remove exception parameter Message-ID: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> This change removes the trailing exception parameter in ScopedMemoryAccess_closeScope, which is now unused. (Plus some unrelated minimal doc cleanup that removes mentions of the old SymbolLookup class.) ------------- Commit messages: - some doc fixes - Merge branch 'foreign-preview' into close-scope-remove-param - initial commit Changes: https://git.openjdk.java.net/panama-foreign/pull/637/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=637&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280596 Stats: 14 lines in 4 files changed: 0 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/637.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/637/head:pull/637 PR: https://git.openjdk.java.net/panama-foreign/pull/637 From mcimadamore at openjdk.java.net Thu Feb 3 16:36:26 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Feb 2022 16:36:26 GMT Subject: [foreign-preview] RFR: 8280596: ScopedMemoryAccess_closeScope: remove exception parameter In-Reply-To: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> References: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> Message-ID: On Thu, 3 Feb 2022 16:16:39 GMT, Julia Boes wrote: > This change removes the trailing exception parameter in ScopedMemoryAccess_closeScope, which is now unused. > (Plus some unrelated minimal doc cleanup that removes mentions of the old SymbolLookup class.) src/hotspot/share/prims/scopedMemoryAccess.cpp line 168: > 166: > 167: static JNINativeMethod jdk_internal_misc_ScopedMemoryAccess_methods[] = { > 168: {CC "closeScope0", CC "(" SCOPE ")Z", FN_PTR(ScopedMemoryAccess_closeScope)}, Uhmm - it seems like the method declaration for `ScopedMemoryAccess_closeScope` still has a trailing exception object (further down in this file) ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/637 From jboes at openjdk.java.net Fri Feb 4 09:48:03 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 4 Feb 2022 09:48:03 GMT Subject: [foreign-preview] RFR: 8280596: ScopedMemoryAccess_closeScope: remove exception parameter [v2] In-Reply-To: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> References: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> Message-ID: <1pFgWuXGSwpzV-mtQOWTtaTivU2_4LaIyN5FYTJNpa4=.e83a9527-e628-40bd-b35f-3880ddef721c@github.com> > This change removes the trailing exception parameter in ScopedMemoryAccess_closeScope, which is now unused. > (Plus some unrelated minimal doc cleanup that removes mentions of the old SymbolLookup class.) Julia Boes has updated the pull request incrementally with one additional commit since the last revision: properly remove parameter in JNI code ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/637/files - new: https://git.openjdk.java.net/panama-foreign/pull/637/files/25e14b3c..634709a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=637&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=637&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/637.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/637/head:pull/637 PR: https://git.openjdk.java.net/panama-foreign/pull/637 From jboes at openjdk.java.net Fri Feb 4 09:48:03 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 4 Feb 2022 09:48:03 GMT Subject: [foreign-preview] RFR: 8280596: ScopedMemoryAccess_closeScope: remove exception parameter [v2] In-Reply-To: References: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> Message-ID: On Thu, 3 Feb 2022 16:33:25 GMT, Maurizio Cimadamore wrote: >> Julia Boes has updated the pull request incrementally with one additional commit since the last revision: >> >> properly remove parameter in JNI code > > src/hotspot/share/prims/scopedMemoryAccess.cpp line 168: > >> 166: >> 167: static JNINativeMethod jdk_internal_misc_ScopedMemoryAccess_methods[] = { >> 168: {CC "closeScope0", CC "(" SCOPE ")Z", FN_PTR(ScopedMemoryAccess_closeScope)}, > > Uhmm - it seems like the method declaration for `ScopedMemoryAccess_closeScope` still has a trailing exception object (further down in this file) Oops, thanks for spotting. That's removed now. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/637 From mcimadamore at openjdk.java.net Fri Feb 4 10:40:27 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 10:40:27 GMT Subject: [foreign-preview] RFR: 8280596: ScopedMemoryAccess_closeScope: remove exception parameter [v2] In-Reply-To: <1pFgWuXGSwpzV-mtQOWTtaTivU2_4LaIyN5FYTJNpa4=.e83a9527-e628-40bd-b35f-3880ddef721c@github.com> References: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> <1pFgWuXGSwpzV-mtQOWTtaTivU2_4LaIyN5FYTJNpa4=.e83a9527-e628-40bd-b35f-3880ddef721c@github.com> Message-ID: On Fri, 4 Feb 2022 09:48:03 GMT, Julia Boes wrote: >> This change removes the trailing exception parameter in ScopedMemoryAccess_closeScope, which is now unused. >> (Plus some unrelated minimal doc cleanup that removes mentions of the old SymbolLookup class.) > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > properly remove parameter in JNI code Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/637 From jboes at openjdk.java.net Fri Feb 4 10:46:35 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 4 Feb 2022 10:46:35 GMT Subject: [foreign-preview] Integrated: 8280596: ScopedMemoryAccess_closeScope: remove exception parameter In-Reply-To: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> References: <9YG8IgpwRSiIXLW_TSqk56U_LnNLUCV1PTtEhaaJ-6s=.18a64a5d-bcd0-4d2d-81c9-f30020f81202@github.com> Message-ID: <1LS5XCeLWQyMX7qkzrHfclTMWMg-s-WaZzs7gntZEwI=.9d87e5bd-adfd-45ba-b3a2-1f7832dbb076@github.com> On Thu, 3 Feb 2022 16:16:39 GMT, Julia Boes wrote: > This change removes the trailing exception parameter in ScopedMemoryAccess_closeScope, which is now unused. > (Plus some unrelated minimal doc cleanup that removes mentions of the old SymbolLookup class.) This pull request has now been integrated. Changeset: 50fa91fa Author: Julia Boes URL: https://git.openjdk.java.net/panama-foreign/commit/50fa91faf1f972e6937b114f366541993ca6ae2c Stats: 19 lines in 4 files changed: 0 ins; 5 del; 14 mod 8280596: ScopedMemoryAccess_closeScope: remove exception parameter Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/637 From mcimadamore at openjdk.java.net Fri Feb 4 10:46:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 10:46:47 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm Message-ID: This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. ------------- Commit messages: - Revert frame parameters; fix whitespaces - Fix stack popping in assert code Changes: https://git.openjdk.java.net/panama-foreign/pull/638/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=638&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281228 Stats: 45 lines in 1 file changed: 23 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/638.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/638/head:pull/638 PR: https://git.openjdk.java.net/panama-foreign/pull/638 From sundar at openjdk.java.net Fri Feb 4 10:46:49 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 4 Feb 2022 10:46:49 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 22:23:47 GMT, Maurizio Cimadamore wrote: > This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. > > After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. Should have turn off all assertions (of java.lang.foreign and associated internal package for foreign test runs to catch similar such issues, if any? src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 153: > 151: new BindingSpecializer(mv, callerMethodType, callingSequence, abi, leafHandle.type()).specialize(); > 152: > 153: mv.visitMaxs(-1, -1); visitMaxs arguments are ignored with COMPUTE_FRAMES flag, right? any specific reason for -1, -1 instead of 0, 0? ------------- Marked as reviewed by sundar (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/638 From mcimadamore at openjdk.java.net Fri Feb 4 10:46:50 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 10:46:50 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm In-Reply-To: References: Message-ID: <-MYjm5Geh5q7tfV5cH3o_5l-CHnZf6IrESZG3FySOfU=.e2b87a96-6e05-43a2-be75-df081bb9e6b0@github.com> On Fri, 4 Feb 2022 04:06:15 GMT, Athijegannathan Sundararajan wrote: >> This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. >> >> After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 153: > >> 151: new BindingSpecializer(mv, callerMethodType, callingSequence, abi, leafHandle.type()).specialize(); >> 152: >> 153: mv.visitMaxs(-1, -1); > > visitMaxs arguments are ignored with COMPUTE_FRAMES flag, right? any specific reason for -1, -1 instead of 0, 0? I think you are right. I got confused initially as I thought I've seen another place in this class where -1 was used, and I was trying to experiment making ASM spit the bytecode (and not crash) so that I could look at the actual bytecode :-) This can be reverted ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/638 From duke at openjdk.java.net Fri Feb 4 11:06:01 2022 From: duke at openjdk.java.net (duke) Date: Fri, 4 Feb 2022 11:06:01 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 78 new changesets Message-ID: <8a9c86a7-6530-48b2-9fd6-cc865038feb3@openjdk.org> Changeset: 6de90ad9 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2022-01-28 12:45:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6de90ad9800b83c4a5f364c3645603fcb6828d6c 8280863: Update build README to reflect that MSYS2 is supported Reviewed-by: ihse ! doc/building.html ! doc/building.md Changeset: cb8a82ee Author: Kevin Walls Date: 2022-01-28 12:54:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb8a82ee24881113af4eea04d7ce5963d18e9b83 8272317: jstatd has dependency on Security Manager which needs to be removed Reviewed-by: cjplummer, rriggs ! make/modules/jdk.jstatd/Launcher.gmk ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! test/jdk/sun/tools/jstatd/JstatdTest.java - test/jdk/sun/tools/jstatd/all.policy Changeset: 409382ba Author: Sebastian Stenzel Committer: Anthony Scarpino Date: 2022-01-28 16:42:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/409382ba4b43bf48ed0086020dd20641effd35b6 8280703: CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption Reviewed-by: ascarpino ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java Changeset: 95ee9bf7 Author: Brian Burkhalter Date: 2022-01-28 17:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95ee9bf7be40572e768cf6213c03ca183b8ad886 4774868: (fc spec) Unclear spec for FileChannel.force Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: ff34d624 Author: Daniel D. Daugherty Date: 2022-01-28 18:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff34d624ba81698db0aacc1d5e2332c4345010ce 8280898: ProblemList compiler/regalloc/TestC2IntPressure.java on macosx-aarch64 Reviewed-by: ctornqvi ! test/hotspot/jtreg/ProblemList.txt Changeset: 0740ac47 Author: Chris Plummer Date: 2022-01-28 18:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0740ac474cbda439684223e660827e38964e6b1f 8280555: serviceability/sa/TestObjectMonitorIterate.java is failing due to ObjectMonitor referencing a null Object Reviewed-by: sspitsyn, lmesnik ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java Changeset: 91391598 Author: Denghui Dong Date: 2022-01-28 22:52:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91391598989c70c98b9400997df4f9177d3e576f 8280843: macos-Aarch64 SEGV in frame::sender_for_compiled_frame after JDK-8277948 Reviewed-by: aph, dholmes ! src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/thread_windows_aarch64.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d366d15d Author: Brian Burkhalter Date: 2022-01-28 23:18:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d366d15d67a08833d93a5806edef8145cb7803e5 8280903: javadoc build fails after JDK-4774868 Reviewed-by: lancea ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: 268880b4 Author: Andrey Turbanov Date: 2022-01-29 11:36:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/268880b471eed54535927fba953347160f447fcd 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java Changeset: be9f984c Author: Chris Plummer Date: 2022-01-29 21:35:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be9f984caec32c3fe1deef30efe40fa115409ca0 8280553: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java can fail if GC occurs Reviewed-by: alanb, amenkov ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeArray.java Changeset: 251351f4 Author: Aleksey Shipilev Date: 2022-01-31 08:49:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/251351f49498ea39150b38860b8f73232fbaf05d 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops Reviewed-by: sspitsyn, dcubed ! test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java Changeset: c6ed2046 Author: Andrey Turbanov Date: 2022-01-31 12:11:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c6ed2046b4ba8eafb6b7e934b134829760d56ecd 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/java.base/unix/classes/sun/net/www/protocol/file/Handler.java ! src/java.base/windows/classes/sun/net/www/protocol/file/Handler.java Changeset: 61794c50 Author: Stefan Karlsson Date: 2022-01-31 12:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61794c503973a330278f0595e36be0bd686fe2b5 8280817: Clean up and unify empty VM operations Reviewed-by: shade, coleenp ! src/hotspot/share/runtime/vmOperation.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmThread.cpp ! test/hotspot/gtest/threadHelper.inline.hpp Changeset: 091aff92 Author: Dmitry Batrak Date: 2022-01-31 13:43:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/091aff92e2213bfe0de79b3561a7613ab77e24b6 8278908: [macOS] Unexpected text normalization on pasting from clipboard Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! test/jdk/java/awt/datatransfer/UnicodeTransferTest/UnicodeTransferTest.java Changeset: bdda43e0 Author: Thomas Schatzl Date: 2022-01-31 16:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdda43e066b8da0ebf9a8ef2f843eabb230f0800 8280705: Parallel: Full gc mark stack draining should prefer to make work available to other threads Reviewed-by: ayang, mli ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: dcc666d5 Author: Thomas Schatzl Date: 2022-01-31 16:51:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dcc666d53d66e87c11c0c39858b36d40299b7de6 8280139: Report more detailed statistics about task stealing in task queue stats Reviewed-by: kbarrett, iwalulya ! src/hotspot/share/gc/shared/taskqueue.cpp ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 993a2488 Author: Thomas Schatzl Date: 2022-01-31 16:52:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/993a2488ef42b4c63a7e342c12bba8af8e3fab40 8280450: Add task queue printing to STW Full GCs Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 319b7749 Author: Yumin Qi Date: 2022-01-31 19:27:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/319b77492f78a08b7b9488c73876b027c3076c76 8277101: jcmd VM.cds dynamic_dump should not regenerate holder classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java Changeset: f991891b Author: Xue-Lei Andrew Fan Date: 2022-01-31 20:25:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f991891b0ba7a3767d2abd85ab9b2d284dc3d013 8280949: Correct the references for the Java Security Standard Algorithm Names specification Reviewed-by: mullan ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: 39165613 Author: Ioi Lam Date: 2022-01-31 21:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/39165613aa0430861e361a33a4925b85ea24fff1 8280543: Update the "java" and "jcmd" tool specification for CDS Reviewed-by: hseigel, sspitsyn, ccheung ! src/java.base/share/man/java.1 ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 74921e84 Author: Jonathan Gibbons Date: 2022-01-31 22:45:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74921e8422ce31a22516b279a00935b1917c089d 8280738: Minor cleanup for HtmlStyle Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java Changeset: ee3be0bb Author: Jonathan Gibbons Date: 2022-01-31 22:47:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee3be0bb567f0e28fd3e920ef3685607d0a8d656 8280488: doclint reference checks withstand warning suppression Reviewed-by: darcy ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties + test/langtools/jdk/javadoc/tool/doclint/DocLintReferencesTest.java Changeset: 96d0df72 Author: Jonathan Gibbons Date: 2022-01-31 22:54:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96d0df72db277f127bd4c6b8c51bfc64d1c593e0 8272984: javadoc support for reproducible builds Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java + test/langtools/jdk/javadoc/doclet/testDateOption/TestDateOption.java ! test/langtools/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: 4191b2b9 Author: Igor Veresov Date: 2022-01-31 23:02:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4191b2b9b98c1137e5f27e3b64efb83857fa2c91 8275337: C1: assert(false) failed: live_in set of first block must be empty Reviewed-by: kvn ! src/hotspot/share/c1/c1_RangeCheckElimination.cpp + test/hotspot/jtreg/compiler/c1/Test8275337.java Changeset: 4dbebb62 Author: Joe Darcy Date: 2022-01-31 23:22:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dbebb62aa264adda8d96a06f608ef9d13155a26 8280534: Enable compile-time doclint reference checking Reviewed-by: serb, naoto, mchung, lancea, iris ! make/modules/java.base/Java.gmk ! make/modules/java.datatransfer/Java.gmk ! make/modules/java.logging/Java.gmk ! make/modules/java.management/Java.gmk ! src/java.base/share/classes/java/io/FilenameFilter.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/net/package-info.java ! src/java.base/share/classes/java/text/AttributedCharacterIterator.java ! src/java.base/share/classes/java/text/Bidi.java ! src/java.base/share/classes/java/util/Observable.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/Clipboard.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/LoggingMXBean.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/java.management/share/classes/javax/management/remote/JMXAddressable.java ! src/java.management/share/classes/javax/management/remote/JMXServerErrorException.java Changeset: 9c0104b9 Author: Mandy Chung Date: 2022-02-01 00:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c0104b9c96f012da1602f503f641824d78f4260 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack Reviewed-by: alanb ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c Changeset: 1ea01465 Author: Jonathan Gibbons Date: 2022-02-01 00:31:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ea01465ab06749a3177b9b724ccea0945a2de09 8281007: Test jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java fails after JDK-8280738 Reviewed-by: darcy ! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java Changeset: 0e70d450 Author: Joe Darcy Date: 2022-02-01 01:27:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e70d4504c267174738485c7da82a2ac0ef09770 8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix Reviewed-by: bpb, jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: de3113b9 Author: Michael McMahon Date: 2022-02-01 07:26:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de3113b998550021bb502cd6f766036fb8351e7d 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Co-authored-by: Weijun Wang Reviewed-by: dfuchs, weijun, darcy ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpCallerInfo.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java + src/java.base/share/classes/sun/security/util/ChannelBindingException.java + src/java.base/share/classes/sun/security/util/TlsChannelBinding.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java - src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java ! src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java ! test/jdk/com/sun/jndi/ldap/LdapCBPropertiesTest.java + test/jdk/sun/security/krb5/auto/HttpsCB.java Changeset: 16ec47d5 Author: Albert Mingkun Yang Date: 2022-02-01 08:47:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16ec47d5e5bf129fc0910358464ab62bf6ce7ed8 8279856: Parallel: Use PreservedMarks to record promotion-failed objects Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 18a7dc8c Author: Alexander Zuev Date: 2022-02-01 10:20:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a7dc8c08fa15a260b4a39b18c068d30ee45962 8279586: [macos] custom JCheckBox and JRadioBox with custom icon set: focus is still displayed after unchecking Reviewed-by: serb, azvegint ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java Changeset: d37fb1df Author: Albert Mingkun Yang Date: 2022-02-01 10:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d37fb1df460ec980bd8d3029b1ce7896c3249a99 8280870: Parallel: Simplify CLD roots claim in Full GC cycle Reviewed-by: stefank, sjohanss ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 86debf42 Author: Albert Mingkun Yang Date: 2022-02-01 11:03:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86debf42f545a1aec0a065ebd5b016339a1ae09f 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors Reviewed-by: iwalulya ! src/hotspot/share/gc/g1/g1CodeBlobClosure.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1SharedClosures.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: c5a86120 Author: Albert Mingkun Yang Date: 2022-02-01 12:23:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5a86120df7105cf612d513b5bd394501c00efed 8280458: G1: Remove G1BlockOffsetTablePart::_next_offset_threshold Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 1f6fcbe2 Author: Kim Barrett Date: 2022-02-01 15:44:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f6fcbe2f3da4c63976b1564ec2170e4757fadcc 8278475: G1 dirty card refinement by Java threads may get unnecessarily paused Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp Changeset: 5080e815 Author: Chris Plummer Date: 2022-02-01 15:59:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5080e815b4385751734054b5f889c4d89cfcdeb4 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr Reviewed-by: sspitsyn, dholmes ! test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java Changeset: 4532c3a1 Author: Chris Plummer Date: 2022-02-01 16:02:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4532c3a1639af0b4ff8c4f42c3796fa73ca5be83 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered Reviewed-by: alanb, amenkov, lmesnik ! test/hotspot/jtreg/resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeStringArray.java Changeset: d1cc5fda Author: Thomas Stuefe Date: 2022-02-01 17:19:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1cc5fda8f9fe3480d661985f15c71a8a9a4a7f8 8280941: os::print_memory_mappings() prints segment preceeding the inclusion range Reviewed-by: stefank, minqi ! src/hotspot/os/linux/os_linux.cpp Changeset: bde2b378 Author: Jim Laskey Date: 2022-02-01 18:45:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bde2b3783e0e9787cf2f270fcb3a54c2d4f1e5ab 8279954: java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails Reviewed-by: shade, dholmes ! test/jdk/java/lang/StringBuffer/HugeCapacity.java ! test/jdk/java/lang/StringBuilder/HugeCapacity.java Changeset: d95de5c7 Author: Calvin Cheung Date: 2022-02-01 19:33:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d95de5c7fea4b224d6cd073a6d6921d7108bb7e1 8255495: Support CDS Archived Heap for uncompressed oops Reviewed-by: iklam, tschatzl ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/memory/universe.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/DumpingWithNoCoops.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java Changeset: fdd9ca74 Author: Roger Riggs Date: 2022-02-01 20:13:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdd9ca74bd6ca87c30be2bcdcfd22e19b7687a5a 8280642: ObjectInputStream.readObject should throw InvalidClassException instead of IllegalAccessError Reviewed-by: naoto, mchung ! src/java.base/share/classes/java/io/ObjectInputStream.java ! test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java Changeset: a18beb47 Author: Aleksey Shipilev Date: 2022-02-01 20:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a18beb4797a1ca6fc6b31e997be48b2bd91c6ac0 8280867: Cpuid1Ecx feature parsing is incorrect for AMD CPUs Reviewed-by: kvn, dlong ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: c74b8f48 Author: Boris Ulasevich Date: 2022-02-01 20:56:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c74b8f48fad8380dbd811e4a42c361006e13021d 8275914: SHA3: changing java implementation to help C2 create high-performance code Reviewed-by: ascarpino, phh ! src/java.base/share/classes/sun/security/provider/SHA3.java Changeset: 9ca7ff3e Author: Joe Darcy Date: 2022-02-01 22:30:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ca7ff3e4f0a944bacf38da7e5426082d64c52bd 8281082: Improve javadoc references to JOSS Reviewed-by: iris, rriggs, naoto, lancea ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/Serial.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/security/Key.java ! src/java.base/share/classes/java/security/KeyRep.java Changeset: 85d839fb Author: Chris Plummer Date: 2022-02-01 23:02:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85d839fb4f3f820d130ea95f9a54ae137a95c20a 8280601: ClhsdbThreadContext.java test is triggering codecache related asserts Reviewed-by: kevinw, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java Changeset: d32f99ee Author: Roland Westrelin Date: 2022-02-02 07:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d32f99ee65679601d6e160e7975fc1e367bfa6f4 8279219: [REDO] C2 crash when allocating array of size too large Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/allocation/TestAllocArrayAfterAllocNoUse.java + test/hotspot/jtreg/compiler/allocation/TestCCPAllocateArray.java + test/hotspot/jtreg/compiler/allocation/TestFailedAllocationBadGraph.java Changeset: 97af3230 Author: Roland Westrelin Date: 2022-02-02 07:35:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97af32304101397bb33cbbd1e35fd9124f9e2311 8280842: Access violation in ciTypeFlow::profiled_count Reviewed-by: neliasso, vlivanov, kvn ! src/hotspot/share/ci/ciTypeFlow.cpp + test/hotspot/jtreg/compiler/profiling/TestSharedHeadExceptionBackedges.java Changeset: 48a32b5f Author: Jatin Bhateja Date: 2022-02-02 07:36:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48a32b5f3aa1b238bc9857002325579a5b041685 8280976: Incorrect encoding of avx512 vpsraq instruction with mask and constant shift. Reviewed-by: neliasso, thartmann ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: ab638341 Author: Roland Westrelin Date: 2022-02-02 07:37:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab638341de164965e06bb1d59808670260916b82 8280885: Shenandoah: Some tests failed with "EA: missing allocation reference path" Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestUnexpectedIUBarrierEA.java Changeset: 4304a772 Author: Roland Westrelin Date: 2022-02-02 07:38:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4304a7728ec60f7937e0198c4f85384064fe560e 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after JDK-8276116 Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.cpp Changeset: de826ba1 Author: Roland Westrelin Date: 2022-02-02 08:01:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de826ba18a5e98586029581c2d4bcd27334fbdd1 8280600: C2: assert(!had_error) failed: bad dominance Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead.java Changeset: ae2504b4 Author: Prasanta Sadhukhan Date: 2022-02-02 10:04:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae2504b4692a5298b5835727b04a44e1edc8a4d6 8278254: Cleanup doclint warnings in java.desktop module Reviewed-by: aivanov, serb ! src/java.desktop/share/classes/java/awt/BufferCapabilities.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java ! src/java.desktop/share/classes/javax/swing/JApplet.java ! src/java.desktop/share/classes/javax/swing/JDialog.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/java.desktop/share/classes/javax/swing/text/LayeredHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java ! src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java Changeset: 4ea6037e Author: Albert Mingkun Yang Date: 2022-02-02 10:43:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ea6037ea57ce7bbad00ef172dfc3c122b2317fc 8281035: Serial: Move RemoveForwardedPointerClosure to local scope Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp Changeset: ce71e8b2 Author: Roman Kennke Date: 2022-02-02 14:56:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce71e8b281176d39cc879ae4ecf95f3d643ebd29 8279917: Refactor subclassAudits in Thread to use ClassValue Reviewed-by: alanb, rriggs ! src/java.base/share/classes/java/lang/Thread.java Changeset: 87ab0994 Author: Michael McMahon Date: 2022-02-02 15:04:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87ab0994ded3b535a160bb87b6540bd072042c44 8280944: Enable Unix domain sockets in Windows Selector notification mechanism Reviewed-by: dfuchs, alanb ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java ! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java Changeset: 9d578537 Author: Albert Mingkun Yang Date: 2022-02-02 15:17:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d578537ced356eb0526a70f717b5669e30eadc6 8281042: G1: Remove unused init_threshold in G1FullGCCompactionPoint Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp Changeset: 47800bf3 Author: Daniel Fuchs Date: 2022-02-02 17:11:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47800bf3da181ae0ee612b14d95773fd1dc90350 8280868: LineBodyHandlerTest.java creates and discards too many clients Reviewed-by: michaelm ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java Changeset: e3d5c9e7 Author: Masanori Yano Committer: Lance Andersen Date: 2022-02-02 21:02:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3d5c9e7c4ab210ae7a4417a47632603910744a1 8266974: duplicate property key in java.sql.rowset resource bundle Reviewed-by: lancea ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: fe0118f8 Author: Chris Plummer Date: 2022-02-02 21:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe0118f8040ce7e5e3d605942443e3a5d442fa92 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java Changeset: 2531c332 Author: Tobias Hartmann Date: 2022-02-01 17:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2531c332f89c5faedf71ce1737373581c9abf905 8278871: [JVMCI] assert((uint)reason < 2* _trap_hist_limit) failed: oob Backport-of: 6f0e8da6d3bef340299e48977d5e17d05eabe682 ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: a46307a7 Author: Jesper Wilhelmsson Date: 2022-02-03 01:11:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a46307a79dd6c1f5cca02447b3452be8d1fbe9a0 Merge Changeset: a95ee5ad Author: Xue-Lei Andrew Fan Date: 2022-02-03 06:28:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a95ee5ada230a0177517efd3a417f319066169dd 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/ssl/Utilities.java ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java + test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java + test/jdk/javax/net/ssl/templates/SSLExampleCert.java Changeset: fe547eac Author: Artem Semenov Date: 2022-02-03 07:22:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe547eacd71b4eb8119ecc7ca2d0bbe8e757f854 8280956: Re-examine copyright headers on files in src/java.desktop/macosx/native/libawt_lwawt/awt/a11y Reviewed-by: kizune, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: 5ab22e88 Author: Roman Kennke Date: 2022-02-03 07:24:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ab22e88da8d79f9e19e8afffdd06206f42bab94 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations Reviewed-by: sspitsyn, cjplummer ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Changeset: 63a00a0d Author: Kevin Walls Date: 2022-02-03 10:10:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63a00a0df24b154ef459936dbd69bcd2f0626235 8272777: Clean up remaining AccessController warnings in test library Reviewed-by: rriggs, sspitsyn ! test/lib/jdk/test/lib/SA/SATestUtils.java ! test/lib/jdk/test/lib/net/IPSupport.java ! test/lib/jdk/test/lib/net/SimpleSSLContext.java Changeset: 010965c8 Author: Thomas Stuefe Date: 2022-02-03 14:12:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/010965c86ab39260b882df807c4f5d6420b20ca9 8281023: NMT integration into pp debug command does not work Reviewed-by: zgu, iklam ! src/hotspot/share/services/mallocTracker.cpp ! src/hotspot/share/services/mallocTracker.hpp ! src/hotspot/share/services/virtualMemoryTracker.cpp ! src/hotspot/share/services/virtualMemoryTracker.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 1f926609 Author: Pavel Rappo Date: 2022-02-03 14:55:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f926609372c9b80dde831a014310a3729768c92 8281057: Fix doc references to overriding in JLS Reviewed-by: darcy, iris, dholmes, cjplummer ! src/hotspot/share/oops/klassVtable.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java Changeset: 86c24b31 Author: Alex Menkov Date: 2022-02-03 15:51:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86c24b319ed5e2f0097cfb4b1afe2eb358eb5f75 8240908: RetransformClass does not know about MethodParameters attribute Reviewed-by: cjplummer, sspitsyn ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp + test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java = test/lib/jdk/test/lib/util/ClassTransformer.java Changeset: cda9c301 Author: Yumin Qi Date: 2022-02-03 18:02:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cda9c3011beeec8df68e78e096132e712255ce1b 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call Reviewed-by: dholmes, stuefe ! make/data/hotspot-symbols/symbols-unix ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp Changeset: 130cf46d Author: Brian Burkhalter Date: 2022-02-03 19:12:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/130cf46dcb7b089fcf4a4e950cdc701513f7b53f 4750574: (se spec) Selector spec should clarify calculation of select return value Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/Selector.java Changeset: b6935dfb Author: Yi-Fan Tsai Committer: Paul Hohensee Date: 2022-02-03 19:34:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6935dfb86a1c011355d2dfb2140be26ec536351 8251505: Use of types in compiler shared code should be consistent. Reviewed-by: phh ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/sweeper.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: e44dc638 Author: Dean Long Date: 2022-02-03 22:10:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e44dc638b8936b1b76ca9ddf9ece0c5c4705a19c 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack Co-authored-by: Yi Yang Co-authored-by: Yi Yang Reviewed-by: vlivanov, thartmann ! src/hotspot/share/runtime/deoptimization.cpp + test/hotspot/jtreg/compiler/interpreter/Custom.jasm + test/hotspot/jtreg/compiler/interpreter/VerifyStackWithUnreachableBlock.java Changeset: 63e11cfa Author: Andrey Turbanov Date: 2022-02-04 07:08:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63e11cfa3f887515ca36ab5147c3e6fa540978d3 8280970: Cleanup dead code in java.security.Provider Reviewed-by: valeriep ! src/java.base/share/classes/java/security/Provider.java Changeset: c936e705 Author: Richard Reingruber Date: 2022-02-04 07:57:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c936e7059b848d0e0be5f3234c4367657f2af2a7 8280593: [PPC64, S390] redundant allocation of MacroAssembler in StubGenerator ctor Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/s390/stubGenerator_s390.cpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp Changeset: 46c6c6f3 Author: Martin Doerr Date: 2022-02-04 09:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46c6c6f308b5ec0ec3b762df4b76de555287474c 8281043: Intrinsify recursive ObjectMonitor locking for PPC64 Reviewed-by: rrich, lucy ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Changeset: 51b53a82 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 10:51:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51b53a821bb3cfb962f80a637f5fb8cde988975a 8280913: Create a regression test for JRootPane.setDefaultButton() method Reviewed-by: aivanov + test/jdk/javax/swing/JRootPane/DefaultButtonTest.java Changeset: 396829b2 Author: duke Date: 2022-02-04 11:00:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396829b2d1a5d9248c4afa0dab598614c77a54ee Automatic merge of jdk:master into master Changeset: 94812205 Author: duke Date: 2022-02-04 11:01:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/948122059f12a377af6252cec172058f12933a1f Automatic merge of master into foreign-memaccess+abi ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp From duke at openjdk.java.net Fri Feb 4 11:10:37 2022 From: duke at openjdk.java.net (duke) Date: Fri, 4 Feb 2022 11:10:37 GMT Subject: git: openjdk/panama-foreign: master: 77 new changesets Message-ID: <4c617ffa-03ee-4f32-adf4-3a4f254ca6d7@openjdk.org> Changeset: 6de90ad9 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2022-01-28 12:45:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6de90ad9800b83c4a5f364c3645603fcb6828d6c 8280863: Update build README to reflect that MSYS2 is supported Reviewed-by: ihse ! doc/building.html ! doc/building.md Changeset: cb8a82ee Author: Kevin Walls Date: 2022-01-28 12:54:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb8a82ee24881113af4eea04d7ce5963d18e9b83 8272317: jstatd has dependency on Security Manager which needs to be removed Reviewed-by: cjplummer, rriggs ! make/modules/jdk.jstatd/Launcher.gmk ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! test/jdk/sun/tools/jstatd/JstatdTest.java - test/jdk/sun/tools/jstatd/all.policy Changeset: 409382ba Author: Sebastian Stenzel Committer: Anthony Scarpino Date: 2022-01-28 16:42:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/409382ba4b43bf48ed0086020dd20641effd35b6 8280703: CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption Reviewed-by: ascarpino ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java Changeset: 95ee9bf7 Author: Brian Burkhalter Date: 2022-01-28 17:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95ee9bf7be40572e768cf6213c03ca183b8ad886 4774868: (fc spec) Unclear spec for FileChannel.force Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: ff34d624 Author: Daniel D. Daugherty Date: 2022-01-28 18:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff34d624ba81698db0aacc1d5e2332c4345010ce 8280898: ProblemList compiler/regalloc/TestC2IntPressure.java on macosx-aarch64 Reviewed-by: ctornqvi ! test/hotspot/jtreg/ProblemList.txt Changeset: 0740ac47 Author: Chris Plummer Date: 2022-01-28 18:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0740ac474cbda439684223e660827e38964e6b1f 8280555: serviceability/sa/TestObjectMonitorIterate.java is failing due to ObjectMonitor referencing a null Object Reviewed-by: sspitsyn, lmesnik ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java Changeset: 91391598 Author: Denghui Dong Date: 2022-01-28 22:52:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91391598989c70c98b9400997df4f9177d3e576f 8280843: macos-Aarch64 SEGV in frame::sender_for_compiled_frame after JDK-8277948 Reviewed-by: aph, dholmes ! src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/thread_windows_aarch64.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d366d15d Author: Brian Burkhalter Date: 2022-01-28 23:18:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d366d15d67a08833d93a5806edef8145cb7803e5 8280903: javadoc build fails after JDK-4774868 Reviewed-by: lancea ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: 268880b4 Author: Andrey Turbanov Date: 2022-01-29 11:36:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/268880b471eed54535927fba953347160f447fcd 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java Changeset: be9f984c Author: Chris Plummer Date: 2022-01-29 21:35:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be9f984caec32c3fe1deef30efe40fa115409ca0 8280553: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java can fail if GC occurs Reviewed-by: alanb, amenkov ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeArray.java Changeset: 251351f4 Author: Aleksey Shipilev Date: 2022-01-31 08:49:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/251351f49498ea39150b38860b8f73232fbaf05d 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops Reviewed-by: sspitsyn, dcubed ! test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java Changeset: c6ed2046 Author: Andrey Turbanov Date: 2022-01-31 12:11:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c6ed2046b4ba8eafb6b7e934b134829760d56ecd 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/java.base/unix/classes/sun/net/www/protocol/file/Handler.java ! src/java.base/windows/classes/sun/net/www/protocol/file/Handler.java Changeset: 61794c50 Author: Stefan Karlsson Date: 2022-01-31 12:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61794c503973a330278f0595e36be0bd686fe2b5 8280817: Clean up and unify empty VM operations Reviewed-by: shade, coleenp ! src/hotspot/share/runtime/vmOperation.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmThread.cpp ! test/hotspot/gtest/threadHelper.inline.hpp Changeset: 091aff92 Author: Dmitry Batrak Date: 2022-01-31 13:43:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/091aff92e2213bfe0de79b3561a7613ab77e24b6 8278908: [macOS] Unexpected text normalization on pasting from clipboard Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! test/jdk/java/awt/datatransfer/UnicodeTransferTest/UnicodeTransferTest.java Changeset: bdda43e0 Author: Thomas Schatzl Date: 2022-01-31 16:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdda43e066b8da0ebf9a8ef2f843eabb230f0800 8280705: Parallel: Full gc mark stack draining should prefer to make work available to other threads Reviewed-by: ayang, mli ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: dcc666d5 Author: Thomas Schatzl Date: 2022-01-31 16:51:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dcc666d53d66e87c11c0c39858b36d40299b7de6 8280139: Report more detailed statistics about task stealing in task queue stats Reviewed-by: kbarrett, iwalulya ! src/hotspot/share/gc/shared/taskqueue.cpp ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 993a2488 Author: Thomas Schatzl Date: 2022-01-31 16:52:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/993a2488ef42b4c63a7e342c12bba8af8e3fab40 8280450: Add task queue printing to STW Full GCs Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 319b7749 Author: Yumin Qi Date: 2022-01-31 19:27:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/319b77492f78a08b7b9488c73876b027c3076c76 8277101: jcmd VM.cds dynamic_dump should not regenerate holder classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java Changeset: f991891b Author: Xue-Lei Andrew Fan Date: 2022-01-31 20:25:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f991891b0ba7a3767d2abd85ab9b2d284dc3d013 8280949: Correct the references for the Java Security Standard Algorithm Names specification Reviewed-by: mullan ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: 39165613 Author: Ioi Lam Date: 2022-01-31 21:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/39165613aa0430861e361a33a4925b85ea24fff1 8280543: Update the "java" and "jcmd" tool specification for CDS Reviewed-by: hseigel, sspitsyn, ccheung ! src/java.base/share/man/java.1 ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 74921e84 Author: Jonathan Gibbons Date: 2022-01-31 22:45:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74921e8422ce31a22516b279a00935b1917c089d 8280738: Minor cleanup for HtmlStyle Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java Changeset: ee3be0bb Author: Jonathan Gibbons Date: 2022-01-31 22:47:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee3be0bb567f0e28fd3e920ef3685607d0a8d656 8280488: doclint reference checks withstand warning suppression Reviewed-by: darcy ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties + test/langtools/jdk/javadoc/tool/doclint/DocLintReferencesTest.java Changeset: 96d0df72 Author: Jonathan Gibbons Date: 2022-01-31 22:54:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96d0df72db277f127bd4c6b8c51bfc64d1c593e0 8272984: javadoc support for reproducible builds Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java + test/langtools/jdk/javadoc/doclet/testDateOption/TestDateOption.java ! test/langtools/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: 4191b2b9 Author: Igor Veresov Date: 2022-01-31 23:02:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4191b2b9b98c1137e5f27e3b64efb83857fa2c91 8275337: C1: assert(false) failed: live_in set of first block must be empty Reviewed-by: kvn ! src/hotspot/share/c1/c1_RangeCheckElimination.cpp + test/hotspot/jtreg/compiler/c1/Test8275337.java Changeset: 4dbebb62 Author: Joe Darcy Date: 2022-01-31 23:22:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dbebb62aa264adda8d96a06f608ef9d13155a26 8280534: Enable compile-time doclint reference checking Reviewed-by: serb, naoto, mchung, lancea, iris ! make/modules/java.base/Java.gmk ! make/modules/java.datatransfer/Java.gmk ! make/modules/java.logging/Java.gmk ! make/modules/java.management/Java.gmk ! src/java.base/share/classes/java/io/FilenameFilter.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/net/package-info.java ! src/java.base/share/classes/java/text/AttributedCharacterIterator.java ! src/java.base/share/classes/java/text/Bidi.java ! src/java.base/share/classes/java/util/Observable.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/Clipboard.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/LoggingMXBean.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/java.management/share/classes/javax/management/remote/JMXAddressable.java ! src/java.management/share/classes/javax/management/remote/JMXServerErrorException.java Changeset: 9c0104b9 Author: Mandy Chung Date: 2022-02-01 00:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c0104b9c96f012da1602f503f641824d78f4260 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack Reviewed-by: alanb ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c Changeset: 1ea01465 Author: Jonathan Gibbons Date: 2022-02-01 00:31:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ea01465ab06749a3177b9b724ccea0945a2de09 8281007: Test jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java fails after JDK-8280738 Reviewed-by: darcy ! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java Changeset: 0e70d450 Author: Joe Darcy Date: 2022-02-01 01:27:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e70d4504c267174738485c7da82a2ac0ef09770 8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix Reviewed-by: bpb, jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: de3113b9 Author: Michael McMahon Date: 2022-02-01 07:26:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de3113b998550021bb502cd6f766036fb8351e7d 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Co-authored-by: Weijun Wang Reviewed-by: dfuchs, weijun, darcy ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpCallerInfo.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java + src/java.base/share/classes/sun/security/util/ChannelBindingException.java + src/java.base/share/classes/sun/security/util/TlsChannelBinding.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java - src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java ! src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java ! test/jdk/com/sun/jndi/ldap/LdapCBPropertiesTest.java + test/jdk/sun/security/krb5/auto/HttpsCB.java Changeset: 16ec47d5 Author: Albert Mingkun Yang Date: 2022-02-01 08:47:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16ec47d5e5bf129fc0910358464ab62bf6ce7ed8 8279856: Parallel: Use PreservedMarks to record promotion-failed objects Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 18a7dc8c Author: Alexander Zuev Date: 2022-02-01 10:20:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a7dc8c08fa15a260b4a39b18c068d30ee45962 8279586: [macos] custom JCheckBox and JRadioBox with custom icon set: focus is still displayed after unchecking Reviewed-by: serb, azvegint ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java Changeset: d37fb1df Author: Albert Mingkun Yang Date: 2022-02-01 10:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d37fb1df460ec980bd8d3029b1ce7896c3249a99 8280870: Parallel: Simplify CLD roots claim in Full GC cycle Reviewed-by: stefank, sjohanss ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 86debf42 Author: Albert Mingkun Yang Date: 2022-02-01 11:03:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86debf42f545a1aec0a065ebd5b016339a1ae09f 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors Reviewed-by: iwalulya ! src/hotspot/share/gc/g1/g1CodeBlobClosure.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1SharedClosures.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: c5a86120 Author: Albert Mingkun Yang Date: 2022-02-01 12:23:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5a86120df7105cf612d513b5bd394501c00efed 8280458: G1: Remove G1BlockOffsetTablePart::_next_offset_threshold Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 1f6fcbe2 Author: Kim Barrett Date: 2022-02-01 15:44:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f6fcbe2f3da4c63976b1564ec2170e4757fadcc 8278475: G1 dirty card refinement by Java threads may get unnecessarily paused Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp Changeset: 5080e815 Author: Chris Plummer Date: 2022-02-01 15:59:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5080e815b4385751734054b5f889c4d89cfcdeb4 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr Reviewed-by: sspitsyn, dholmes ! test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java Changeset: 4532c3a1 Author: Chris Plummer Date: 2022-02-01 16:02:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4532c3a1639af0b4ff8c4f42c3796fa73ca5be83 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered Reviewed-by: alanb, amenkov, lmesnik ! test/hotspot/jtreg/resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeStringArray.java Changeset: d1cc5fda Author: Thomas Stuefe Date: 2022-02-01 17:19:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1cc5fda8f9fe3480d661985f15c71a8a9a4a7f8 8280941: os::print_memory_mappings() prints segment preceeding the inclusion range Reviewed-by: stefank, minqi ! src/hotspot/os/linux/os_linux.cpp Changeset: bde2b378 Author: Jim Laskey Date: 2022-02-01 18:45:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bde2b3783e0e9787cf2f270fcb3a54c2d4f1e5ab 8279954: java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails Reviewed-by: shade, dholmes ! test/jdk/java/lang/StringBuffer/HugeCapacity.java ! test/jdk/java/lang/StringBuilder/HugeCapacity.java Changeset: d95de5c7 Author: Calvin Cheung Date: 2022-02-01 19:33:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d95de5c7fea4b224d6cd073a6d6921d7108bb7e1 8255495: Support CDS Archived Heap for uncompressed oops Reviewed-by: iklam, tschatzl ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/memory/universe.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/DumpingWithNoCoops.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java Changeset: fdd9ca74 Author: Roger Riggs Date: 2022-02-01 20:13:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdd9ca74bd6ca87c30be2bcdcfd22e19b7687a5a 8280642: ObjectInputStream.readObject should throw InvalidClassException instead of IllegalAccessError Reviewed-by: naoto, mchung ! src/java.base/share/classes/java/io/ObjectInputStream.java ! test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java Changeset: a18beb47 Author: Aleksey Shipilev Date: 2022-02-01 20:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a18beb4797a1ca6fc6b31e997be48b2bd91c6ac0 8280867: Cpuid1Ecx feature parsing is incorrect for AMD CPUs Reviewed-by: kvn, dlong ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: c74b8f48 Author: Boris Ulasevich Date: 2022-02-01 20:56:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c74b8f48fad8380dbd811e4a42c361006e13021d 8275914: SHA3: changing java implementation to help C2 create high-performance code Reviewed-by: ascarpino, phh ! src/java.base/share/classes/sun/security/provider/SHA3.java Changeset: 9ca7ff3e Author: Joe Darcy Date: 2022-02-01 22:30:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ca7ff3e4f0a944bacf38da7e5426082d64c52bd 8281082: Improve javadoc references to JOSS Reviewed-by: iris, rriggs, naoto, lancea ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/Serial.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/security/Key.java ! src/java.base/share/classes/java/security/KeyRep.java Changeset: 85d839fb Author: Chris Plummer Date: 2022-02-01 23:02:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85d839fb4f3f820d130ea95f9a54ae137a95c20a 8280601: ClhsdbThreadContext.java test is triggering codecache related asserts Reviewed-by: kevinw, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java Changeset: d32f99ee Author: Roland Westrelin Date: 2022-02-02 07:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d32f99ee65679601d6e160e7975fc1e367bfa6f4 8279219: [REDO] C2 crash when allocating array of size too large Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/allocation/TestAllocArrayAfterAllocNoUse.java + test/hotspot/jtreg/compiler/allocation/TestCCPAllocateArray.java + test/hotspot/jtreg/compiler/allocation/TestFailedAllocationBadGraph.java Changeset: 97af3230 Author: Roland Westrelin Date: 2022-02-02 07:35:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97af32304101397bb33cbbd1e35fd9124f9e2311 8280842: Access violation in ciTypeFlow::profiled_count Reviewed-by: neliasso, vlivanov, kvn ! src/hotspot/share/ci/ciTypeFlow.cpp + test/hotspot/jtreg/compiler/profiling/TestSharedHeadExceptionBackedges.java Changeset: 48a32b5f Author: Jatin Bhateja Date: 2022-02-02 07:36:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48a32b5f3aa1b238bc9857002325579a5b041685 8280976: Incorrect encoding of avx512 vpsraq instruction with mask and constant shift. Reviewed-by: neliasso, thartmann ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: ab638341 Author: Roland Westrelin Date: 2022-02-02 07:37:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab638341de164965e06bb1d59808670260916b82 8280885: Shenandoah: Some tests failed with "EA: missing allocation reference path" Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestUnexpectedIUBarrierEA.java Changeset: 4304a772 Author: Roland Westrelin Date: 2022-02-02 07:38:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4304a7728ec60f7937e0198c4f85384064fe560e 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after JDK-8276116 Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.cpp Changeset: de826ba1 Author: Roland Westrelin Date: 2022-02-02 08:01:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de826ba18a5e98586029581c2d4bcd27334fbdd1 8280600: C2: assert(!had_error) failed: bad dominance Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead.java Changeset: ae2504b4 Author: Prasanta Sadhukhan Date: 2022-02-02 10:04:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae2504b4692a5298b5835727b04a44e1edc8a4d6 8278254: Cleanup doclint warnings in java.desktop module Reviewed-by: aivanov, serb ! src/java.desktop/share/classes/java/awt/BufferCapabilities.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java ! src/java.desktop/share/classes/javax/swing/JApplet.java ! src/java.desktop/share/classes/javax/swing/JDialog.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/java.desktop/share/classes/javax/swing/text/LayeredHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java ! src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java Changeset: 4ea6037e Author: Albert Mingkun Yang Date: 2022-02-02 10:43:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ea6037ea57ce7bbad00ef172dfc3c122b2317fc 8281035: Serial: Move RemoveForwardedPointerClosure to local scope Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp Changeset: ce71e8b2 Author: Roman Kennke Date: 2022-02-02 14:56:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce71e8b281176d39cc879ae4ecf95f3d643ebd29 8279917: Refactor subclassAudits in Thread to use ClassValue Reviewed-by: alanb, rriggs ! src/java.base/share/classes/java/lang/Thread.java Changeset: 87ab0994 Author: Michael McMahon Date: 2022-02-02 15:04:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87ab0994ded3b535a160bb87b6540bd072042c44 8280944: Enable Unix domain sockets in Windows Selector notification mechanism Reviewed-by: dfuchs, alanb ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java ! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java Changeset: 9d578537 Author: Albert Mingkun Yang Date: 2022-02-02 15:17:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d578537ced356eb0526a70f717b5669e30eadc6 8281042: G1: Remove unused init_threshold in G1FullGCCompactionPoint Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp Changeset: 47800bf3 Author: Daniel Fuchs Date: 2022-02-02 17:11:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47800bf3da181ae0ee612b14d95773fd1dc90350 8280868: LineBodyHandlerTest.java creates and discards too many clients Reviewed-by: michaelm ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java Changeset: e3d5c9e7 Author: Masanori Yano Committer: Lance Andersen Date: 2022-02-02 21:02:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3d5c9e7c4ab210ae7a4417a47632603910744a1 8266974: duplicate property key in java.sql.rowset resource bundle Reviewed-by: lancea ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: fe0118f8 Author: Chris Plummer Date: 2022-02-02 21:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe0118f8040ce7e5e3d605942443e3a5d442fa92 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java Changeset: 2531c332 Author: Tobias Hartmann Date: 2022-02-01 17:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2531c332f89c5faedf71ce1737373581c9abf905 8278871: [JVMCI] assert((uint)reason < 2* _trap_hist_limit) failed: oob Backport-of: 6f0e8da6d3bef340299e48977d5e17d05eabe682 ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: a46307a7 Author: Jesper Wilhelmsson Date: 2022-02-03 01:11:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a46307a79dd6c1f5cca02447b3452be8d1fbe9a0 Merge Changeset: a95ee5ad Author: Xue-Lei Andrew Fan Date: 2022-02-03 06:28:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a95ee5ada230a0177517efd3a417f319066169dd 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/ssl/Utilities.java ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java + test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java + test/jdk/javax/net/ssl/templates/SSLExampleCert.java Changeset: fe547eac Author: Artem Semenov Date: 2022-02-03 07:22:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe547eacd71b4eb8119ecc7ca2d0bbe8e757f854 8280956: Re-examine copyright headers on files in src/java.desktop/macosx/native/libawt_lwawt/awt/a11y Reviewed-by: kizune, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: 5ab22e88 Author: Roman Kennke Date: 2022-02-03 07:24:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ab22e88da8d79f9e19e8afffdd06206f42bab94 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations Reviewed-by: sspitsyn, cjplummer ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Changeset: 63a00a0d Author: Kevin Walls Date: 2022-02-03 10:10:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63a00a0df24b154ef459936dbd69bcd2f0626235 8272777: Clean up remaining AccessController warnings in test library Reviewed-by: rriggs, sspitsyn ! test/lib/jdk/test/lib/SA/SATestUtils.java ! test/lib/jdk/test/lib/net/IPSupport.java ! test/lib/jdk/test/lib/net/SimpleSSLContext.java Changeset: 010965c8 Author: Thomas Stuefe Date: 2022-02-03 14:12:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/010965c86ab39260b882df807c4f5d6420b20ca9 8281023: NMT integration into pp debug command does not work Reviewed-by: zgu, iklam ! src/hotspot/share/services/mallocTracker.cpp ! src/hotspot/share/services/mallocTracker.hpp ! src/hotspot/share/services/virtualMemoryTracker.cpp ! src/hotspot/share/services/virtualMemoryTracker.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 1f926609 Author: Pavel Rappo Date: 2022-02-03 14:55:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f926609372c9b80dde831a014310a3729768c92 8281057: Fix doc references to overriding in JLS Reviewed-by: darcy, iris, dholmes, cjplummer ! src/hotspot/share/oops/klassVtable.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java Changeset: 86c24b31 Author: Alex Menkov Date: 2022-02-03 15:51:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86c24b319ed5e2f0097cfb4b1afe2eb358eb5f75 8240908: RetransformClass does not know about MethodParameters attribute Reviewed-by: cjplummer, sspitsyn ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp + test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java = test/lib/jdk/test/lib/util/ClassTransformer.java Changeset: cda9c301 Author: Yumin Qi Date: 2022-02-03 18:02:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cda9c3011beeec8df68e78e096132e712255ce1b 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call Reviewed-by: dholmes, stuefe ! make/data/hotspot-symbols/symbols-unix ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp Changeset: 130cf46d Author: Brian Burkhalter Date: 2022-02-03 19:12:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/130cf46dcb7b089fcf4a4e950cdc701513f7b53f 4750574: (se spec) Selector spec should clarify calculation of select return value Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/Selector.java Changeset: b6935dfb Author: Yi-Fan Tsai Committer: Paul Hohensee Date: 2022-02-03 19:34:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6935dfb86a1c011355d2dfb2140be26ec536351 8251505: Use of types in compiler shared code should be consistent. Reviewed-by: phh ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/sweeper.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: e44dc638 Author: Dean Long Date: 2022-02-03 22:10:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e44dc638b8936b1b76ca9ddf9ece0c5c4705a19c 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack Co-authored-by: Yi Yang Co-authored-by: Yi Yang Reviewed-by: vlivanov, thartmann ! src/hotspot/share/runtime/deoptimization.cpp + test/hotspot/jtreg/compiler/interpreter/Custom.jasm + test/hotspot/jtreg/compiler/interpreter/VerifyStackWithUnreachableBlock.java Changeset: 63e11cfa Author: Andrey Turbanov Date: 2022-02-04 07:08:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63e11cfa3f887515ca36ab5147c3e6fa540978d3 8280970: Cleanup dead code in java.security.Provider Reviewed-by: valeriep ! src/java.base/share/classes/java/security/Provider.java Changeset: c936e705 Author: Richard Reingruber Date: 2022-02-04 07:57:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c936e7059b848d0e0be5f3234c4367657f2af2a7 8280593: [PPC64, S390] redundant allocation of MacroAssembler in StubGenerator ctor Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/s390/stubGenerator_s390.cpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp Changeset: 46c6c6f3 Author: Martin Doerr Date: 2022-02-04 09:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46c6c6f308b5ec0ec3b762df4b76de555287474c 8281043: Intrinsify recursive ObjectMonitor locking for PPC64 Reviewed-by: rrich, lucy ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Changeset: 51b53a82 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 10:51:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51b53a821bb3cfb962f80a637f5fb8cde988975a 8280913: Create a regression test for JRootPane.setDefaultButton() method Reviewed-by: aivanov + test/jdk/javax/swing/JRootPane/DefaultButtonTest.java Changeset: 396829b2 Author: duke Date: 2022-02-04 11:00:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396829b2d1a5d9248c4afa0dab598614c77a54ee Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Feb 4 11:16:52 2022 From: duke at openjdk.java.net (duke) Date: Fri, 4 Feb 2022 11:16:52 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 79 new changesets Message-ID: <968fc785-1a07-4060-8be5-e9e964e0815d@openjdk.org> Changeset: 6de90ad9 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2022-01-28 12:45:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6de90ad9800b83c4a5f364c3645603fcb6828d6c 8280863: Update build README to reflect that MSYS2 is supported Reviewed-by: ihse ! doc/building.html ! doc/building.md Changeset: cb8a82ee Author: Kevin Walls Date: 2022-01-28 12:54:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb8a82ee24881113af4eea04d7ce5963d18e9b83 8272317: jstatd has dependency on Security Manager which needs to be removed Reviewed-by: cjplummer, rriggs ! make/modules/jdk.jstatd/Launcher.gmk ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! test/jdk/sun/tools/jstatd/JstatdTest.java - test/jdk/sun/tools/jstatd/all.policy Changeset: 409382ba Author: Sebastian Stenzel Committer: Anthony Scarpino Date: 2022-01-28 16:42:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/409382ba4b43bf48ed0086020dd20641effd35b6 8280703: CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption Reviewed-by: ascarpino ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java Changeset: 95ee9bf7 Author: Brian Burkhalter Date: 2022-01-28 17:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95ee9bf7be40572e768cf6213c03ca183b8ad886 4774868: (fc spec) Unclear spec for FileChannel.force Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: ff34d624 Author: Daniel D. Daugherty Date: 2022-01-28 18:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff34d624ba81698db0aacc1d5e2332c4345010ce 8280898: ProblemList compiler/regalloc/TestC2IntPressure.java on macosx-aarch64 Reviewed-by: ctornqvi ! test/hotspot/jtreg/ProblemList.txt Changeset: 0740ac47 Author: Chris Plummer Date: 2022-01-28 18:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0740ac474cbda439684223e660827e38964e6b1f 8280555: serviceability/sa/TestObjectMonitorIterate.java is failing due to ObjectMonitor referencing a null Object Reviewed-by: sspitsyn, lmesnik ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java Changeset: 91391598 Author: Denghui Dong Date: 2022-01-28 22:52:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91391598989c70c98b9400997df4f9177d3e576f 8280843: macos-Aarch64 SEGV in frame::sender_for_compiled_frame after JDK-8277948 Reviewed-by: aph, dholmes ! src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/thread_windows_aarch64.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d366d15d Author: Brian Burkhalter Date: 2022-01-28 23:18:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d366d15d67a08833d93a5806edef8145cb7803e5 8280903: javadoc build fails after JDK-4774868 Reviewed-by: lancea ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: 268880b4 Author: Andrey Turbanov Date: 2022-01-29 11:36:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/268880b471eed54535927fba953347160f447fcd 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java Changeset: be9f984c Author: Chris Plummer Date: 2022-01-29 21:35:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be9f984caec32c3fe1deef30efe40fa115409ca0 8280553: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java can fail if GC occurs Reviewed-by: alanb, amenkov ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeArray.java Changeset: 251351f4 Author: Aleksey Shipilev Date: 2022-01-31 08:49:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/251351f49498ea39150b38860b8f73232fbaf05d 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops Reviewed-by: sspitsyn, dcubed ! test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java Changeset: c6ed2046 Author: Andrey Turbanov Date: 2022-01-31 12:11:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c6ed2046b4ba8eafb6b7e934b134829760d56ecd 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/java.base/unix/classes/sun/net/www/protocol/file/Handler.java ! src/java.base/windows/classes/sun/net/www/protocol/file/Handler.java Changeset: 61794c50 Author: Stefan Karlsson Date: 2022-01-31 12:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61794c503973a330278f0595e36be0bd686fe2b5 8280817: Clean up and unify empty VM operations Reviewed-by: shade, coleenp ! src/hotspot/share/runtime/vmOperation.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmThread.cpp ! test/hotspot/gtest/threadHelper.inline.hpp Changeset: 091aff92 Author: Dmitry Batrak Date: 2022-01-31 13:43:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/091aff92e2213bfe0de79b3561a7613ab77e24b6 8278908: [macOS] Unexpected text normalization on pasting from clipboard Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! test/jdk/java/awt/datatransfer/UnicodeTransferTest/UnicodeTransferTest.java Changeset: bdda43e0 Author: Thomas Schatzl Date: 2022-01-31 16:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdda43e066b8da0ebf9a8ef2f843eabb230f0800 8280705: Parallel: Full gc mark stack draining should prefer to make work available to other threads Reviewed-by: ayang, mli ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: dcc666d5 Author: Thomas Schatzl Date: 2022-01-31 16:51:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dcc666d53d66e87c11c0c39858b36d40299b7de6 8280139: Report more detailed statistics about task stealing in task queue stats Reviewed-by: kbarrett, iwalulya ! src/hotspot/share/gc/shared/taskqueue.cpp ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 993a2488 Author: Thomas Schatzl Date: 2022-01-31 16:52:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/993a2488ef42b4c63a7e342c12bba8af8e3fab40 8280450: Add task queue printing to STW Full GCs Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 319b7749 Author: Yumin Qi Date: 2022-01-31 19:27:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/319b77492f78a08b7b9488c73876b027c3076c76 8277101: jcmd VM.cds dynamic_dump should not regenerate holder classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java Changeset: f991891b Author: Xue-Lei Andrew Fan Date: 2022-01-31 20:25:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f991891b0ba7a3767d2abd85ab9b2d284dc3d013 8280949: Correct the references for the Java Security Standard Algorithm Names specification Reviewed-by: mullan ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: 39165613 Author: Ioi Lam Date: 2022-01-31 21:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/39165613aa0430861e361a33a4925b85ea24fff1 8280543: Update the "java" and "jcmd" tool specification for CDS Reviewed-by: hseigel, sspitsyn, ccheung ! src/java.base/share/man/java.1 ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 74921e84 Author: Jonathan Gibbons Date: 2022-01-31 22:45:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74921e8422ce31a22516b279a00935b1917c089d 8280738: Minor cleanup for HtmlStyle Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java Changeset: ee3be0bb Author: Jonathan Gibbons Date: 2022-01-31 22:47:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee3be0bb567f0e28fd3e920ef3685607d0a8d656 8280488: doclint reference checks withstand warning suppression Reviewed-by: darcy ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties + test/langtools/jdk/javadoc/tool/doclint/DocLintReferencesTest.java Changeset: 96d0df72 Author: Jonathan Gibbons Date: 2022-01-31 22:54:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96d0df72db277f127bd4c6b8c51bfc64d1c593e0 8272984: javadoc support for reproducible builds Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java + test/langtools/jdk/javadoc/doclet/testDateOption/TestDateOption.java ! test/langtools/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: 4191b2b9 Author: Igor Veresov Date: 2022-01-31 23:02:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4191b2b9b98c1137e5f27e3b64efb83857fa2c91 8275337: C1: assert(false) failed: live_in set of first block must be empty Reviewed-by: kvn ! src/hotspot/share/c1/c1_RangeCheckElimination.cpp + test/hotspot/jtreg/compiler/c1/Test8275337.java Changeset: 4dbebb62 Author: Joe Darcy Date: 2022-01-31 23:22:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dbebb62aa264adda8d96a06f608ef9d13155a26 8280534: Enable compile-time doclint reference checking Reviewed-by: serb, naoto, mchung, lancea, iris ! make/modules/java.base/Java.gmk ! make/modules/java.datatransfer/Java.gmk ! make/modules/java.logging/Java.gmk ! make/modules/java.management/Java.gmk ! src/java.base/share/classes/java/io/FilenameFilter.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/net/package-info.java ! src/java.base/share/classes/java/text/AttributedCharacterIterator.java ! src/java.base/share/classes/java/text/Bidi.java ! src/java.base/share/classes/java/util/Observable.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/Clipboard.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/LoggingMXBean.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/java.management/share/classes/javax/management/remote/JMXAddressable.java ! src/java.management/share/classes/javax/management/remote/JMXServerErrorException.java Changeset: 9c0104b9 Author: Mandy Chung Date: 2022-02-01 00:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c0104b9c96f012da1602f503f641824d78f4260 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack Reviewed-by: alanb ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c Changeset: 1ea01465 Author: Jonathan Gibbons Date: 2022-02-01 00:31:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ea01465ab06749a3177b9b724ccea0945a2de09 8281007: Test jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java fails after JDK-8280738 Reviewed-by: darcy ! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java Changeset: 0e70d450 Author: Joe Darcy Date: 2022-02-01 01:27:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e70d4504c267174738485c7da82a2ac0ef09770 8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix Reviewed-by: bpb, jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: de3113b9 Author: Michael McMahon Date: 2022-02-01 07:26:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de3113b998550021bb502cd6f766036fb8351e7d 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Co-authored-by: Weijun Wang Reviewed-by: dfuchs, weijun, darcy ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpCallerInfo.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java + src/java.base/share/classes/sun/security/util/ChannelBindingException.java + src/java.base/share/classes/sun/security/util/TlsChannelBinding.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java - src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java ! src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java ! test/jdk/com/sun/jndi/ldap/LdapCBPropertiesTest.java + test/jdk/sun/security/krb5/auto/HttpsCB.java Changeset: 16ec47d5 Author: Albert Mingkun Yang Date: 2022-02-01 08:47:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16ec47d5e5bf129fc0910358464ab62bf6ce7ed8 8279856: Parallel: Use PreservedMarks to record promotion-failed objects Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 18a7dc8c Author: Alexander Zuev Date: 2022-02-01 10:20:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a7dc8c08fa15a260b4a39b18c068d30ee45962 8279586: [macos] custom JCheckBox and JRadioBox with custom icon set: focus is still displayed after unchecking Reviewed-by: serb, azvegint ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java Changeset: d37fb1df Author: Albert Mingkun Yang Date: 2022-02-01 10:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d37fb1df460ec980bd8d3029b1ce7896c3249a99 8280870: Parallel: Simplify CLD roots claim in Full GC cycle Reviewed-by: stefank, sjohanss ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 86debf42 Author: Albert Mingkun Yang Date: 2022-02-01 11:03:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86debf42f545a1aec0a065ebd5b016339a1ae09f 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors Reviewed-by: iwalulya ! src/hotspot/share/gc/g1/g1CodeBlobClosure.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1SharedClosures.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: c5a86120 Author: Albert Mingkun Yang Date: 2022-02-01 12:23:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5a86120df7105cf612d513b5bd394501c00efed 8280458: G1: Remove G1BlockOffsetTablePart::_next_offset_threshold Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 1f6fcbe2 Author: Kim Barrett Date: 2022-02-01 15:44:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f6fcbe2f3da4c63976b1564ec2170e4757fadcc 8278475: G1 dirty card refinement by Java threads may get unnecessarily paused Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp Changeset: 5080e815 Author: Chris Plummer Date: 2022-02-01 15:59:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5080e815b4385751734054b5f889c4d89cfcdeb4 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr Reviewed-by: sspitsyn, dholmes ! test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java Changeset: 4532c3a1 Author: Chris Plummer Date: 2022-02-01 16:02:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4532c3a1639af0b4ff8c4f42c3796fa73ca5be83 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered Reviewed-by: alanb, amenkov, lmesnik ! test/hotspot/jtreg/resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeStringArray.java Changeset: d1cc5fda Author: Thomas Stuefe Date: 2022-02-01 17:19:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1cc5fda8f9fe3480d661985f15c71a8a9a4a7f8 8280941: os::print_memory_mappings() prints segment preceeding the inclusion range Reviewed-by: stefank, minqi ! src/hotspot/os/linux/os_linux.cpp Changeset: bde2b378 Author: Jim Laskey Date: 2022-02-01 18:45:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bde2b3783e0e9787cf2f270fcb3a54c2d4f1e5ab 8279954: java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails Reviewed-by: shade, dholmes ! test/jdk/java/lang/StringBuffer/HugeCapacity.java ! test/jdk/java/lang/StringBuilder/HugeCapacity.java Changeset: d95de5c7 Author: Calvin Cheung Date: 2022-02-01 19:33:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d95de5c7fea4b224d6cd073a6d6921d7108bb7e1 8255495: Support CDS Archived Heap for uncompressed oops Reviewed-by: iklam, tschatzl ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/memory/universe.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/DumpingWithNoCoops.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java Changeset: fdd9ca74 Author: Roger Riggs Date: 2022-02-01 20:13:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdd9ca74bd6ca87c30be2bcdcfd22e19b7687a5a 8280642: ObjectInputStream.readObject should throw InvalidClassException instead of IllegalAccessError Reviewed-by: naoto, mchung ! src/java.base/share/classes/java/io/ObjectInputStream.java ! test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java Changeset: a18beb47 Author: Aleksey Shipilev Date: 2022-02-01 20:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a18beb4797a1ca6fc6b31e997be48b2bd91c6ac0 8280867: Cpuid1Ecx feature parsing is incorrect for AMD CPUs Reviewed-by: kvn, dlong ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: c74b8f48 Author: Boris Ulasevich Date: 2022-02-01 20:56:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c74b8f48fad8380dbd811e4a42c361006e13021d 8275914: SHA3: changing java implementation to help C2 create high-performance code Reviewed-by: ascarpino, phh ! src/java.base/share/classes/sun/security/provider/SHA3.java Changeset: 9ca7ff3e Author: Joe Darcy Date: 2022-02-01 22:30:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ca7ff3e4f0a944bacf38da7e5426082d64c52bd 8281082: Improve javadoc references to JOSS Reviewed-by: iris, rriggs, naoto, lancea ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/Serial.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/security/Key.java ! src/java.base/share/classes/java/security/KeyRep.java Changeset: 85d839fb Author: Chris Plummer Date: 2022-02-01 23:02:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85d839fb4f3f820d130ea95f9a54ae137a95c20a 8280601: ClhsdbThreadContext.java test is triggering codecache related asserts Reviewed-by: kevinw, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java Changeset: d32f99ee Author: Roland Westrelin Date: 2022-02-02 07:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d32f99ee65679601d6e160e7975fc1e367bfa6f4 8279219: [REDO] C2 crash when allocating array of size too large Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/allocation/TestAllocArrayAfterAllocNoUse.java + test/hotspot/jtreg/compiler/allocation/TestCCPAllocateArray.java + test/hotspot/jtreg/compiler/allocation/TestFailedAllocationBadGraph.java Changeset: 97af3230 Author: Roland Westrelin Date: 2022-02-02 07:35:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97af32304101397bb33cbbd1e35fd9124f9e2311 8280842: Access violation in ciTypeFlow::profiled_count Reviewed-by: neliasso, vlivanov, kvn ! src/hotspot/share/ci/ciTypeFlow.cpp + test/hotspot/jtreg/compiler/profiling/TestSharedHeadExceptionBackedges.java Changeset: 48a32b5f Author: Jatin Bhateja Date: 2022-02-02 07:36:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48a32b5f3aa1b238bc9857002325579a5b041685 8280976: Incorrect encoding of avx512 vpsraq instruction with mask and constant shift. Reviewed-by: neliasso, thartmann ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: ab638341 Author: Roland Westrelin Date: 2022-02-02 07:37:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab638341de164965e06bb1d59808670260916b82 8280885: Shenandoah: Some tests failed with "EA: missing allocation reference path" Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestUnexpectedIUBarrierEA.java Changeset: 4304a772 Author: Roland Westrelin Date: 2022-02-02 07:38:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4304a7728ec60f7937e0198c4f85384064fe560e 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after JDK-8276116 Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.cpp Changeset: de826ba1 Author: Roland Westrelin Date: 2022-02-02 08:01:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de826ba18a5e98586029581c2d4bcd27334fbdd1 8280600: C2: assert(!had_error) failed: bad dominance Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead.java Changeset: ae2504b4 Author: Prasanta Sadhukhan Date: 2022-02-02 10:04:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae2504b4692a5298b5835727b04a44e1edc8a4d6 8278254: Cleanup doclint warnings in java.desktop module Reviewed-by: aivanov, serb ! src/java.desktop/share/classes/java/awt/BufferCapabilities.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java ! src/java.desktop/share/classes/javax/swing/JApplet.java ! src/java.desktop/share/classes/javax/swing/JDialog.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/java.desktop/share/classes/javax/swing/text/LayeredHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java ! src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java Changeset: 4ea6037e Author: Albert Mingkun Yang Date: 2022-02-02 10:43:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ea6037ea57ce7bbad00ef172dfc3c122b2317fc 8281035: Serial: Move RemoveForwardedPointerClosure to local scope Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp Changeset: ce71e8b2 Author: Roman Kennke Date: 2022-02-02 14:56:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce71e8b281176d39cc879ae4ecf95f3d643ebd29 8279917: Refactor subclassAudits in Thread to use ClassValue Reviewed-by: alanb, rriggs ! src/java.base/share/classes/java/lang/Thread.java Changeset: 87ab0994 Author: Michael McMahon Date: 2022-02-02 15:04:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87ab0994ded3b535a160bb87b6540bd072042c44 8280944: Enable Unix domain sockets in Windows Selector notification mechanism Reviewed-by: dfuchs, alanb ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java ! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java Changeset: 9d578537 Author: Albert Mingkun Yang Date: 2022-02-02 15:17:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d578537ced356eb0526a70f717b5669e30eadc6 8281042: G1: Remove unused init_threshold in G1FullGCCompactionPoint Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp Changeset: 47800bf3 Author: Daniel Fuchs Date: 2022-02-02 17:11:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47800bf3da181ae0ee612b14d95773fd1dc90350 8280868: LineBodyHandlerTest.java creates and discards too many clients Reviewed-by: michaelm ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java Changeset: e3d5c9e7 Author: Masanori Yano Committer: Lance Andersen Date: 2022-02-02 21:02:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3d5c9e7c4ab210ae7a4417a47632603910744a1 8266974: duplicate property key in java.sql.rowset resource bundle Reviewed-by: lancea ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: fe0118f8 Author: Chris Plummer Date: 2022-02-02 21:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe0118f8040ce7e5e3d605942443e3a5d442fa92 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java Changeset: 2531c332 Author: Tobias Hartmann Date: 2022-02-01 17:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2531c332f89c5faedf71ce1737373581c9abf905 8278871: [JVMCI] assert((uint)reason < 2* _trap_hist_limit) failed: oob Backport-of: 6f0e8da6d3bef340299e48977d5e17d05eabe682 ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: a46307a7 Author: Jesper Wilhelmsson Date: 2022-02-03 01:11:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a46307a79dd6c1f5cca02447b3452be8d1fbe9a0 Merge Changeset: a95ee5ad Author: Xue-Lei Andrew Fan Date: 2022-02-03 06:28:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a95ee5ada230a0177517efd3a417f319066169dd 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/ssl/Utilities.java ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java + test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java + test/jdk/javax/net/ssl/templates/SSLExampleCert.java Changeset: fe547eac Author: Artem Semenov Date: 2022-02-03 07:22:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe547eacd71b4eb8119ecc7ca2d0bbe8e757f854 8280956: Re-examine copyright headers on files in src/java.desktop/macosx/native/libawt_lwawt/awt/a11y Reviewed-by: kizune, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: 5ab22e88 Author: Roman Kennke Date: 2022-02-03 07:24:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ab22e88da8d79f9e19e8afffdd06206f42bab94 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations Reviewed-by: sspitsyn, cjplummer ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Changeset: 63a00a0d Author: Kevin Walls Date: 2022-02-03 10:10:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63a00a0df24b154ef459936dbd69bcd2f0626235 8272777: Clean up remaining AccessController warnings in test library Reviewed-by: rriggs, sspitsyn ! test/lib/jdk/test/lib/SA/SATestUtils.java ! test/lib/jdk/test/lib/net/IPSupport.java ! test/lib/jdk/test/lib/net/SimpleSSLContext.java Changeset: 010965c8 Author: Thomas Stuefe Date: 2022-02-03 14:12:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/010965c86ab39260b882df807c4f5d6420b20ca9 8281023: NMT integration into pp debug command does not work Reviewed-by: zgu, iklam ! src/hotspot/share/services/mallocTracker.cpp ! src/hotspot/share/services/mallocTracker.hpp ! src/hotspot/share/services/virtualMemoryTracker.cpp ! src/hotspot/share/services/virtualMemoryTracker.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 1f926609 Author: Pavel Rappo Date: 2022-02-03 14:55:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f926609372c9b80dde831a014310a3729768c92 8281057: Fix doc references to overriding in JLS Reviewed-by: darcy, iris, dholmes, cjplummer ! src/hotspot/share/oops/klassVtable.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java Changeset: 86c24b31 Author: Alex Menkov Date: 2022-02-03 15:51:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86c24b319ed5e2f0097cfb4b1afe2eb358eb5f75 8240908: RetransformClass does not know about MethodParameters attribute Reviewed-by: cjplummer, sspitsyn ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp + test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java = test/lib/jdk/test/lib/util/ClassTransformer.java Changeset: cda9c301 Author: Yumin Qi Date: 2022-02-03 18:02:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cda9c3011beeec8df68e78e096132e712255ce1b 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call Reviewed-by: dholmes, stuefe ! make/data/hotspot-symbols/symbols-unix ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp Changeset: 130cf46d Author: Brian Burkhalter Date: 2022-02-03 19:12:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/130cf46dcb7b089fcf4a4e950cdc701513f7b53f 4750574: (se spec) Selector spec should clarify calculation of select return value Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/Selector.java Changeset: b6935dfb Author: Yi-Fan Tsai Committer: Paul Hohensee Date: 2022-02-03 19:34:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6935dfb86a1c011355d2dfb2140be26ec536351 8251505: Use of types in compiler shared code should be consistent. Reviewed-by: phh ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/sweeper.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: e44dc638 Author: Dean Long Date: 2022-02-03 22:10:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e44dc638b8936b1b76ca9ddf9ece0c5c4705a19c 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack Co-authored-by: Yi Yang Co-authored-by: Yi Yang Reviewed-by: vlivanov, thartmann ! src/hotspot/share/runtime/deoptimization.cpp + test/hotspot/jtreg/compiler/interpreter/Custom.jasm + test/hotspot/jtreg/compiler/interpreter/VerifyStackWithUnreachableBlock.java Changeset: 63e11cfa Author: Andrey Turbanov Date: 2022-02-04 07:08:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63e11cfa3f887515ca36ab5147c3e6fa540978d3 8280970: Cleanup dead code in java.security.Provider Reviewed-by: valeriep ! src/java.base/share/classes/java/security/Provider.java Changeset: c936e705 Author: Richard Reingruber Date: 2022-02-04 07:57:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c936e7059b848d0e0be5f3234c4367657f2af2a7 8280593: [PPC64, S390] redundant allocation of MacroAssembler in StubGenerator ctor Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/s390/stubGenerator_s390.cpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp Changeset: 46c6c6f3 Author: Martin Doerr Date: 2022-02-04 09:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46c6c6f308b5ec0ec3b762df4b76de555287474c 8281043: Intrinsify recursive ObjectMonitor locking for PPC64 Reviewed-by: rrich, lucy ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Changeset: 51b53a82 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 10:51:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51b53a821bb3cfb962f80a637f5fb8cde988975a 8280913: Create a regression test for JRootPane.setDefaultButton() method Reviewed-by: aivanov + test/jdk/javax/swing/JRootPane/DefaultButtonTest.java Changeset: 396829b2 Author: duke Date: 2022-02-04 11:00:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396829b2d1a5d9248c4afa0dab598614c77a54ee Automatic merge of jdk:master into master Changeset: 94812205 Author: duke Date: 2022-02-04 11:01:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/948122059f12a377af6252cec172058f12933a1f Automatic merge of master into foreign-memaccess+abi ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp Changeset: 2e129168 Author: duke Date: 2022-02-04 11:01:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e1291680024f12fbf2f0f02b0f79d7b4348b369 Automatic merge of foreign-memaccess+abi into foreign-jextract From duke at openjdk.java.net Fri Feb 4 11:21:29 2022 From: duke at openjdk.java.net (duke) Date: Fri, 4 Feb 2022 11:21:29 GMT Subject: git: openjdk/panama-foreign: foreign-preview: 78 new changesets Message-ID: <3b168f3a-8c4c-419c-9879-13338918a23e@openjdk.org> Changeset: 6de90ad9 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2022-01-28 12:45:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6de90ad9800b83c4a5f364c3645603fcb6828d6c 8280863: Update build README to reflect that MSYS2 is supported Reviewed-by: ihse ! doc/building.html ! doc/building.md Changeset: cb8a82ee Author: Kevin Walls Date: 2022-01-28 12:54:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb8a82ee24881113af4eea04d7ce5963d18e9b83 8272317: jstatd has dependency on Security Manager which needs to be removed Reviewed-by: cjplummer, rriggs ! make/modules/jdk.jstatd/Launcher.gmk ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! test/jdk/sun/tools/jstatd/JstatdTest.java - test/jdk/sun/tools/jstatd/all.policy Changeset: 409382ba Author: Sebastian Stenzel Committer: Anthony Scarpino Date: 2022-01-28 16:42:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/409382ba4b43bf48ed0086020dd20641effd35b6 8280703: CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption Reviewed-by: ascarpino ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java Changeset: 95ee9bf7 Author: Brian Burkhalter Date: 2022-01-28 17:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95ee9bf7be40572e768cf6213c03ca183b8ad886 4774868: (fc spec) Unclear spec for FileChannel.force Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: ff34d624 Author: Daniel D. Daugherty Date: 2022-01-28 18:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff34d624ba81698db0aacc1d5e2332c4345010ce 8280898: ProblemList compiler/regalloc/TestC2IntPressure.java on macosx-aarch64 Reviewed-by: ctornqvi ! test/hotspot/jtreg/ProblemList.txt Changeset: 0740ac47 Author: Chris Plummer Date: 2022-01-28 18:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0740ac474cbda439684223e660827e38964e6b1f 8280555: serviceability/sa/TestObjectMonitorIterate.java is failing due to ObjectMonitor referencing a null Object Reviewed-by: sspitsyn, lmesnik ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java Changeset: 91391598 Author: Denghui Dong Date: 2022-01-28 22:52:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91391598989c70c98b9400997df4f9177d3e576f 8280843: macos-Aarch64 SEGV in frame::sender_for_compiled_frame after JDK-8277948 Reviewed-by: aph, dholmes ! src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/thread_windows_aarch64.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d366d15d Author: Brian Burkhalter Date: 2022-01-28 23:18:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d366d15d67a08833d93a5806edef8145cb7803e5 8280903: javadoc build fails after JDK-4774868 Reviewed-by: lancea ! src/java.base/share/classes/java/nio/channels/FileChannel.java Changeset: 268880b4 Author: Andrey Turbanov Date: 2022-01-29 11:36:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/268880b471eed54535927fba953347160f447fcd 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java Changeset: be9f984c Author: Chris Plummer Date: 2022-01-29 21:35:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be9f984caec32c3fe1deef30efe40fa115409ca0 8280553: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java can fail if GC occurs Reviewed-by: alanb, amenkov ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeArray.java Changeset: 251351f4 Author: Aleksey Shipilev Date: 2022-01-31 08:49:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/251351f49498ea39150b38860b8f73232fbaf05d 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops Reviewed-by: sspitsyn, dcubed ! test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java Changeset: c6ed2046 Author: Andrey Turbanov Date: 2022-01-31 12:11:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c6ed2046b4ba8eafb6b7e934b134829760d56ecd 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/java.base/unix/classes/sun/net/www/protocol/file/Handler.java ! src/java.base/windows/classes/sun/net/www/protocol/file/Handler.java Changeset: 61794c50 Author: Stefan Karlsson Date: 2022-01-31 12:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61794c503973a330278f0595e36be0bd686fe2b5 8280817: Clean up and unify empty VM operations Reviewed-by: shade, coleenp ! src/hotspot/share/runtime/vmOperation.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmThread.cpp ! test/hotspot/gtest/threadHelper.inline.hpp Changeset: 091aff92 Author: Dmitry Batrak Date: 2022-01-31 13:43:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/091aff92e2213bfe0de79b3561a7613ab77e24b6 8278908: [macOS] Unexpected text normalization on pasting from clipboard Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! test/jdk/java/awt/datatransfer/UnicodeTransferTest/UnicodeTransferTest.java Changeset: bdda43e0 Author: Thomas Schatzl Date: 2022-01-31 16:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdda43e066b8da0ebf9a8ef2f843eabb230f0800 8280705: Parallel: Full gc mark stack draining should prefer to make work available to other threads Reviewed-by: ayang, mli ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: dcc666d5 Author: Thomas Schatzl Date: 2022-01-31 16:51:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dcc666d53d66e87c11c0c39858b36d40299b7de6 8280139: Report more detailed statistics about task stealing in task queue stats Reviewed-by: kbarrett, iwalulya ! src/hotspot/share/gc/shared/taskqueue.cpp ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 993a2488 Author: Thomas Schatzl Date: 2022-01-31 16:52:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/993a2488ef42b4c63a7e342c12bba8af8e3fab40 8280450: Add task queue printing to STW Full GCs Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 319b7749 Author: Yumin Qi Date: 2022-01-31 19:27:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/319b77492f78a08b7b9488c73876b027c3076c76 8277101: jcmd VM.cds dynamic_dump should not regenerate holder classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java Changeset: f991891b Author: Xue-Lei Andrew Fan Date: 2022-01-31 20:25:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f991891b0ba7a3767d2abd85ab9b2d284dc3d013 8280949: Correct the references for the Java Security Standard Algorithm Names specification Reviewed-by: mullan ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: 39165613 Author: Ioi Lam Date: 2022-01-31 21:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/39165613aa0430861e361a33a4925b85ea24fff1 8280543: Update the "java" and "jcmd" tool specification for CDS Reviewed-by: hseigel, sspitsyn, ccheung ! src/java.base/share/man/java.1 ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 74921e84 Author: Jonathan Gibbons Date: 2022-01-31 22:45:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74921e8422ce31a22516b279a00935b1917c089d 8280738: Minor cleanup for HtmlStyle Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java Changeset: ee3be0bb Author: Jonathan Gibbons Date: 2022-01-31 22:47:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee3be0bb567f0e28fd3e920ef3685607d0a8d656 8280488: doclint reference checks withstand warning suppression Reviewed-by: darcy ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties + test/langtools/jdk/javadoc/tool/doclint/DocLintReferencesTest.java Changeset: 96d0df72 Author: Jonathan Gibbons Date: 2022-01-31 22:54:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96d0df72db277f127bd4c6b8c51bfc64d1c593e0 8272984: javadoc support for reproducible builds Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java + test/langtools/jdk/javadoc/doclet/testDateOption/TestDateOption.java ! test/langtools/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: 4191b2b9 Author: Igor Veresov Date: 2022-01-31 23:02:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4191b2b9b98c1137e5f27e3b64efb83857fa2c91 8275337: C1: assert(false) failed: live_in set of first block must be empty Reviewed-by: kvn ! src/hotspot/share/c1/c1_RangeCheckElimination.cpp + test/hotspot/jtreg/compiler/c1/Test8275337.java Changeset: 4dbebb62 Author: Joe Darcy Date: 2022-01-31 23:22:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dbebb62aa264adda8d96a06f608ef9d13155a26 8280534: Enable compile-time doclint reference checking Reviewed-by: serb, naoto, mchung, lancea, iris ! make/modules/java.base/Java.gmk ! make/modules/java.datatransfer/Java.gmk ! make/modules/java.logging/Java.gmk ! make/modules/java.management/Java.gmk ! src/java.base/share/classes/java/io/FilenameFilter.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/net/package-info.java ! src/java.base/share/classes/java/text/AttributedCharacterIterator.java ! src/java.base/share/classes/java/text/Bidi.java ! src/java.base/share/classes/java/util/Observable.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/Clipboard.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/LoggingMXBean.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/java.management/share/classes/javax/management/remote/JMXAddressable.java ! src/java.management/share/classes/javax/management/remote/JMXServerErrorException.java Changeset: 9c0104b9 Author: Mandy Chung Date: 2022-02-01 00:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c0104b9c96f012da1602f503f641824d78f4260 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack Reviewed-by: alanb ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c Changeset: 1ea01465 Author: Jonathan Gibbons Date: 2022-02-01 00:31:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ea01465ab06749a3177b9b724ccea0945a2de09 8281007: Test jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java fails after JDK-8280738 Reviewed-by: darcy ! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java Changeset: 0e70d450 Author: Joe Darcy Date: 2022-02-01 01:27:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e70d4504c267174738485c7da82a2ac0ef09770 8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix Reviewed-by: bpb, jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: de3113b9 Author: Michael McMahon Date: 2022-02-01 07:26:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de3113b998550021bb502cd6f766036fb8351e7d 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Co-authored-by: Weijun Wang Reviewed-by: dfuchs, weijun, darcy ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpCallerInfo.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java + src/java.base/share/classes/sun/security/util/ChannelBindingException.java + src/java.base/share/classes/sun/security/util/TlsChannelBinding.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java - src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java ! src/java.security.jgss/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java ! test/jdk/com/sun/jndi/ldap/LdapCBPropertiesTest.java + test/jdk/sun/security/krb5/auto/HttpsCB.java Changeset: 16ec47d5 Author: Albert Mingkun Yang Date: 2022-02-01 08:47:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16ec47d5e5bf129fc0910358464ab62bf6ce7ed8 8279856: Parallel: Use PreservedMarks to record promotion-failed objects Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 18a7dc8c Author: Alexander Zuev Date: 2022-02-01 10:20:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a7dc8c08fa15a260b4a39b18c068d30ee45962 8279586: [macos] custom JCheckBox and JRadioBox with custom icon set: focus is still displayed after unchecking Reviewed-by: serb, azvegint ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java Changeset: d37fb1df Author: Albert Mingkun Yang Date: 2022-02-01 10:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d37fb1df460ec980bd8d3029b1ce7896c3249a99 8280870: Parallel: Simplify CLD roots claim in Full GC cycle Reviewed-by: stefank, sjohanss ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 86debf42 Author: Albert Mingkun Yang Date: 2022-02-01 11:03:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86debf42f545a1aec0a065ebd5b016339a1ae09f 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors Reviewed-by: iwalulya ! src/hotspot/share/gc/g1/g1CodeBlobClosure.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1SharedClosures.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: c5a86120 Author: Albert Mingkun Yang Date: 2022-02-01 12:23:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5a86120df7105cf612d513b5bd394501c00efed 8280458: G1: Remove G1BlockOffsetTablePart::_next_offset_threshold Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 1f6fcbe2 Author: Kim Barrett Date: 2022-02-01 15:44:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f6fcbe2f3da4c63976b1564ec2170e4757fadcc 8278475: G1 dirty card refinement by Java threads may get unnecessarily paused Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp Changeset: 5080e815 Author: Chris Plummer Date: 2022-02-01 15:59:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5080e815b4385751734054b5f889c4d89cfcdeb4 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr Reviewed-by: sspitsyn, dholmes ! test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java Changeset: 4532c3a1 Author: Chris Plummer Date: 2022-02-01 16:02:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4532c3a1639af0b4ff8c4f42c3796fa73ca5be83 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered Reviewed-by: alanb, amenkov, lmesnik ! test/hotspot/jtreg/resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java ! test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeStringArray.java Changeset: d1cc5fda Author: Thomas Stuefe Date: 2022-02-01 17:19:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1cc5fda8f9fe3480d661985f15c71a8a9a4a7f8 8280941: os::print_memory_mappings() prints segment preceeding the inclusion range Reviewed-by: stefank, minqi ! src/hotspot/os/linux/os_linux.cpp Changeset: bde2b378 Author: Jim Laskey Date: 2022-02-01 18:45:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bde2b3783e0e9787cf2f270fcb3a54c2d4f1e5ab 8279954: java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails Reviewed-by: shade, dholmes ! test/jdk/java/lang/StringBuffer/HugeCapacity.java ! test/jdk/java/lang/StringBuilder/HugeCapacity.java Changeset: d95de5c7 Author: Calvin Cheung Date: 2022-02-01 19:33:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d95de5c7fea4b224d6cd073a6d6921d7108bb7e1 8255495: Support CDS Archived Heap for uncompressed oops Reviewed-by: iklam, tschatzl ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/memory/universe.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/DumpingWithNoCoops.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java Changeset: fdd9ca74 Author: Roger Riggs Date: 2022-02-01 20:13:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdd9ca74bd6ca87c30be2bcdcfd22e19b7687a5a 8280642: ObjectInputStream.readObject should throw InvalidClassException instead of IllegalAccessError Reviewed-by: naoto, mchung ! src/java.base/share/classes/java/io/ObjectInputStream.java ! test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java Changeset: a18beb47 Author: Aleksey Shipilev Date: 2022-02-01 20:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a18beb4797a1ca6fc6b31e997be48b2bd91c6ac0 8280867: Cpuid1Ecx feature parsing is incorrect for AMD CPUs Reviewed-by: kvn, dlong ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: c74b8f48 Author: Boris Ulasevich Date: 2022-02-01 20:56:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c74b8f48fad8380dbd811e4a42c361006e13021d 8275914: SHA3: changing java implementation to help C2 create high-performance code Reviewed-by: ascarpino, phh ! src/java.base/share/classes/sun/security/provider/SHA3.java Changeset: 9ca7ff3e Author: Joe Darcy Date: 2022-02-01 22:30:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ca7ff3e4f0a944bacf38da7e5426082d64c52bd 8281082: Improve javadoc references to JOSS Reviewed-by: iris, rriggs, naoto, lancea ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/Serial.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/security/Key.java ! src/java.base/share/classes/java/security/KeyRep.java Changeset: 85d839fb Author: Chris Plummer Date: 2022-02-01 23:02:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85d839fb4f3f820d130ea95f9a54ae137a95c20a 8280601: ClhsdbThreadContext.java test is triggering codecache related asserts Reviewed-by: kevinw, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java Changeset: d32f99ee Author: Roland Westrelin Date: 2022-02-02 07:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d32f99ee65679601d6e160e7975fc1e367bfa6f4 8279219: [REDO] C2 crash when allocating array of size too large Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/allocation/TestAllocArrayAfterAllocNoUse.java + test/hotspot/jtreg/compiler/allocation/TestCCPAllocateArray.java + test/hotspot/jtreg/compiler/allocation/TestFailedAllocationBadGraph.java Changeset: 97af3230 Author: Roland Westrelin Date: 2022-02-02 07:35:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97af32304101397bb33cbbd1e35fd9124f9e2311 8280842: Access violation in ciTypeFlow::profiled_count Reviewed-by: neliasso, vlivanov, kvn ! src/hotspot/share/ci/ciTypeFlow.cpp + test/hotspot/jtreg/compiler/profiling/TestSharedHeadExceptionBackedges.java Changeset: 48a32b5f Author: Jatin Bhateja Date: 2022-02-02 07:36:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48a32b5f3aa1b238bc9857002325579a5b041685 8280976: Incorrect encoding of avx512 vpsraq instruction with mask and constant shift. Reviewed-by: neliasso, thartmann ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: ab638341 Author: Roland Westrelin Date: 2022-02-02 07:37:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab638341de164965e06bb1d59808670260916b82 8280885: Shenandoah: Some tests failed with "EA: missing allocation reference path" Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestUnexpectedIUBarrierEA.java Changeset: 4304a772 Author: Roland Westrelin Date: 2022-02-02 07:38:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4304a7728ec60f7937e0198c4f85384064fe560e 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after JDK-8276116 Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.cpp Changeset: de826ba1 Author: Roland Westrelin Date: 2022-02-02 08:01:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de826ba18a5e98586029581c2d4bcd27334fbdd1 8280600: C2: assert(!had_error) failed: bad dominance Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead.java Changeset: ae2504b4 Author: Prasanta Sadhukhan Date: 2022-02-02 10:04:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae2504b4692a5298b5835727b04a44e1edc8a4d6 8278254: Cleanup doclint warnings in java.desktop module Reviewed-by: aivanov, serb ! src/java.desktop/share/classes/java/awt/BufferCapabilities.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/java.desktop/share/classes/javax/swing/DefaultListSelectionModel.java ! src/java.desktop/share/classes/javax/swing/JApplet.java ! src/java.desktop/share/classes/javax/swing/JDialog.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/java.desktop/share/classes/javax/swing/text/LayeredHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java ! src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java Changeset: 4ea6037e Author: Albert Mingkun Yang Date: 2022-02-02 10:43:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ea6037ea57ce7bbad00ef172dfc3c122b2317fc 8281035: Serial: Move RemoveForwardedPointerClosure to local scope Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/preservedMarks.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp Changeset: ce71e8b2 Author: Roman Kennke Date: 2022-02-02 14:56:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce71e8b281176d39cc879ae4ecf95f3d643ebd29 8279917: Refactor subclassAudits in Thread to use ClassValue Reviewed-by: alanb, rriggs ! src/java.base/share/classes/java/lang/Thread.java Changeset: 87ab0994 Author: Michael McMahon Date: 2022-02-02 15:04:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87ab0994ded3b535a160bb87b6540bd072042c44 8280944: Enable Unix domain sockets in Windows Selector notification mechanism Reviewed-by: dfuchs, alanb ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java ! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java Changeset: 9d578537 Author: Albert Mingkun Yang Date: 2022-02-02 15:17:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d578537ced356eb0526a70f717b5669e30eadc6 8281042: G1: Remove unused init_threshold in G1FullGCCompactionPoint Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp Changeset: 47800bf3 Author: Daniel Fuchs Date: 2022-02-02 17:11:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47800bf3da181ae0ee612b14d95773fd1dc90350 8280868: LineBodyHandlerTest.java creates and discards too many clients Reviewed-by: michaelm ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java Changeset: e3d5c9e7 Author: Masanori Yano Committer: Lance Andersen Date: 2022-02-02 21:02:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3d5c9e7c4ab210ae7a4417a47632603910744a1 8266974: duplicate property key in java.sql.rowset resource bundle Reviewed-by: lancea ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: fe0118f8 Author: Chris Plummer Date: 2022-02-02 21:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe0118f8040ce7e5e3d605942443e3a5d442fa92 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java Changeset: 2531c332 Author: Tobias Hartmann Date: 2022-02-01 17:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2531c332f89c5faedf71ce1737373581c9abf905 8278871: [JVMCI] assert((uint)reason < 2* _trap_hist_limit) failed: oob Backport-of: 6f0e8da6d3bef340299e48977d5e17d05eabe682 ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: a46307a7 Author: Jesper Wilhelmsson Date: 2022-02-03 01:11:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a46307a79dd6c1f5cca02447b3452be8d1fbe9a0 Merge Changeset: a95ee5ad Author: Xue-Lei Andrew Fan Date: 2022-02-03 06:28:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a95ee5ada230a0177517efd3a417f319066169dd 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/ssl/Utilities.java ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java + test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java + test/jdk/javax/net/ssl/templates/SSLExampleCert.java Changeset: fe547eac Author: Artem Semenov Date: 2022-02-03 07:22:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe547eacd71b4eb8119ecc7ca2d0bbe8e757f854 8280956: Re-examine copyright headers on files in src/java.desktop/macosx/native/libawt_lwawt/awt/a11y Reviewed-by: kizune, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabGroupAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: 5ab22e88 Author: Roman Kennke Date: 2022-02-03 07:24:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ab22e88da8d79f9e19e8afffdd06206f42bab94 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations Reviewed-by: sspitsyn, cjplummer ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Changeset: 63a00a0d Author: Kevin Walls Date: 2022-02-03 10:10:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63a00a0df24b154ef459936dbd69bcd2f0626235 8272777: Clean up remaining AccessController warnings in test library Reviewed-by: rriggs, sspitsyn ! test/lib/jdk/test/lib/SA/SATestUtils.java ! test/lib/jdk/test/lib/net/IPSupport.java ! test/lib/jdk/test/lib/net/SimpleSSLContext.java Changeset: 010965c8 Author: Thomas Stuefe Date: 2022-02-03 14:12:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/010965c86ab39260b882df807c4f5d6420b20ca9 8281023: NMT integration into pp debug command does not work Reviewed-by: zgu, iklam ! src/hotspot/share/services/mallocTracker.cpp ! src/hotspot/share/services/mallocTracker.hpp ! src/hotspot/share/services/virtualMemoryTracker.cpp ! src/hotspot/share/services/virtualMemoryTracker.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 1f926609 Author: Pavel Rappo Date: 2022-02-03 14:55:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f926609372c9b80dde831a014310a3729768c92 8281057: Fix doc references to overriding in JLS Reviewed-by: darcy, iris, dholmes, cjplummer ! src/hotspot/share/oops/klassVtable.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java Changeset: 86c24b31 Author: Alex Menkov Date: 2022-02-03 15:51:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86c24b319ed5e2f0097cfb4b1afe2eb358eb5f75 8240908: RetransformClass does not know about MethodParameters attribute Reviewed-by: cjplummer, sspitsyn ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp + test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java = test/lib/jdk/test/lib/util/ClassTransformer.java Changeset: cda9c301 Author: Yumin Qi Date: 2022-02-03 18:02:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cda9c3011beeec8df68e78e096132e712255ce1b 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call Reviewed-by: dholmes, stuefe ! make/data/hotspot-symbols/symbols-unix ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp Changeset: 130cf46d Author: Brian Burkhalter Date: 2022-02-03 19:12:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/130cf46dcb7b089fcf4a4e950cdc701513f7b53f 4750574: (se spec) Selector spec should clarify calculation of select return value Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/Selector.java Changeset: b6935dfb Author: Yi-Fan Tsai Committer: Paul Hohensee Date: 2022-02-03 19:34:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6935dfb86a1c011355d2dfb2140be26ec536351 8251505: Use of types in compiler shared code should be consistent. Reviewed-by: phh ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/sweeper.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: e44dc638 Author: Dean Long Date: 2022-02-03 22:10:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e44dc638b8936b1b76ca9ddf9ece0c5c4705a19c 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack Co-authored-by: Yi Yang Co-authored-by: Yi Yang Reviewed-by: vlivanov, thartmann ! src/hotspot/share/runtime/deoptimization.cpp + test/hotspot/jtreg/compiler/interpreter/Custom.jasm + test/hotspot/jtreg/compiler/interpreter/VerifyStackWithUnreachableBlock.java Changeset: 63e11cfa Author: Andrey Turbanov Date: 2022-02-04 07:08:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63e11cfa3f887515ca36ab5147c3e6fa540978d3 8280970: Cleanup dead code in java.security.Provider Reviewed-by: valeriep ! src/java.base/share/classes/java/security/Provider.java Changeset: c936e705 Author: Richard Reingruber Date: 2022-02-04 07:57:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c936e7059b848d0e0be5f3234c4367657f2af2a7 8280593: [PPC64, S390] redundant allocation of MacroAssembler in StubGenerator ctor Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/s390/stubGenerator_s390.cpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp Changeset: 46c6c6f3 Author: Martin Doerr Date: 2022-02-04 09:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46c6c6f308b5ec0ec3b762df4b76de555287474c 8281043: Intrinsify recursive ObjectMonitor locking for PPC64 Reviewed-by: rrich, lucy ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Changeset: 51b53a82 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 10:51:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51b53a821bb3cfb962f80a637f5fb8cde988975a 8280913: Create a regression test for JRootPane.setDefaultButton() method Reviewed-by: aivanov + test/jdk/javax/swing/JRootPane/DefaultButtonTest.java Changeset: 396829b2 Author: duke Date: 2022-02-04 11:00:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396829b2d1a5d9248c4afa0dab598614c77a54ee Automatic merge of jdk:master into master Changeset: 4a17c5b1 Author: duke Date: 2022-02-04 11:01:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a17c5b125e6c6e8940463118c474db11cd2721d Automatic merge of master into foreign-preview ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java From mcimadamore at openjdk.java.net Fri Feb 4 12:52:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 12:52:01 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm [v2] In-Reply-To: References: Message-ID: > This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. > > After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix adaptation in non-specialized path, and fix TestMatrix ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/638/files - new: https://git.openjdk.java.net/panama-foreign/pull/638/files/542c3395..bce66ffa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=638&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=638&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/638.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/638/head:pull/638 PR: https://git.openjdk.java.net/panama-foreign/pull/638 From jvernee at openjdk.java.net Fri Feb 4 12:52:02 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Feb 2022 12:52:02 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm [v2] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 12:47:47 GMT, Maurizio Cimadamore wrote: >> This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. >> >> After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix adaptation in non-specialized path, and fix TestMatrix Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/638 From mcimadamore at openjdk.java.net Fri Feb 4 12:52:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 12:52:02 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 22:23:47 GMT, Maurizio Cimadamore wrote: > This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. > > After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. I've added another small fix (spotted by @JornVernee) where the adaptation of a method type was created, and then discarded (in non specializing mode). This is only caught by TestMatrix (which is a manual-only test). When I tried to ran it, several combinations were failing because of the invalid combo of `/manual` and `/timeout`, so I've fixed that too. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/638 From mcimadamore at openjdk.java.net Fri Feb 4 13:02:54 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 13:02:54 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm [v3] In-Reply-To: References: Message-ID: > This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. > > After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Removed unused imports - Generalize typeStack testing ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/638/files - new: https://git.openjdk.java.net/panama-foreign/pull/638/files/bce66ffa..e73a2aa3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=638&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=638&range=01-02 Stats: 10 lines in 1 file changed: 4 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/638.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/638/head:pull/638 PR: https://git.openjdk.java.net/panama-foreign/pull/638 From jvernee at openjdk.java.net Fri Feb 4 13:02:55 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Feb 2022 13:02:55 GMT Subject: [foreign-preview] RFR: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm [v3] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 12:59:46 GMT, Maurizio Cimadamore wrote: >> This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. >> >> After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Removed unused imports > - Generalize typeStack testing Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/638 From mcimadamore at openjdk.java.net Fri Feb 4 13:05:45 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 13:05:45 GMT Subject: git: openjdk/panama-foreign: foreign-preview: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm Message-ID: Changeset: e1aa60af Author: Maurizio Cimadamore Date: 2022-02-04 13:05:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1aa60af00cc4eac00ae0c52ec9aa2aa24002f6a 8281228: Preview branch's CLinker.downcallHandle crashes inside asm Reviewed-by: sundar, jvernee ! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java ! src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! test/jdk/java/foreign/TestMatrix.java From mcimadamore at openjdk.java.net Fri Feb 4 13:08:37 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Feb 2022 13:08:37 GMT Subject: [foreign-preview] Integrated: 8281228: Preview branch's CLinker.downcallHandle crashes inside asm In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 22:23:47 GMT, Maurizio Cimadamore wrote: > This patch addresses a low level crash occuring in the ASM library, triggered by the new binding specialization logic. After some debugging I realized that there was no real "bug", but something subtle that we missed during review. The binding specializer uses an internal operand stack to keep track of the types maniupulated when processing ABI bindings. Most of the "pop" operation on this stack were done inside an `assert` statement, which meant that the pop operation would not be executed when running without `-esa`. Unfortunately this issue was not caught because the makefile always runs tests with assertions enabled. > > After fixing this, I have also verified that the existing test (if ran without assertion enabled) would indeed have been enough to trigger the failure; in other words, the failure has not been detected because of *the way* in which tests were ran, and not because we were lacking in test coverage (for instance, TestDowncall showed 812 failures without the fix). For these reasons I did not include any test in the fix. This pull request has now been integrated. Changeset: e1aa60af Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/e1aa60af00cc4eac00ae0c52ec9aa2aa24002f6a Stats: 53 lines in 3 files changed: 26 ins; 0 del; 27 mod 8281228: Preview branch's CLinker.downcallHandle crashes inside asm Reviewed-by: sundar, jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/638 From notzed at gmail.com Sat Feb 5 09:16:33 2022 From: notzed at gmail.com (Michael Zucchi) Date: Sat, 5 Feb 2022 19:46:33 +1030 Subject: resource scopes and close actions In-Reply-To: <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> Message-ID: <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> On 3/2/22 22:01, Maurizio Cimadamore wrote: > >> So it's only a minor inconvenience - it needs to keep another copy of >> the MemoryAddress (ps) around, and it needs to have a static 'close' >> function that takes a MemoryAddress rather than a static or >> objectfunction that uses 'segment'.? The former is just a wasteful >> copy and the latter pollutes the api a bit.? ffmpeg >> avformat_close_input actually takes an AVFormatContext ** and so can >> be invoked multiple times safely, so another explicit close function >> would be useful as well but that's another matter. >> > So, this is the main factory for AVFormatContext, and it takes a scope > - that seems to make sense to me. When the user closes the scope, some > native function will be called to release the memory that has been > allocated so far. I'm not sure I see the issues you mention though: > with respect to duplication, you refer to the fact that you have to > keep a MemoryAddress (local!) variable around? Not to dismiss the > concern, but that doesn't seem _that_ terrible. > Well it's only semantically a local, physically it's copied to the lambda handle.? Like i said it's only a minor thing. > As for the close(MemoryAddress), yes, something like that would be > needed, but why is it a public method? Couldn't it just be some > private method somewhere? I guess I'm a bit fuzzy as to where your API > boundaries are. It seems to me that you want your clients to deal in > AVFormatContext, AVRational and friends, and you don't really want > them to think (too much) about scope, segments and addresses - which I > think is a fine move. But if that's the case, why having a > close(MemoryAddress) in the API? > Well the situation is a bit messier than i thought, as below. >> Anyway i'm still trying to work out how to fit this all in, i'm >> passing around scopes because MemorySegment.ofAddress() needs it and >> now i'm trying to work out how to fit them to the lifecycle of >> objects.?? This was the first attempt at utilising the facilities for >> some benefit. > I think having at least one scope does make sense. After all it is > possible for a client to create an AVFormatContext, get an AVStream > out of it and keep hold of it for too long (e.g. after the > AVFormatContext has been released). In which case, if the client tries > to access that AVStream you will have a JVM crash. If, on the other > hand, the AVStream is backed by the same scope as the AVFormatContext, > clients can't cause crashes in this particular way: once the > AVFormatContext has been closed, nothing associated with its scope > will be accessible. Which seems like an important invariant in your > API? Also, I'm not 100% clear on how you handle writes; if the user > sets a custom AVStream on your array, clearly you can have a problem > if the lifecycle of the custom AVStream doesn't match that of the > enclosing AVFormatContext (which seems to be another reason to keep > track of lifecycles?) Hmm yes I see the utility there, without a scope-thing you lose that downstream tracking although it also means you have to be all in on it for it to be effective.? In this specific case possibly AVFormatContext should have it's own shared scope and an explicit close function so it could close that scope at the right time, rather than going the other way around. Sorry I got that part about writing streams completely wrong as it's been a long time since i looked at it.? It's a bit more complicated as the close function? you use depends on the constructor and potentially later calls. reading streams: ? avformat_open_input() allocates/initialises struct AVFormatContext ? you can read and modify some of the structures it creates ? avformat_close_input() closes it. or also reading streams (e.g. to provide custom i/o): ? avformat_alloc_context() ? modify some fields ? avformat_open_input() ? read/modify things ? avformat_close_input() writing: ? avformat_alloc_contex() ? modify some fields ? avformat_new_stream() ? lookup/modify some fields ? avformat_write_header() ? avformat_free() So 'auto-closing' isn't quite straightforward anyway, not without some higher level calls or state tracking.? In the JNI version I used the 'opaque' user-data field in AVFormatContext to track which close function should be used.? Same approach could be done here I guess, although it would need a copy of the MemoryAddress to be saved in any constructors so the close function could access it in an onClose handler. >> >> But it seems very difficult to get right and somewhat clumsy to use >> and only provides a very marginal increase in live-ness safety >> because you can always turn a MemoryAddress into a MemorySegment in >> another scope.? And ideally it's not something you'd expose to the >> api user.? With JNI there were other more straightforward mechanisms >> to manage the java<>c lifecycle matching (e.g. nulling out the >> pointer), ones that could be hidden from the library user. > It is true that if you have a MemoryAddress you can always turn it > into something - but here you are writing an high-level API - again, > I'm not 100% sure as to what the boundaries of your API are. If your > API wraps segments and addresses, then a user, ideally, will not be > able to circumvent scopes by creating a segment backed by same address > but a different scope. If, on the other hand, your struct abstractions > also expose segments and addresses, there is a chance for users to > break away from scope restrictions, but they will always need a > restricted operation to do so. So, assuming your API is the only > "privileged" part running in your system, the user can't mess with > scopes, even if it can sees the addresses. Oh right, well I didn't really think about hiding them completely from the api, I suppose that makes sense and maybe in some cases it will be possible.? In other cases they are just handles, so even if they are hidden they are still represented by a MemoryAddress which are all in the global scope so they can't go out of scope even if they are closed - which will still potentially crash the jvm if they are passed to function calls.? See a couple of paragraphs below about those. I don't really see what practical difference the restricted functions make for a library - it's up to the application author and ultimately the user as to which modules have native access and not the library. MemorySegment and maybe MemoryAddress will have to be exposed for some of the data structures for use and interoperation with other libraries.? Specifically for ffmpeg there's at least AVFrame { uint8_t *data[8]; }, which are memory buffers for pixels and samples (and could be any primitive type not just ubyte) and the main input/output one is interested in.? While the jni version has some helpers to handle conversion to/from java2d/javafx/java audio, it exposes a jni-allocated ByteBuffer for other cases like opencl where you want to avoid big copies.? It's also got ref/unref of the data fields and some functions will implicitly unref, so that might be tricky to get to work within the confines of resource scopes. Possibly a case where it just doesn't really fit the mechanism. OpenCL (& Vulkan) does everything via handles (typed anonymous pointers), so presumably represented by MemoryAddress.? What approach to use here to make them scope-safe?? Have explicit scope tests before using them in calls? If one wanted a scope-protected MemoryAddress this seems to be the only solution in the present api: CLCommandQueue { ? ResourceScope scope; ? MemoryAddress handle; ? void enqueueNDRangeKernel(...) { ??? try (ResourceScope scope = ResourceScope.newConfinedScope()) { ?????? scope.keepAlive(this.scope); ???????? enqueueNDRangeKernel$MH.invokeExact((Addressable)handle, ...); ??? } catch (IllegalStateException ex) { ??? } ? } } Actually it's a bit worse because there will be handles (possibly in different scopes) in the argument list and they would all need to be checked in the same way. So for practicality they would have to be MemorySegment (ideally length=0) since they are always checked? OpenCL adds another wrinkle here, it's possible to use generic getters to retrieve handles to other objects, like retrieving the cl_command_queue a given cl_event was written to.? In the jni bindings I did for opencl I used a global hash table to resolve handles to unique java objects, that seems the only approach but it seems heavy.? Side note: MemoryAddress.hashCode() is very poor for hash tables since most addresses have at least the 3 least significant bits set to 0 on a 64-bit machine. ?!Z From notzed at gmail.com Sat Feb 5 11:27:03 2022 From: notzed at gmail.com (Michael Zucchi) Date: Sat, 5 Feb 2022 21:57:03 +1030 Subject: MemorySegment.ofByteBuffer(ByteBuffer.allocateDirect()) Message-ID: Evening, I'm seeing a direct ByteBuffer being freed while still used by a MemorySegment.ofByteBuffer().?? I'm apparently using foreign-jextract @ commit 6c3e90789b1a6590894f09c2027a7fcf9e23af06 (Fri Jan 28 11:01:26 2022) but it hasn't changed for months. The docs for ofByteBuffer() explicitly state the backing buffer is referenced. ??? /** ???? * Creates a new buffer memory segment that models the memory associated with the given byte ???? * buffer. The segment starts relative to the buffer's position (inclusive) ???? * and ends relative to the buffer's limit (exclusive). ???? *

???? * If the buffer is {@link ByteBuffer#isReadOnly() read-only}, the resulting segment will also be ???? * {@link ByteBuffer#isReadOnly() read-only}. The scope associated with this segment can either be the ???? * {@linkplain ResourceScope#globalScope() global} resource scope, in case the buffer has been created independently, ???? * or some other resource scope, in case the buffer has been obtained using {@link #asByteBuffer()}. ???? *

???? * The resulting memory segment keeps a reference to the backing buffer, keeping it reachable. ???? * ???? * @param bb the byte buffer backing the buffer memory segment. ???? * @return a new buffer memory segment. ???? */ But I don't see how it could be looking at AbstractMemorySegmentImpl.ofBuffer(), it just creates the segment using (long, long, int, scope) ??? public static AbstractMemorySegmentImpl ofBuffer(ByteBuffer bb) { ... ??????????? return new NativeMemorySegmentImpl(bbAddress + pos, size, modes, bufferScope); ... ??? } For what it's worth this is the code i'm using.? IntArray is just a thin wrapper over MemorySegment. ??? IntArray loadSPIRV(String name) throws IOException { ?? ???? try (InputStream is = TestVulkan.class.getResourceAsStream(name)) { ?? ???? ??? ByteBuffer bb = ByteBuffer.allocateDirect(8192).order(ByteOrder.nativeOrder()); ?? ???? ??? int length = Channels.newChannel(is).read(bb); ?? ???? ??? bb.position(0); ?? ???? ??? bb.limit(length); ?? ???? ??? return IntArray.create(MemorySegment.ofByteBuffer(bb)); ?? ???? } ?? ?} ??? IntArray mandelbrot_cs; ??? void demo() throws Exception { ?? ???? mandelbrot_cs = loadSPIRV("mandelbrot.bin"); ??????? ... at some point later and before i use it it's junk, vulkan crashes? ... ??? } If I keep a hard reference to 'bb' then it works fine indicating it's probably getting gc'd otherwise. ??? ByteBuffer bb; ?? ?IntArray loadSPIRV(String name) throws IOException { ... ?? ???? ??? bb.position(0); ?? ???? ??? bb.limit(length); ??????????? this.bb = bb; ... ??? } This version of loadSPIRV works fine: ??? IntArray loadSPIRV(String name) throws IOException { ?? ???? try (InputStream is = TestVulkan.class.getResourceAsStream(name)) { ?? ???? ??? MemorySegment seg = ((SegmentAllocator)scope).allocateArray(Memory.INT, 2048); ?? ???? ??? int length = Channels.newChannel(is).read(seg.asByteBuffer()); ?? ???? ??? return IntArray.create(seg.asSlice(0, length)); ?? ???? } ?? ?} Regards, ?!Z From cleber.muramoto at gmail.com Sat Feb 5 17:01:07 2022 From: cleber.muramoto at gmail.com (Cleber Muramoto) Date: Sat, 5 Feb 2022 14:01:07 -0300 Subject: [foreign] Mesuring downcall stub performance Message-ID: Hello, I'm trying to understand the overhead of calling a downcall stub generated by jextract. The source I'm using can be found on https://github.com/cmuramoto/test-jextract Basically, I have the following piece of code MemorySegment data = loadFile(); // mmaps a text file with keywords, 1 per line (\n = separator) MemorySegment trie = loadTrie(); // mmaps a trie data structure that maps string->int The trie is a contiguous array of pairs (int, int), which are fetched using int base(MemorySegment ms,long offset) { return ms.get(JAVA_INT, offset<<3); } int check(MemorySegment ms,long offset) { return ms.get(JAVA_INT, 4L + ( offset<<3)); } And the lookup method is as follows // finds the value associated with the key data.slice(pos, end - pos) long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ var from = 0L; var to = 0L; while (pos < end) { to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); if(check(trie, to) != from) { return ABSENT; // 1L<<33 } from = to; pos++; } to = base(trie, from); var check = check(trie, to); if (check != i32(from)) { return NO_VALUE; // 1L << 32 } return base(array, to); } Running this code on a file with ~10 million lines with a fully populated trie (so that every lookup succeeds), I measured a peak throughput of 391ns/query. This lookup code suffers from bounds checking (which are unnecessary given how the trie constrains its 'jumps' from a previous to a current offset, but the JVM can't possibly know about this) and using Unsafe directly gives a pretty decent boost, but still can't match a C++ counterpart. Based on the lookup code, I created an assembly version that receives the segment's raw addresses and the length of the string, compiled it with nasm, and created a shared library with ld: nasm -felf64 trie.asm -o trie.o ld -z noexecstack -shared trie.o -o libtrie.so Then generated the stubs with jextract: jextract -t trie.asm --source -ltrie trie.h trie.h declares de lookup function and a noop ( xor rax, rax ret) which I used as a baseline to measure a 3-arg call overhead, which in my environment is about ~18ns/call. A compiled C++ code linked against libtrie.so manages to achieve ~210ns/query. My naive expectation was that on the Java side I would get, roughly, C throughput + 20ns ? 230ns/call, but so far I have the following: (best out of 10 loops) jdk-17 branch -native - 288 ns/query -unsafe - 282 ns/query jdk-19 branch -native - 372 ns/query -memory-segments - 391 ns/query -unsafe - 317 ns/query I did not use JMH, but the tests were executed with EpsilonGC and the hot paths are allocation-free. So I wonder, on the JVM side, is there any difference in the intrinsic call overhead when invoking a noop vs a real function (both with the same type of arguments)? If not, how can I profile the culprit? I tried async-profiler but the flame graph seems dominated by the assembly labels of libtrie.so (especially the inc3) Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? Cheers! From notzed at gmail.com Sun Feb 6 02:38:18 2022 From: notzed at gmail.com (Michael Zucchi) Date: Sun, 6 Feb 2022 13:08:18 +1030 Subject: experiments in panama code generation Message-ID: <4215ee1d-29bf-afc6-9f9d-e06091dfd452@gmail.com> All, For what it's worth i've published [1,2,3] the code generator i've been working on for the last few weeks (months? - i've spent way more time on it than i care to admit).? It's of course more work in progress than panama but maybe someone will find something of use, if nothing else the generated code has some examples of how to use the current apis.? The gcc plugin is also quite complete for extracting all available information that can then be used by other tools, although it's one hell of a mess of code at this point. It contains some examples for a toy api (for prototyping), ffmpeg (plays video frames in a jframe), opencl (does some info queries), and vulkan (runs a compute shader and shows the result in a jframe).? They all use a common helper module (notzed.nativez) for various reasons i sort of don't like that but its hard to avoid. The original cause was to do the stuff jextract wasn't ever going to - more selective and direct config-driven generation of java-friendly apis from c header files.? jextract can be more selective than it used to be when i started but the rest is much the same.? Apparently also bitfields? Simple example of what i'm trying for: class cl_h { ??? public static int clEnqueueReadBuffer( ??? ??? Addressable command_queue, ?? ???? Addressable buffer, ?? ???? int blocking_read, ??? ??? long offset, ??? ??? long size, ??? ??? Addressable ptr, ??? ??? int num_events_in_wait_list, ?? ???? Addressable event_wait_list, ??? ??? Addressable event) { ... } } Weird class name, no type checking, must check return, must manage the wait list by hand.? Having to use MemoryAddress.NULL for nulls. To make a usable api for general consumption one has to write another class to call this one - but that either needs another complete c parser and generator, or a lot of manual labour. vs class CL { ??????? public static void clEnqueueReadBuffer( ??? ??? ??? cl_command_queue command_queue, ??? ??? ??? cl_mem buffer, ??? ??? ??? int blocking_read, ??? ??? ??? long offset, ??? ??? ??? long size, ??? ??? ??? MemoryAddress ptr, ??? ??? ??? cl_event_list event_wait_list, ??? ??? ??? cl_event_list event) { ... } } Simple class name, typed arguments, throws exception on error, the event list is managed/updated automatically, implied parameters don't need to be supplied, simple null for null.? This is direct output from a fairly simple config file [4]. Structures and unions are similar. ? Classes are typed holders of MemorySegment and have normal java getters and setters, anything can be renamed to be more java-like, fields can be excluded if they're private or not useful, can be read/write and indexed acceess is optional.? It's quit a pity you can't implement Addressable as it would just be so much tidier than having to reimplement the same thing for the same purpose but in an incompatible way. I suppose my aim is to keep working on it until it's complete enough and then create some specific libraries that use it.? A secondary aim will be to explore approaches/code-size/performance.? But how long that takes and what i do depends on where my interests take me. Why?? Just for fun really, it's just a puzzle to solve.? I've taken a few years off working and i'm getting a bit bored of going for bicycle rides/drinking at the pub/reading books/gardening/playstation/cooking and i've got some long-standing jni projects to update to panama. Cheers, ?!Z aka Michael [1] https://code.zedzone.space/cvs?p=panamaz;a=blob_plain;f=README;hb=HEAD README [2] https://code.zedzone.space/cvs?p=panamaz&a=tree Source tree browser. [3] https://code.zedzone.space/git/panamaz git url [4] https://code.zedzone.space/cvs?p=panamaz;a=blob_plain;f=src/notzed.clstatic/gen/opencl.api;hb=HEAD || From maurizio.cimadamore at oracle.com Mon Feb 7 10:49:13 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 10:49:13 +0000 Subject: resource scopes and close actions In-Reply-To: <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> Message-ID: <311b838b-e44a-4d91-6f7f-3a50b0eb8e76@oracle.com> If you want a "scoped" memory address, please look at NativeSymbol. This is used by the lookup functions provided by the JDK, but is also useful to capture an address and associate a scope with it. This allows you to model everything with one field (NativeSymbol) and then no liveness check is needed, just pass the symbol to the method handle, and standard safety checks will apply. Maurizio On 05/02/2022 09:16, Michael Zucchi wrote: > OpenCL (& Vulkan) does everything via handles (typed anonymous > pointers), so presumably represented by MemoryAddress.? What approach > to use here to make them scope-safe?? Have explicit scope tests before > using them in calls? > > If one wanted a scope-protected MemoryAddress this seems to be the > only solution in the present api: > > CLCommandQueue { > ? ResourceScope scope; > ? MemoryAddress handle; > > ? void enqueueNDRangeKernel(...) { > ??? try (ResourceScope scope = ResourceScope.newConfinedScope()) { > ?????? scope.keepAlive(this.scope); > ???????? enqueueNDRangeKernel$MH.invokeExact((Addressable)handle, ...); > ??? } catch (IllegalStateException ex) { > ??? } > ? } > } > > Actually it's a bit worse because there will be handles (possibly in > different scopes) in the argument list and they would all need to be > checked in the same way. > > So for practicality they would have to be MemorySegment (ideally > length=0) since they are always checked? From maurizio.cimadamore at oracle.com Mon Feb 7 10:57:28 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 10:57:28 +0000 Subject: MemorySegment.ofByteBuffer(ByteBuffer.allocateDirect()) In-Reply-To: References: Message-ID: <40fe1f11-d50b-1c9b-4906-cb0f6b13c755@oracle.com> Ah, that's a bug, thanks. It should create a non-closeable global scope that keeps reference the byte buffer. We have that code to keep class loaders alive: ResourceScopeImpl.heapScope(bb); Maurizio On 05/02/2022 11:27, Michael Zucchi wrote: > > Evening, > > I'm seeing a direct ByteBuffer being freed while still used by a > MemorySegment.ofByteBuffer().?? I'm apparently using foreign-jextract > @ commit 6c3e90789b1a6590894f09c2027a7fcf9e23af06 (Fri Jan 28 11:01:26 > 2022) but it hasn't changed for months. > > The docs for ofByteBuffer() explicitly state the backing buffer is > referenced. > > ??? /** > ???? * Creates a new buffer memory segment that models the memory > associated with the given byte > ???? * buffer. The segment starts relative to the buffer's position > (inclusive) > ???? * and ends relative to the buffer's limit (exclusive). > ???? *

> ???? * If the buffer is {@link ByteBuffer#isReadOnly() read-only}, the > resulting segment will also be > ???? * {@link ByteBuffer#isReadOnly() read-only}. The scope associated > with this segment can either be the > ???? * {@linkplain ResourceScope#globalScope() global} resource scope, > in case the buffer has been created independently, > ???? * or some other resource scope, in case the buffer has been > obtained using {@link #asByteBuffer()}. > ???? *

> ???? * The resulting memory segment keeps a reference to the backing > buffer, keeping it reachable. > ???? * > ???? * @param bb the byte buffer backing the buffer memory segment. > ???? * @return a new buffer memory segment. > ???? */ > > But I don't see how it could be looking at > AbstractMemorySegmentImpl.ofBuffer(), it just creates the segment > using (long, long, int, scope) > > ??? public static AbstractMemorySegmentImpl ofBuffer(ByteBuffer bb) { > ... > ??????????? return new NativeMemorySegmentImpl(bbAddress + pos, size, > modes, bufferScope); > ... > ??? } > > For what it's worth this is the code i'm using.? IntArray is just a > thin wrapper over MemorySegment. > > ??? IntArray loadSPIRV(String name) throws IOException { > ?? ???? try (InputStream is = > TestVulkan.class.getResourceAsStream(name)) { > ?? ???? ??? ByteBuffer bb = > ByteBuffer.allocateDirect(8192).order(ByteOrder.nativeOrder()); > ?? ???? ??? int length = Channels.newChannel(is).read(bb); > > ?? ???? ??? bb.position(0); > ?? ???? ??? bb.limit(length); > > ?? ???? ??? return IntArray.create(MemorySegment.ofByteBuffer(bb)); > ?? ???? } > ?? ?} > ??? IntArray mandelbrot_cs; > > ??? void demo() throws Exception { > ?? ???? mandelbrot_cs = loadSPIRV("mandelbrot.bin"); > > ??????? ... at some point later and before i use it it's junk, vulkan > crashes? ... > ??? } > > If I keep a hard reference to 'bb' then it works fine indicating it's > probably getting gc'd otherwise. > > ??? ByteBuffer bb; > > ?? ?IntArray loadSPIRV(String name) throws IOException { > ... > ?? ???? ??? bb.position(0); > ?? ???? ??? bb.limit(length); > > ??????????? this.bb = bb; > ... > ??? } > > This version of loadSPIRV works fine: > > ??? IntArray loadSPIRV(String name) throws IOException { > ?? ???? try (InputStream is = > TestVulkan.class.getResourceAsStream(name)) { > ?? ???? ??? MemorySegment seg = > ((SegmentAllocator)scope).allocateArray(Memory.INT, 2048); > ?? ???? ??? int length = > Channels.newChannel(is).read(seg.asByteBuffer()); > > ?? ???? ??? return IntArray.create(seg.asSlice(0, length)); > ?? ???? } > ?? ?} > > > Regards, > ?!Z From maurizio.cimadamore at oracle.com Mon Feb 7 11:16:14 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 11:16:14 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: References: Message-ID: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> Hi, your estimate of 18ns/call seems accurate. We do have JMH benchmark which measures no-op calls and results are similar. We'd need to investigate re. bound checks (but there is some work going on in the area, see [1]) and, more importantly, performance regression w.r.t. 17. There are no VM changes from 17 to 18 - the onlt thing that changed was that now we also check by-reference parameters in downcall for liveness - but in this case you're using MemoryAddress parameters, so your code is not impacted by that. It's also interesting that the Unsafe path got slower as well in the transition from 17 to 19, which is odd. It would also help if the native benchmark had correspoding C/C++ code, for portability. Thanks Maurizio On 05/02/2022 17:01, Cleber Muramoto wrote: > Hello, I'm trying to understand the overhead of calling a downcall stub > generated by jextract. > > The source I'm using can be found on > https://github.com/cmuramoto/test-jextract > > Basically, I have the following piece of code > > MemorySegment data = loadFile(); // mmaps a text file with keywords, 1 per > line (\n = separator) > MemorySegment trie = loadTrie(); // mmaps a trie data structure that maps > string->int > > The trie is a contiguous array of pairs (int, int), which are fetched using > > int base(MemorySegment ms,long offset) { > return ms.get(JAVA_INT, offset<<3); > } > > int check(MemorySegment ms,long offset) { > return ms.get(JAVA_INT, 4L + ( offset<<3)); > } > > And the lookup method is as follows > > // finds the value associated with the key data.slice(pos, end - pos) > long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ > var from = 0L; > var to = 0L; > > while (pos < end) { > to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); > if(check(trie, to) != from) { > return ABSENT; // 1L<<33 > } > from = to; > pos++; > } > > to = base(trie, from); > var check = check(trie, to); > > if (check != i32(from)) { > return NO_VALUE; // 1L << 32 > } > return base(array, to); > } > > Running this code on a file with ~10 million lines with a fully populated > trie (so that every lookup succeeds), I measured a peak throughput of > 391ns/query. > > This lookup code suffers from bounds checking (which are unnecessary given > how the trie constrains its 'jumps' from a previous to a current offset, > but the JVM can't possibly know about this) and using Unsafe directly gives > a pretty decent boost, but still can't match a C++ counterpart. > > Based on the lookup code, I created an assembly version that receives the > segment's raw addresses and the length of the string, compiled it with > nasm, and created a shared library with ld: > > nasm -felf64 trie.asm -o trie.o > ld -z noexecstack -shared trie.o -o libtrie.so > > Then generated the stubs with jextract: > > jextract -t trie.asm --source -ltrie trie.h > > trie.h declares de lookup function and a noop ( xor rax, rax ret) which I > used as a baseline to measure a 3-arg call overhead, which in my > environment is about ~18ns/call. > > A compiled C++ code linked against libtrie.so manages to achieve > ~210ns/query. > > My naive expectation was that on the Java side I would get, roughly, C > throughput + 20ns ? 230ns/call, but so far I have the following: > > (best out of 10 loops) > jdk-17 branch > -native - 288 ns/query > -unsafe - 282 ns/query > > jdk-19 branch > -native - 372 ns/query > -memory-segments - 391 ns/query > -unsafe - 317 ns/query > > I did not use JMH, but the tests were executed with EpsilonGC and the hot > paths are allocation-free. > > So I wonder, on the JVM side, is there any difference in the intrinsic call > overhead when invoking a noop vs a real function (both with the same type > of arguments)? If not, how can I profile the culprit? I tried > async-profiler but the flame graph seems dominated by the assembly labels > of libtrie.so (especially the inc3) > > Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? > > Cheers! From maurizio.cimadamore at oracle.com Mon Feb 7 11:56:59 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 11:56:59 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> References: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> Message-ID: <8b986107-dbbd-dbc2-7635-6f1e20b73d23@oracle.com> Foregot to include a link: [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-December/015915.html Btw, I tried your benchmark, but it crashes left and right on my machine (Linux, x64). Seems like some out of bound memory access - I get an exception in the MemorySegment test and a plain crash when using unsafe. It seems like calls to base() end up returning very big offsets which are then out of bounds in the segments where they are used (the data segment is 133 bytes, while the trie file is 134 bytes). Not sure if something got truncated. Maurizio On 07/02/2022 11:16, Maurizio Cimadamore wrote: > Hi, > your estimate of 18ns/call seems accurate. We do have JMH benchmark > which measures no-op calls and results are similar. > > We'd need to investigate re. bound checks (but there is some work > going on in the area, see [1]) and, more importantly, performance > regression w.r.t. 17. > > There are no VM changes from 17 to 18 - the onlt thing that changed > was that now we also check by-reference parameters in downcall for > liveness - but in this case you're using MemoryAddress parameters, so > your code is not impacted by that. > > It's also interesting that the Unsafe path got slower as well in the > transition from 17 to 19, which is odd. > > It would also help if the native benchmark had correspoding C/C++ > code, for portability. > > Thanks > Maurizio > > On 05/02/2022 17:01, Cleber Muramoto wrote: >> Hello, I'm trying to understand the overhead of calling a downcall stub >> generated by jextract. >> >> The source I'm using can be found on >> https://github.com/cmuramoto/test-jextract >> >> Basically, I have the following piece of code >> >> MemorySegment data = loadFile(); // mmaps a text file with keywords, >> 1 per >> line (\n = separator) >> MemorySegment trie = loadTrie(); // mmaps a trie data structure that >> maps >> string->int >> >> The trie is a contiguous array of pairs (int, int), which are fetched >> using >> >> int base(MemorySegment ms,long offset) { >> ?? return ms.get(JAVA_INT, offset<<3); >> } >> >> int check(MemorySegment ms,long offset) { >> ?? return ms.get(JAVA_INT, 4L + ( offset<<3)); >> } >> >> And the lookup method is as follows >> >> // finds the value associated with the key data.slice(pos, end - pos) >> long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ >> ?? var from = 0L; >> ?? var to = 0L; >> >> while (pos < end) { >> to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); >> if(check(trie, to) != from) { >> return ABSENT; // 1L<<33 >> } >> from = to; >> pos++; >> } >> >> to = base(trie, from); >> var check = check(trie, to); >> >> ?? if (check != i32(from)) { >> ???? return NO_VALUE; // 1L << 32 >> ?? } >> ?? return base(array, to); >> } >> >> Running this code on a file with ~10 million lines with a fully >> populated >> trie (so that every lookup succeeds), I measured a peak throughput of >> 391ns/query. >> >> This lookup code suffers from bounds checking (which are unnecessary >> given >> how the trie constrains its 'jumps' from a previous to a current offset, >> but the JVM can't possibly know about this) and using Unsafe directly >> gives >> a pretty decent boost, but still can't match a C++ counterpart. >> >> Based on the lookup code, I created an assembly version that receives >> the >> segment's raw addresses and the length of the string, compiled it with >> nasm, and created a shared library with ld: >> >> nasm -felf64 trie.asm -o trie.o >> ld -z noexecstack -shared trie.o -o libtrie.so >> >> Then generated the stubs with jextract: >> >> jextract -t trie.asm --source -ltrie trie.h >> >> trie.h declares de lookup function and a noop ( xor rax, rax ret) >> which I >> used as a baseline to measure a 3-arg call overhead, which in my >> environment is about ~18ns/call. >> >> A compiled C++ code linked against libtrie.so manages to achieve >> ~210ns/query. >> >> My naive expectation was that on the Java side I would get, roughly, C >> throughput + 20ns ? 230ns/call, but so far I have the following: >> >> (best out of 10 loops) >> jdk-17 branch >> -native - 288 ns/query >> -unsafe - 282 ns/query >> >> jdk-19 branch >> -native - 372 ns/query >> -memory-segments - 391 ns/query >> -unsafe - 317 ns/query >> >> I did not use JMH, but the tests were executed with EpsilonGC and the >> hot >> paths are allocation-free. >> >> So I wonder, on the JVM side, is there any difference in the >> intrinsic call >> overhead when invoking a noop vs a real function (both with the same >> type >> of arguments)? If not, how can I profile the culprit? I tried >> async-profiler but the flame graph seems dominated by the assembly >> labels >> of libtrie.so (especially the inc3) >> >> Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? >> >> Cheers! From maurizio.cimadamore at oracle.com Mon Feb 7 12:03:21 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 12:03:21 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: <672612734.116476.1644075111745@email.ionos.de> References: <672612734.116476.1644075111745@email.ionos.de> Message-ID: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> Hi Clemens (it seems like your message got dropped by the mailing list, not sure why). Your message seems to point at some bad interaction between jpackage and Panama both trying to load ucrtbase.dll (and only one can win). Apparently, the Panama code isn't executed early enough in the jpackage case. We'll need to investigate more. Maurizio On 05/02/2022 15:31, Clemens Lanthaler wrote: > Hello everybody, > > I am the developer of project librawfx (github.com/lanthale/librawfx) > and the app Photoslide (github.com/lanthale/photoslide). > > At the begining of Photoslide the whole app was modularized and > therefore all was working including librawfx which is using project > Panama. After a while I had to change to a mixed (modulepath for > jdk+javafx libs and classpath for the rest) environment and deployed > my app PhotoSlide again. Under Linux and OSX all is working as > expected. The problem exists only under Windows. Furthermore it exists > only if I am creating a Jlink/Jpackage distribution. Running the app > from maven was working as expected. Only the JPackage launcher have > the issue and I have no clue what the root cause is. > > The exception I am always seeing is: > Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load > SCHWERWIEGEND: null > java.lang.UnsatisfiedLinkError: Native Library > C:\Windows\System32\ucrtbase.dll already loaded in another classloader > (Full stacktrace below) > > How can you reproduce the issue: > > 1. Git clone project https://github.com/lanthale/JeditFX.git > 2. Start the app with "mvn javafx:run at default-cli" > 3. Click on the open icon in the toolbar and select file > "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" > 4. The app is showing the image below the textarea > 5. Create the jlink/jpackage app-image with "mvn -Ppackage clean install" > 6. Start the exe jeditfx.exe in directory ".\target\jeditfx" > 7. Open the same file again -> No image is shown below the text area > and the exception is thrown in the background > > > I have tried many things but it is only happening if I have > OpenJFX+JDK Modules on the module path and the rest of the jar files > on the classpath. All libs which are not having any Panama code inside > of the app are working perfectly and it is only happening on Windows. > > Thank you in advance for your help! > > best regards, > Clemens > > > > > *Full stacktrace from Photoslide:* > > Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex > createSearchIndex > INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 > Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater > lambda$checkForSoftwareUpdates$2 > INFORMATION: No new version found! > Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex > lambda$createSearchIndex$0 > INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 > Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load > SCHWERWIEGEND: null > java.lang.UnsatisfiedLinkError: Native Library > C:\Windows\System32\ucrtbase.dll already loaded in another classloader > at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown > Source) > at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown > Source) > at > jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown > Source) > at > jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown > Source) > at > jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown > Source) > at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown > Source) > at > jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown > Source) > at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) > at org.libraw.win.libraw_h.(libraw_h.java:15) > at org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) > at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) > at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) > at > javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown > Source) > at > javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown > Source) > at > javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown > Source) > at > javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown > Source) > at > javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown > Source) > at javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown > Source) > at javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown > Source) > at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) > at > org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) > at > org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) > at > javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown > Source) > at java.base/java.util.concurrent.FutureTask.run(Unknown Source) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown > Source) > at java.base/java.util.concurrent.FutureTask.run(Unknown Source) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > at java.base/java.lang.Thread.run(Unknown Source) From mail at smogura.eu Mon Feb 7 12:12:50 2022 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Mon, 7 Feb 2022 12:12:50 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: <8b986107-dbbd-dbc2-7635-6f1e20b73d23@oracle.com> References: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> <8b986107-dbbd-dbc2-7635-6f1e20b73d23@oracle.com> Message-ID: Hi, This is just a wild guess. I wonder if the issues can be related to the usage of shared scopes, which use the volatile, loops with volatile may be hard to optimize. Did you consider using non-shared scopes (or derive somehow confined scopes from the shared scope in case of true multithreaded application)? Best regards, Rado ________________________________ From: panama-dev on behalf of Maurizio Cimadamore Sent: Monday, February 7, 2022 12:56 To: Cleber Muramoto ; panama-dev at openjdk.java.net Subject: Re: [foreign] Mesuring downcall stub performance Foregot to include a link: [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-December/015915.html Btw, I tried your benchmark, but it crashes left and right on my machine (Linux, x64). Seems like some out of bound memory access - I get an exception in the MemorySegment test and a plain crash when using unsafe. It seems like calls to base() end up returning very big offsets which are then out of bounds in the segments where they are used (the data segment is 133 bytes, while the trie file is 134 bytes). Not sure if something got truncated. Maurizio On 07/02/2022 11:16, Maurizio Cimadamore wrote: > Hi, > your estimate of 18ns/call seems accurate. We do have JMH benchmark > which measures no-op calls and results are similar. > > We'd need to investigate re. bound checks (but there is some work > going on in the area, see [1]) and, more importantly, performance > regression w.r.t. 17. > > There are no VM changes from 17 to 18 - the onlt thing that changed > was that now we also check by-reference parameters in downcall for > liveness - but in this case you're using MemoryAddress parameters, so > your code is not impacted by that. > > It's also interesting that the Unsafe path got slower as well in the > transition from 17 to 19, which is odd. > > It would also help if the native benchmark had correspoding C/C++ > code, for portability. > > Thanks > Maurizio > > On 05/02/2022 17:01, Cleber Muramoto wrote: >> Hello, I'm trying to understand the overhead of calling a downcall stub >> generated by jextract. >> >> The source I'm using can be found on >> https://github.com/cmuramoto/test-jextract >> >> Basically, I have the following piece of code >> >> MemorySegment data = loadFile(); // mmaps a text file with keywords, >> 1 per >> line (\n = separator) >> MemorySegment trie = loadTrie(); // mmaps a trie data structure that >> maps >> string->int >> >> The trie is a contiguous array of pairs (int, int), which are fetched >> using >> >> int base(MemorySegment ms,long offset) { >> return ms.get(JAVA_INT, offset<<3); >> } >> >> int check(MemorySegment ms,long offset) { >> return ms.get(JAVA_INT, 4L + ( offset<<3)); >> } >> >> And the lookup method is as follows >> >> // finds the value associated with the key data.slice(pos, end - pos) >> long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ >> var from = 0L; >> var to = 0L; >> >> while (pos < end) { >> to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); >> if(check(trie, to) != from) { >> return ABSENT; // 1L<<33 >> } >> from = to; >> pos++; >> } >> >> to = base(trie, from); >> var check = check(trie, to); >> >> if (check != i32(from)) { >> return NO_VALUE; // 1L << 32 >> } >> return base(array, to); >> } >> >> Running this code on a file with ~10 million lines with a fully >> populated >> trie (so that every lookup succeeds), I measured a peak throughput of >> 391ns/query. >> >> This lookup code suffers from bounds checking (which are unnecessary >> given >> how the trie constrains its 'jumps' from a previous to a current offset, >> but the JVM can't possibly know about this) and using Unsafe directly >> gives >> a pretty decent boost, but still can't match a C++ counterpart. >> >> Based on the lookup code, I created an assembly version that receives >> the >> segment's raw addresses and the length of the string, compiled it with >> nasm, and created a shared library with ld: >> >> nasm -felf64 trie.asm -o trie.o >> ld -z noexecstack -shared trie.o -o libtrie.so >> >> Then generated the stubs with jextract: >> >> jextract -t trie.asm --source -ltrie trie.h >> >> trie.h declares de lookup function and a noop ( xor rax, rax ret) >> which I >> used as a baseline to measure a 3-arg call overhead, which in my >> environment is about ~18ns/call. >> >> A compiled C++ code linked against libtrie.so manages to achieve >> ~210ns/query. >> >> My naive expectation was that on the Java side I would get, roughly, C >> throughput + 20ns ? 230ns/call, but so far I have the following: >> >> (best out of 10 loops) >> jdk-17 branch >> -native - 288 ns/query >> -unsafe - 282 ns/query >> >> jdk-19 branch >> -native - 372 ns/query >> -memory-segments - 391 ns/query >> -unsafe - 317 ns/query >> >> I did not use JMH, but the tests were executed with EpsilonGC and the >> hot >> paths are allocation-free. >> >> So I wonder, on the JVM side, is there any difference in the >> intrinsic call >> overhead when invoking a noop vs a real function (both with the same >> type >> of arguments)? If not, how can I profile the culprit? I tried >> async-profiler but the flame graph seems dominated by the assembly >> labels >> of libtrie.so (especially the inc3) >> >> Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? >> >> Cheers! From clemens.lanthaler at itarchitects.at Mon Feb 7 12:15:16 2022 From: clemens.lanthaler at itarchitects.at (clemens.lanthaler at itarchitects.at) Date: Mon, 7 Feb 2022 13:15:16 +0100 Subject: Issue in combination with JLink/JPackage In-Reply-To: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> Message-ID: Hi Maurizio, thanks allot for your help and for the investigation. best regards, Clemens > On 7. Feb 2022, at 13:03, Maurizio Cimadamore wrote: > > ? > Hi Clemens (it seems like your message got dropped by the mailing list, not sure why). > > Your message seems to point at some bad interaction between jpackage and Panama both trying to load ucrtbase.dll (and only one can win). Apparently, the Panama code isn't executed early enough in the jpackage case. > > We'll need to investigate more. > > Maurizio > > On 05/02/2022 15:31, Clemens Lanthaler wrote: >> Hello everybody, >> >> I am the developer of project librawfx (github.com/lanthale/librawfx) and the app Photoslide (github.com/lanthale/photoslide). >> >> At the begining of Photoslide the whole app was modularized and therefore all was working including librawfx which is using project Panama. After a while I had to change to a mixed (modulepath for jdk+javafx libs and classpath for the rest) environment and deployed my app PhotoSlide again. Under Linux and OSX all is working as expected. The problem exists only under Windows. Furthermore it exists only if I am creating a Jlink/Jpackage distribution. Running the app from maven was working as expected. Only the JPackage launcher have the issue and I have no clue what the root cause is. >> >> The exception I am always seeing is: >> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >> SCHWERWIEGEND: null >> java.lang.UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll already loaded in another classloader >> (Full stacktrace below) >> >> How can you reproduce the issue: >> Git clone project https://github.com/lanthale/JeditFX.git >> Start the app with "mvn javafx:run at default-cli" >> Click on the open icon in the toolbar and select file "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >> The app is showing the image below the textarea >> Create the jlink/jpackage app-image with "mvn -Ppackage clean install" >> Start the exe jeditfx.exe in directory ".\target\jeditfx" >> Open the same file again -> No image is shown below the text area and the exception is thrown in the background >> >> I have tried many things but it is only happening if I have OpenJFX+JDK Modules on the module path and the rest of the jar files on the classpath. All libs which are not having any Panama code inside of the app are working perfectly and it is only happening on Windows. >> >> Thank you in advance for your help! >> >> best regards, >> Clemens >> >> >> >> >> Full stacktrace from Photoslide: >> >> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex createSearchIndex >> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater lambda$checkForSoftwareUpdates$2 >> INFORMATION: No new version found! >> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex lambda$createSearchIndex$0 >> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >> SCHWERWIEGEND: null >> java.lang.UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll already loaded in another classloader >> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) >> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) >> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown Source) >> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown Source) >> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown Source) >> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown Source) >> at jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown Source) >> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >> at org.libraw.win.libraw_h.(libraw_h.java:15) >> at org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >> at javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown Source) >> at javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown Source) >> at javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown Source) >> at javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown Source) >> at javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown Source) >> at javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown Source) >> at javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown Source) >> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >> at org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >> at org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >> at javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown Source) >> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) >> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) >> at java.base/java.lang.Thread.run(Unknown Source) From maurizio.cimadamore at oracle.com Mon Feb 7 12:18:19 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 12:18:19 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: References: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> <8b986107-dbbd-dbc2-7635-6f1e20b73d23@oracle.com> Message-ID: On 07/02/2022 12:12, Rados?aw Smogura wrote: > Hi, > > This is just a wild guess. > > I wonder if the issues can be related to the usage of shared scopes, > which use the volatile, loops with volatile may be hard to optimize. > > Did you consider using non-shared scopes (or derive somehow confined > scopes from the shared scope in case of true multithreaded application)? Not sure - when accessing memory, there's no volatile access anywhere. You get volatile semantics only when closing - but AFAIK, the benchmark creates a single global scope which is then "leaked". So I don't think scope can be an issue here. (hard to say though, given that I can't manage to get the bits running :-) ). Maurizio > > Best regards, > Rado > ------------------------------------------------------------------------ > *From:* panama-dev on behalf of > Maurizio Cimadamore > *Sent:* Monday, February 7, 2022 12:56 > *To:* Cleber Muramoto ; > panama-dev at openjdk.java.net > *Subject:* Re: [foreign] Mesuring downcall stub performance > Foregot to include a link: > > [1] - > https://mail.openjdk.java.net/pipermail/panama-dev/2021-December/015915.html > > Btw, I tried your benchmark, but it crashes left and right on my machine > (Linux, x64). > > Seems like some out of bound memory access - I get an exception in the > MemorySegment test and a plain crash when using unsafe. It seems like > calls to base() end up returning very big offsets which are then out of > bounds in the segments where they are used (the data segment is 133 > bytes, while the trie file is 134 bytes). Not sure if something got > truncated. > > Maurizio > > On 07/02/2022 11:16, Maurizio Cimadamore wrote: > > Hi, > > your estimate of 18ns/call seems accurate. We do have JMH benchmark > > which measures no-op calls and results are similar. > > > > We'd need to investigate re. bound checks (but there is some work > > going on in the area, see [1]) and, more importantly, performance > > regression w.r.t. 17. > > > > There are no VM changes from 17 to 18 - the onlt thing that changed > > was that now we also check by-reference parameters in downcall for > > liveness - but in this case you're using MemoryAddress parameters, so > > your code is not impacted by that. > > > > It's also interesting that the Unsafe path got slower as well in the > > transition from 17 to 19, which is odd. > > > > It would also help if the native benchmark had correspoding C/C++ > > code, for portability. > > > > Thanks > > Maurizio > > > > On 05/02/2022 17:01, Cleber Muramoto wrote: > >> Hello, I'm trying to understand the overhead of calling a downcall stub > >> generated by jextract. > >> > >> The source I'm using can be found on > >> https://github.com/cmuramoto/test-jextract > > >> > >> Basically, I have the following piece of code > >> > >> MemorySegment data = loadFile(); // mmaps a text file with keywords, > >> 1 per > >> line (\n = separator) > >> MemorySegment trie = loadTrie(); // mmaps a trie data structure that > >> maps > >> string->int > >> > >> The trie is a contiguous array of pairs (int, int), which are fetched > >> using > >> > >> int base(MemorySegment ms,long offset) { > >> ?? return ms.get(JAVA_INT, offset<<3); > >> } > >> > >> int check(MemorySegment ms,long offset) { > >> ?? return ms.get(JAVA_INT, 4L + ( offset<<3)); > >> } > >> > >> And the lookup method is as follows > >> > >> // finds the value associated with the key data.slice(pos, end - pos) > >> long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ > >> ?? var from = 0L; > >> ?? var to = 0L; > >> > >> while (pos < end) { > >> to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); > >> if(check(trie, to) != from) { > >> return ABSENT; // 1L<<33 > >> } > >> from = to; > >> pos++; > >> } > >> > >> to = base(trie, from); > >> var check = check(trie, to); > >> > >> ?? if (check != i32(from)) { > >> ???? return NO_VALUE; // 1L << 32 > >> ?? } > >> ?? return base(array, to); > >> } > >> > >> Running this code on a file with ~10 million lines with a fully > >> populated > >> trie (so that every lookup succeeds), I measured a peak throughput of > >> 391ns/query. > >> > >> This lookup code suffers from bounds checking (which are unnecessary > >> given > >> how the trie constrains its 'jumps' from a previous to a current > offset, > >> but the JVM can't possibly know about this) and using Unsafe directly > >> gives > >> a pretty decent boost, but still can't match a C++ counterpart. > >> > >> Based on the lookup code, I created an assembly version that receives > >> the > >> segment's raw addresses and the length of the string, compiled it with > >> nasm, and created a shared library with ld: > >> > >> nasm -felf64 trie.asm -o trie.o > >> ld -z noexecstack -shared trie.o -o libtrie.so > >> > >> Then generated the stubs with jextract: > >> > >> jextract -t trie.asm --source -ltrie trie.h > >> > >> trie.h declares de lookup function and a noop ( xor rax, rax ret) > >> which I > >> used as a baseline to measure a 3-arg call overhead, which in my > >> environment is about ~18ns/call. > >> > >> A compiled C++ code linked against libtrie.so manages to achieve > >> ~210ns/query. > >> > >> My naive expectation was that on the Java side I would get, roughly, C > >> throughput + 20ns ? 230ns/call, but so far I have the following: > >> > >> (best out of 10 loops) > >> jdk-17 branch > >> -native - 288 ns/query > >> -unsafe - 282 ns/query > >> > >> jdk-19 branch > >> -native - 372 ns/query > >> -memory-segments - 391 ns/query > >> -unsafe - 317 ns/query > >> > >> I did not use JMH, but the tests were executed with EpsilonGC and the > >> hot > >> paths are allocation-free. > >> > >> So I wonder, on the JVM side, is there any difference in the > >> intrinsic call > >> overhead when invoking a noop vs a real function (both with the same > >> type > >> of arguments)? If not, how can I profile the culprit? I tried > >> async-profiler but the flame graph seems dominated by the assembly > >> labels > >> of libtrie.so (especially the inc3) > >> > >> Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? > >> > >> Cheers! From maurizio.cimadamore at oracle.com Mon Feb 7 12:19:05 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 12:19:05 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> Message-ID: No problem. I've filed this: https://bugs.openjdk.java.net/browse/JDK-8281335 Cheers Maurizio On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: > Hi Maurizio, > > thanks allot for your help and for the investigation. > > best regards, > Clemens > > >> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >> wrote: >> >> ? >> >> Hi Clemens (it seems like your message got dropped by the mailing >> list, not sure why). >> >> Your message seems to point at some bad interaction between jpackage >> and Panama both trying to load ucrtbase.dll (and only one can win). >> Apparently, the Panama code isn't executed early enough in the >> jpackage case. >> >> We'll need to investigate more. >> >> Maurizio >> >> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>> Hello everybody, >>> >>> I am the developer of project librawfx >>> (github.com/lanthale/librawfx) and the app Photoslide >>> (github.com/lanthale/photoslide). >>> >>> At the begining of Photoslide the whole app was modularized and >>> therefore all was working including librawfx which is using project >>> Panama. After a while I had to change to a mixed (modulepath for >>> jdk+javafx libs and classpath for the rest) environment and deployed >>> my app PhotoSlide again. Under Linux and OSX all is working as >>> expected. The problem exists only under Windows. Furthermore it >>> exists only if I am creating a Jlink/Jpackage distribution. Running >>> the app from maven was working as expected. Only the JPackage >>> launcher have the issue and I have no clue what the root cause is. >>> >>> The exception I am always seeing is: >>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>> SCHWERWIEGEND: null >>> java.lang.UnsatisfiedLinkError: Native Library >>> C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>> (Full stacktrace below) >>> >>> How can you reproduce the issue: >>> >>> 1. Git clone project https://github.com/lanthale/JeditFX.git >>> 2. Start the app with "mvn javafx:run at default-cli" >>> 3. Click on the open icon in the toolbar and select file >>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>> 4. The app is showing the image below the textarea >>> 5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>> install" >>> 6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>> 7. Open the same file again -> No image is shown below the text >>> area and the exception is thrown in the background >>> >>> >>> I have tried many things but it is only happening if I have >>> OpenJFX+JDK Modules on the module path and the rest of the jar files >>> on the classpath. All libs which are not having any Panama code >>> inside of the app are working perfectly and it is only happening on >>> Windows. >>> >>> Thank you in advance for your help! >>> >>> best regards, >>> Clemens >>> >>> >>> >>> >>> *Full stacktrace from Photoslide:* >>> >>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>> createSearchIndex >>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>> lambda$checkForSoftwareUpdates$2 >>> INFORMATION: No new version found! >>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>> lambda$createSearchIndex$0 >>> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>> SCHWERWIEGEND: null >>> java.lang.UnsatisfiedLinkError: Native Library >>> C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>> Source) >>> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>> Source) >>> at >>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>> Source) >>> at >>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>> Source) >>> at >>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>> Source) >>> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>> Source) >>> at >>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>> Source) >>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>> at >>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>> at >>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>> Source) >>> at >>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>> Source) >>> at >>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>> Source) >>> at >>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>> Source) >>> at >>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>> Source) >>> at javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>> Source) >>> at javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>> Source) >>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>> at >>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>> >>> at >>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>> >>> at >>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>> Source) >>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>> at >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>> Source) >>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>> at >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>> Source) >>> at >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>> Source) >>> at java.base/java.lang.Thread.run(Unknown Source) From maurizio.cimadamore at oracle.com Mon Feb 7 12:19:34 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 12:19:34 +0000 Subject: MemorySegment.ofByteBuffer(ByteBuffer.allocateDirect()) In-Reply-To: <40fe1f11-d50b-1c9b-4906-cb0f6b13c755@oracle.com> References: <40fe1f11-d50b-1c9b-4906-cb0f6b13c755@oracle.com> Message-ID: On 07/02/2022 10:57, Maurizio Cimadamore wrote: > Ah, that's a bug, thanks. Filed: https://bugs.openjdk.java.net/browse/JDK-8281334 Maurizio > > It should create a non-closeable global scope that keeps reference the > byte buffer. We have that code to keep class loaders alive: > > ResourceScopeImpl.heapScope(bb); > > Maurizio > > On 05/02/2022 11:27, Michael Zucchi wrote: >> >> Evening, >> >> I'm seeing a direct ByteBuffer being freed while still used by a >> MemorySegment.ofByteBuffer().?? I'm apparently using foreign-jextract >> @ commit 6c3e90789b1a6590894f09c2027a7fcf9e23af06 (Fri Jan 28 >> 11:01:26 2022) but it hasn't changed for months. >> >> The docs for ofByteBuffer() explicitly state the backing buffer is >> referenced. >> >> ??? /** >> ???? * Creates a new buffer memory segment that models the memory >> associated with the given byte >> ???? * buffer. The segment starts relative to the buffer's position >> (inclusive) >> ???? * and ends relative to the buffer's limit (exclusive). >> ???? *

>> ???? * If the buffer is {@link ByteBuffer#isReadOnly() read-only}, >> the resulting segment will also be >> ???? * {@link ByteBuffer#isReadOnly() read-only}. The scope >> associated with this segment can either be the >> ???? * {@linkplain ResourceScope#globalScope() global} resource >> scope, in case the buffer has been created independently, >> ???? * or some other resource scope, in case the buffer has been >> obtained using {@link #asByteBuffer()}. >> ???? *

>> ???? * The resulting memory segment keeps a reference to the backing >> buffer, keeping it reachable. >> ???? * >> ???? * @param bb the byte buffer backing the buffer memory segment. >> ???? * @return a new buffer memory segment. >> ???? */ >> >> But I don't see how it could be looking at >> AbstractMemorySegmentImpl.ofBuffer(), it just creates the segment >> using (long, long, int, scope) >> >> ??? public static AbstractMemorySegmentImpl ofBuffer(ByteBuffer bb) { >> ... >> ??????????? return new NativeMemorySegmentImpl(bbAddress + pos, size, >> modes, bufferScope); >> ... >> ??? } >> >> For what it's worth this is the code i'm using.? IntArray is just a >> thin wrapper over MemorySegment. >> >> ??? IntArray loadSPIRV(String name) throws IOException { >> ?? ???? try (InputStream is = >> TestVulkan.class.getResourceAsStream(name)) { >> ?? ???? ??? ByteBuffer bb = >> ByteBuffer.allocateDirect(8192).order(ByteOrder.nativeOrder()); >> ?? ???? ??? int length = Channels.newChannel(is).read(bb); >> >> ?? ???? ??? bb.position(0); >> ?? ???? ??? bb.limit(length); >> >> ?? ???? ??? return IntArray.create(MemorySegment.ofByteBuffer(bb)); >> ?? ???? } >> ?? ?} >> ??? IntArray mandelbrot_cs; >> >> ??? void demo() throws Exception { >> ?? ???? mandelbrot_cs = loadSPIRV("mandelbrot.bin"); >> >> ??????? ... at some point later and before i use it it's junk, vulkan >> crashes? ... >> ??? } >> >> If I keep a hard reference to 'bb' then it works fine indicating it's >> probably getting gc'd otherwise. >> >> ??? ByteBuffer bb; >> >> ?? ?IntArray loadSPIRV(String name) throws IOException { >> ... >> ?? ???? ??? bb.position(0); >> ?? ???? ??? bb.limit(length); >> >> ??????????? this.bb = bb; >> ... >> ??? } >> >> This version of loadSPIRV works fine: >> >> ??? IntArray loadSPIRV(String name) throws IOException { >> ?? ???? try (InputStream is = >> TestVulkan.class.getResourceAsStream(name)) { >> ?? ???? ??? MemorySegment seg = >> ((SegmentAllocator)scope).allocateArray(Memory.INT, 2048); >> ?? ???? ??? int length = >> Channels.newChannel(is).read(seg.asByteBuffer()); >> >> ?? ???? ??? return IntArray.create(seg.asSlice(0, length)); >> ?? ???? } >> ?? ?} >> >> >> Regards, >> ?!Z From mcimadamore at openjdk.java.net Mon Feb 7 13:14:54 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 13:14:54 GMT Subject: [foreign-preview] RFR: 8281334: MemorySegment.ofBuffer does not keep byte buffer alive Message-ID: <6FxtEVxBYrgV6Xslt_rbV-qqMXmHaS-cWRriGs2lU6U=.2280e0a6-f6a2-4d35-84cc-7b3d4529131d@github.com> This patch tweaks AbstractMemorySegmentImpl::ofBuffer to create an heap scope which keeps the input ByteBuffer alive, in case the returned segment has to be associated with a global scope. ------------- Commit messages: - Remove unused import in test - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/639/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=639&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281334 Stats: 25 lines in 2 files changed: 24 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/639.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/639/head:pull/639 PR: https://git.openjdk.java.net/panama-foreign/pull/639 From cleber.muramoto at gmail.com Mon Feb 7 13:36:35 2022 From: cleber.muramoto at gmail.com (Cleber Muramoto) Date: Mon, 7 Feb 2022 10:36:35 -0300 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> References: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> Message-ID: Hi Maurizio. Probably git LFS messed up. The keys and trie files should be 95MB and 280MB, respectively. You'll find the files in this drive link: https://drive.google.com/drive/folders/1x-imW6MLZNdcJSolmG2B0B06OCYKLU8i The benchmark code for C++ can be found under native folder (bench.cpp), just run ./compile.bench.sh shared ./run.shared.sh I found that odd too that Unsafe got slower in comparison to jdk-17. I'll create a branch with the corresponding code. Regards On Mon, Feb 7, 2022 at 8:16 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > your estimate of 18ns/call seems accurate. We do have JMH benchmark > which measures no-op calls and results are similar. > > We'd need to investigate re. bound checks (but there is some work going > on in the area, see [1]) and, more importantly, performance regression > w.r.t. 17. > > There are no VM changes from 17 to 18 - the onlt thing that changed was > that now we also check by-reference parameters in downcall for liveness > - but in this case you're using MemoryAddress parameters, so your code > is not impacted by that. > > It's also interesting that the Unsafe path got slower as well in the > transition from 17 to 19, which is odd. > > It would also help if the native benchmark had correspoding C/C++ code, > for portability. > > Thanks > Maurizio > > On 05/02/2022 17:01, Cleber Muramoto wrote: > > Hello, I'm trying to understand the overhead of calling a downcall stub > > generated by jextract. > > > > The source I'm using can be found on > > https://github.com/cmuramoto/test-jextract > > > > Basically, I have the following piece of code > > > > MemorySegment data = loadFile(); // mmaps a text file with keywords, 1 > per > > line (\n = separator) > > MemorySegment trie = loadTrie(); // mmaps a trie data structure that maps > > string->int > > > > The trie is a contiguous array of pairs (int, int), which are fetched > using > > > > int base(MemorySegment ms,long offset) { > > return ms.get(JAVA_INT, offset<<3); > > } > > > > int check(MemorySegment ms,long offset) { > > return ms.get(JAVA_INT, 4L + ( offset<<3)); > > } > > > > And the lookup method is as follows > > > > // finds the value associated with the key data.slice(pos, end - pos) > > long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ > > var from = 0L; > > var to = 0L; > > > > while (pos < end) { > > to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); > > if(check(trie, to) != from) { > > return ABSENT; // 1L<<33 > > } > > from = to; > > pos++; > > } > > > > to = base(trie, from); > > var check = check(trie, to); > > > > if (check != i32(from)) { > > return NO_VALUE; // 1L << 32 > > } > > return base(array, to); > > } > > > > Running this code on a file with ~10 million lines with a fully populated > > trie (so that every lookup succeeds), I measured a peak throughput of > > 391ns/query. > > > > This lookup code suffers from bounds checking (which are unnecessary > given > > how the trie constrains its 'jumps' from a previous to a current offset, > > but the JVM can't possibly know about this) and using Unsafe directly > gives > > a pretty decent boost, but still can't match a C++ counterpart. > > > > Based on the lookup code, I created an assembly version that receives the > > segment's raw addresses and the length of the string, compiled it with > > nasm, and created a shared library with ld: > > > > nasm -felf64 trie.asm -o trie.o > > ld -z noexecstack -shared trie.o -o libtrie.so > > > > Then generated the stubs with jextract: > > > > jextract -t trie.asm --source -ltrie trie.h > > > > trie.h declares de lookup function and a noop ( xor rax, rax ret) which I > > used as a baseline to measure a 3-arg call overhead, which in my > > environment is about ~18ns/call. > > > > A compiled C++ code linked against libtrie.so manages to achieve > > ~210ns/query. > > > > My naive expectation was that on the Java side I would get, roughly, C > > throughput + 20ns ? 230ns/call, but so far I have the following: > > > > (best out of 10 loops) > > jdk-17 branch > > -native - 288 ns/query > > -unsafe - 282 ns/query > > > > jdk-19 branch > > -native - 372 ns/query > > -memory-segments - 391 ns/query > > -unsafe - 317 ns/query > > > > I did not use JMH, but the tests were executed with EpsilonGC and the hot > > paths are allocation-free. > > > > So I wonder, on the JVM side, is there any difference in the intrinsic > call > > overhead when invoking a noop vs a real function (both with the same type > > of arguments)? If not, how can I profile the culprit? I tried > > async-profiler but the flame graph seems dominated by the assembly labels > > of libtrie.so (especially the inc3) > > > > Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? > > > > Cheers! > From duncan.gittins at gmail.com Mon Feb 7 13:44:55 2022 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Mon, 7 Feb 2022 13:44:55 +0000 Subject: Fwd: jextract / jpackage / JavaFX - Windows library load issue In-Reply-To: <68ace13e-6cd0-cf79-86cb-04c263250cc5@gmail.com> References: <68ace13e-6cd0-cf79-86cb-04c263250cc5@gmail.com> Message-ID: <9bdbcb72-f19c-fc8f-dd37-ec5b76ea639f@gmail.com> The jpackage / JavaFX issue sounds like the one I reported in May - see below. There is a workaround - depending on which Panama version you are using - by editing the RuntimeHelper.lookup() call to eliminate the CLinker.systemLookup(). This might introduce other issues, but did not affect my own jextract / jpackage / JavaFX app. https://bugs.openjdk.java.net/browse/JDK-8281335 I don't apply this workaround now for RuntimeHelper of my JavaFX / jpackage app - not sure if bug still applies, I will scan my source code. Also note earlier versions of jpackage messed up library path on Windows. Kind regards Duncan -------- Forwarded Message -------- Subject: jextract / jpackage / JavaFX - Windows library load issue Date: Sat, 22 May 2021 13:34:25 +0100 From: Duncan Gittins To: panama-dev at openjdk.java.net It's great to see you've released a new Panama/foreign EA - much appreciated. Here is some feedback which I noticed in EA and latest panama-foreign for a recent change in behaviour when using jextract / jpackage together for a JavaFX application. I use jextract on 5 headers - one package per Windows library (Ole32_h / Shell32 / User / Kernel32 / Advapi). My different app runs fine from command line with "java", but the same jars+runtime inside jpackage EXE always gives library load errors for jextract code called by a JavaFX app: Caused by: java.lang.UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll already loaded in another classloader ??????? ... ??????? at jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown Source) ??????? at duncan.win.ole.RuntimeHelper.lookup(RuntimeHelper.java:50) ??????? at duncan.win.ole.Ole32_h.(Ole32_h.java:16) ??????? at duncan.panama.Ole32.CoInitialize(Unknown Source) Non-JavaFX apps using jextract code all run fine as EXE. My easy workaround is to hand edit 5x RuntimeHelper.lookup() to omit use of "systemLookup": ??? static SymbolLookup lookup() { ??????? SymbolLookup loaderLookup = SymbolLookup.loaderLookup(); ??????? // THIS LINE CAUSES UnsatisfiedLinkError: SymbolLookup systemLookup = CLinker.systemLookup(); ??????? return name -> loaderLookup.lookup(name) /*.or(() -> systemLookup.lookup(name)) */; ??? } Do you have suggestions on what I should be doing? If nothing obvious, and as I've not given much detail on reproducing this issue, I could try to set up a minimal test case to help with further investigations. BTW I mentioned in different thread a few weeks ago that jpackage has changed between JDK16 and JDK17. New jpackage strips the Windows default library path from java.library.path, so you have to add "--java-options -Djava.library.path=c:\\Windows\\System32" to allow jpackage to run any Panama code as Windows EXE. The library load error as above appears in EXEs generated by both versions of jpackage. Kind regards Duncan From maurizio.cimadamore at oracle.com Mon Feb 7 13:55:34 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 13:55:34 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: References: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> Message-ID: On 07/02/2022 13:36, Cleber Muramoto wrote: > Hi Maurizio. > > Probably git LFS messed up. The keys and trie files should be 95MB and > 280MB, respectively. I downloaded the file directly from github and it now works. Here's what I get: unsafe ns/q: 335.05 native: ns/q: 339.13 segment: ns/q: 329.15 (for each, I only listed the best result - not sure how to parse all the numbers the benchmark generates, so I only used the very first one :-)). In general, using the latest Panama EA, I couldn't really tell the three benchmark apart, and, also, I noticed that numbers can vary quite a bit from run to run. Maurizio > > You'll find the files in this drive link: > > https://drive.google.com/drive/folders/1x-imW6MLZNdcJSolmG2B0B06OCYKLU8i > > > The benchmark code for C++ can be found under native folder > (bench.cpp), just run > > ./compile.bench.sh > > shared > ./run.shared.sh > > > I found that odd too that Unsafe got slower in comparison to jdk-17. > I'll create a branch with the corresponding code. > > Regards > > On Mon, Feb 7, 2022 at 8:16 AM Maurizio Cimadamore > wrote: > > Hi, > your estimate of 18ns/call seems accurate. We do have JMH benchmark > which measures no-op calls and results are similar. > > We'd need to investigate re. bound checks (but there is some work > going > on in the area, see [1]) and, more importantly, performance > regression > w.r.t. 17. > > There are no VM changes from 17 to 18 - the onlt thing that > changed was > that now we also check by-reference parameters in downcall for > liveness > - but in this case you're using MemoryAddress parameters, so your > code > is not impacted by that. > > It's also interesting that the Unsafe path got slower as well in the > transition from 17 to 19, which is odd. > > It would also help if the native benchmark had correspoding C/C++ > code, > for portability. > > Thanks > Maurizio > > On 05/02/2022 17:01, Cleber Muramoto wrote: > > Hello, I'm trying to understand the overhead of calling a > downcall stub > > generated by jextract. > > > > The source I'm using can be found on > > https://github.com/cmuramoto/test-jextract > > > > > Basically, I have the following piece of code > > > > MemorySegment data = loadFile(); // mmaps a text file with > keywords, 1 per > > line (\n = separator) > > MemorySegment trie = loadTrie(); // mmaps a trie data structure > that maps > > string->int > > > > The trie is a contiguous array of pairs (int, int), which are > fetched using > > > > int base(MemorySegment ms,long offset) { > >? ? return ms.get(JAVA_INT, offset<<3); > > } > > > > int check(MemorySegment ms,long offset) { > >? ? return ms.get(JAVA_INT, 4L + ( offset<<3)); > > } > > > > And the lookup method is as follows > > > > // finds the value associated with the key data.slice(pos, end - > pos) > > long lookup(MemorySegment trie, MemorySegment data, int pos, int > end){ > >? ? var from = 0L; > >? ? var to = 0L; > > > > while (pos < end) { > > to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); > > if(check(trie, to) != from) { > > return ABSENT; // 1L<<33 > > } > > from = to; > > pos++; > > } > > > > to = base(trie, from); > > var check = check(trie, to); > > > >? ? if (check != i32(from)) { > >? ? ? return NO_VALUE; // 1L << 32 > >? ? } > >? ? return base(array, to); > > } > > > > Running this code on a file with ~10 million lines with a fully > populated > > trie (so that every lookup succeeds), I measured a peak > throughput of > > 391ns/query. > > > > This lookup code suffers from bounds checking (which are > unnecessary given > > how the trie constrains its 'jumps' from a previous to a current > offset, > > but the JVM can't possibly know about this) and using Unsafe > directly gives > > a pretty decent boost, but still can't match a C++ counterpart. > > > > Based on the lookup code, I created an assembly version that > receives the > > segment's raw addresses and the length of the string, compiled > it with > > nasm, and created a shared library with ld: > > > > nasm -felf64 trie.asm -o trie.o > > ld -z noexecstack -shared trie.o -o libtrie.so > > > > Then generated the stubs with jextract: > > > > jextract -t trie.asm --source -ltrie trie.h > > > > trie.h declares de lookup function and a noop ( xor rax, rax > ret) which I > > used as a baseline to measure a 3-arg call overhead, which in my > > environment is about ~18ns/call. > > > > A compiled C++ code linked against libtrie.so manages to achieve > > ~210ns/query. > > > > My naive expectation was that on the Java side I would get, > roughly, C > > throughput + 20ns ? 230ns/call, but so far I have the following: > > > > (best out of 10 loops) > > jdk-17 branch > > -native - 288 ns/query > > -unsafe - 282 ns/query > > > > jdk-19 branch > > -native - 372 ns/query > > -memory-segments - 391 ns/query > > -unsafe - 317 ns/query > > > > I did not use JMH, but the tests were executed with EpsilonGC > and the hot > > paths are allocation-free. > > > > So I wonder, on the JVM side, is there any difference in the > intrinsic call > > overhead when invoking a noop vs a real function (both with the > same type > > of arguments)? If not, how can I profile the culprit? I tried > > async-profiler but the flame graph seems dominated by the > assembly labels > > of libtrie.so (especially the inc3) > > > > Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? > > > > Cheers! > From duncan.gittins at gmail.com Mon Feb 7 14:24:00 2022 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Mon, 7 Feb 2022 14:24:00 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> Message-ID: See my other email on this. I found that the issue in RuntimeHelper.lookup() was caused by failed symbol lookups for global variables that I did not depend on (and which cannot be found in DLL, only static LIB - so won't ever resolve in Panama?) Because jextract puts multiple definitions per class trying accessing a required caused failed lookups to try to access ucrtbase.dll You may be able to bypass the issue by either: 1) using jextract with "-Djextract.constants.per.class=0". This puts every symbol into own class, so when any class is loaded it does not trigger any unnecessary symbol lookups 2) use jextract with exact types so jextract only generates the exact set of symbols you need: ??? --include-macro xyz ??? --include-function xyz The above should help as long as you aren't depending on the actual library load of ucrtbase.dll. Kind regards Duncan On 07/02/2022 12:19, Maurizio Cimadamore wrote: > No problem. > > I've filed this: > > https://bugs.openjdk.java.net/browse/JDK-8281335 > > Cheers > Maurizio > > On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >> Hi Maurizio, >> >> thanks allot for your help and for the investigation. >> >> best regards, >> Clemens >> >> >>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>> wrote: >>> >>> ? >>> >>> Hi Clemens (it seems like your message got dropped by the mailing >>> list, not sure why). >>> >>> Your message seems to point at some bad interaction between jpackage >>> and Panama both trying to load ucrtbase.dll (and only one can win). >>> Apparently, the Panama code isn't executed early enough in the >>> jpackage case. >>> >>> We'll need to investigate more. >>> >>> Maurizio >>> >>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>> Hello everybody, >>>> >>>> I am the developer of project librawfx >>>> (github.com/lanthale/librawfx) and the app Photoslide >>>> (github.com/lanthale/photoslide). >>>> >>>> At the begining of Photoslide the whole app was modularized and >>>> therefore all was working including librawfx which is using project >>>> Panama. After a while I had to change to a mixed (modulepath for >>>> jdk+javafx libs and classpath for the rest) environment and >>>> deployed my app PhotoSlide again. Under Linux and OSX all is >>>> working as expected. The problem exists only under Windows. >>>> Furthermore it exists only if I am creating a Jlink/Jpackage >>>> distribution. Running the app from maven was working as expected. >>>> Only the JPackage launcher have the issue and I have no clue what >>>> the root cause is. >>>> >>>> The exception I am always seeing is: >>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>> SCHWERWIEGEND: null >>>> java.lang.UnsatisfiedLinkError: Native Library >>>> C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>>> (Full stacktrace below) >>>> >>>> How can you reproduce the issue: >>>> >>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>>> ?2. Start the app with "mvn javafx:run at default-cli" >>>> ?3. Click on the open icon in the toolbar and select file >>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>> ?4. The app is showing the image below the textarea >>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>>> ??? install" >>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>> ?7. Open the same file again -> No image is shown below the text >>>> ??? area and the exception is thrown in the background >>>> >>>> >>>> I have tried many things but it is only happening if I have >>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>>> files on the classpath. All libs which are not having any Panama >>>> code inside of the app are working perfectly and it is only >>>> happening on Windows. >>>> >>>> Thank you in advance for your help! >>>> >>>> best regards, >>>> Clemens >>>> >>>> >>>> >>>> >>>> *Full stacktrace from Photoslide:* >>>> >>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>>> createSearchIndex >>>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>>> lambda$checkForSoftwareUpdates$2 >>>> INFORMATION: No new version found! >>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>>> lambda$createSearchIndex$0 >>>> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>> SCHWERWIEGEND: null >>>> java.lang.UnsatisfiedLinkError: Native Library >>>> C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>>> at >>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>> Source) >>>> at >>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>>> Source) >>>> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>>> Source) >>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>> at >>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>>> Source) >>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>>> Source) >>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>>> at >>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>> >>>> at >>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>> >>>> at >>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>>> Source) >>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>> at >>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>>> Source) >>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>> Source) >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>> Source) >>>> at java.base/java.lang.Thread.run(Unknown Source) From maurizio.cimadamore at oracle.com Mon Feb 7 14:25:07 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 14:25:07 +0000 Subject: Fwd: jextract / jpackage / JavaFX - Windows library load issue In-Reply-To: <9bdbcb72-f19c-fc8f-dd37-ec5b76ea639f@gmail.com> References: <68ace13e-6cd0-cf79-86cb-04c263250cc5@gmail.com> <9bdbcb72-f19c-fc8f-dd37-ec5b76ea639f@gmail.com> Message-ID: Hi Duncan, thanks for the workaround. This is obviously fine for now, but IMHO, system lookup should never throw, regardless of the environment. Maurizio On 07/02/2022 13:44, Duncan Gittins wrote: > The jpackage / JavaFX issue sounds like the one I reported in May - > see below. There is a workaround - depending on which Panama version > you are using - by editing the RuntimeHelper.lookup() call to > eliminate the CLinker.systemLookup(). This might introduce other > issues, but did not affect my own jextract / jpackage / JavaFX app. > > https://bugs.openjdk.java.net/browse/JDK-8281335 > > I don't apply this workaround now for RuntimeHelper of my JavaFX / > jpackage app - not sure if bug still applies, I will scan my source > code. Also note earlier versions of jpackage messed up library path on > Windows. > > Kind regards > > Duncan > > -------- Forwarded Message -------- > Subject:???? jextract / jpackage / JavaFX - Windows library load issue > Date:???? Sat, 22 May 2021 13:34:25 +0100 > From:???? Duncan Gittins > To:???? panama-dev at openjdk.java.net > > > > It's great to see you've released a new Panama/foreign EA - much > appreciated. Here is some feedback which I noticed in EA and latest > panama-foreign for a recent change in behaviour when using jextract / > jpackage together for a JavaFX application. > > I use jextract on 5 headers - one package per Windows library (Ole32_h > / Shell32 / User / Kernel32 / Advapi). My different app runs fine from > command line with "java", but the same jars+runtime inside jpackage > EXE always gives library load errors for jextract code called by a > JavaFX app: > > Caused by: java.lang.UnsatisfiedLinkError: Native Library > C:\Windows\System32\ucrtbase.dll already loaded in another classloader > > ??????? ... > ??????? at > jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown > Source) > ??????? at duncan.win.ole.RuntimeHelper.lookup(RuntimeHelper.java:50) > ??????? at duncan.win.ole.Ole32_h.(Ole32_h.java:16) > ??????? at duncan.panama.Ole32.CoInitialize(Unknown Source) > > Non-JavaFX apps using jextract code all run fine as EXE. My easy > workaround is to hand edit 5x RuntimeHelper.lookup() to omit use of > "systemLookup": > > ??? static SymbolLookup lookup() { > ??????? SymbolLookup loaderLookup = SymbolLookup.loaderLookup(); > ??????? // THIS LINE CAUSES UnsatisfiedLinkError: SymbolLookup > systemLookup = CLinker.systemLookup(); > ??????? return name -> loaderLookup.lookup(name) /*.or(() -> > systemLookup.lookup(name)) */; > ??? } > > Do you have suggestions on what I should be doing? If nothing obvious, > and as I've not given much detail on reproducing this issue, I could > try to set up a minimal test case to help with further investigations. > > BTW I mentioned in different thread a few weeks ago that jpackage has > changed between JDK16 and JDK17. New jpackage strips the Windows > default library path from java.library.path, > so you have to add "--java-options > -Djava.library.path=c:\\Windows\\System32" to allow jpackage to run > any Panama code as Windows EXE. The library load error as above > appears in EXEs generated by both versions of jpackage. > > Kind regards > > Duncan From maurizio.cimadamore at oracle.com Mon Feb 7 14:27:20 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 14:27:20 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: References: <0079ecb3-1f87-845d-6a9f-d785fa88e1fa@oracle.com> Message-ID: <92ac1e6a-8f8f-5b8c-058e-e022a82eda78@oracle.com> On 07/02/2022 13:55, Maurizio Cimadamore wrote: > unsafe > ns/q: 335.05 Actually, this is incorrect - my run configuration was wrong. I was running the benchmark from intellij, which did not apply the settings as per your sh files. Updated numbers: unsafe ns/q: 286.67 native: ns/q: 340.21 segment: ns/q: 340.98 I noted that the native script disables tiered compilation. Also, in general, in seems like things are faster with regular VM parameters. I have a feeling that we might need to turn this into a JMH benchmark. On a very superficial look, while Unsafe clearly will remove bound checks from the code, I'm not sure about the native benchmark; that benchmark class still does quite a bit of access using memory segment. Just for fun, I put together a MemoryAddress variant of the benchmark class, which should perform much closer to unsafe. Here's the number I got: 254.87 ns/q Which seems even faster than unsafe (but it's probably just a blip). In other words, it seems to me that the memory segment benchmark pays for bound checks, the native one pays for bound checks _and_ native calls. The memory address version pays for none of that (but then you don't get any safety). Maurizio From duncan.gittins at gmail.com Mon Feb 7 14:57:50 2022 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Mon, 7 Feb 2022 14:57:50 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> Message-ID: <527b1a18-e506-caaf-56bc-e28961a49a40@gmail.com> Excuse my bad explanation, line below should read: Because by default jextract puts multiple definitions per class, trying to access a required symbol loads all symbols generated into the same class. If one of those additional symbols is un-resolvable such as a Windows global variable, the alternative branch of RuntimeHelper.lookup() accesses ucrtbase.dll => hits the conflict with jpackage/JavaFX. I've tried undoing my changes for 1/2 below, removing either workaround causes "UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll" regression in my application. Kind regards Duncan On 07/02/2022 14:24, Duncan Gittins wrote: > See my other email on this. I found that the issue in > RuntimeHelper.lookup() was caused by failed symbol lookups for global > variables that I did not depend on (and which cannot be found in DLL, > only static LIB - so won't ever resolve in Panama?) > > Because jextract puts multiple definitions per class trying accessing > a required caused failed lookups to try to access ucrtbase.dll > > You may be able to bypass the issue by either: > 1) using jextract with "-Djextract.constants.per.class=0". This puts > every symbol into own class, so when any class is loaded it does not > trigger any unnecessary symbol lookups > 2) use jextract with exact types so jextract only generates the exact > set of symbols you need: > ??? --include-macro xyz > ??? --include-function xyz > > The above should help as long as you aren't depending on the actual > library load of ucrtbase.dll. > > Kind regards > > Duncan > > On 07/02/2022 12:19, Maurizio Cimadamore wrote: >> No problem. >> >> I've filed this: >> >> https://bugs.openjdk.java.net/browse/JDK-8281335 >> >> Cheers >> Maurizio >> >> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >>> Hi Maurizio, >>> >>> thanks allot for your help and for the investigation. >>> >>> best regards, >>> Clemens >>> >>> >>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>>> wrote: >>>> >>>> ? >>>> >>>> Hi Clemens (it seems like your message got dropped by the mailing >>>> list, not sure why). >>>> >>>> Your message seems to point at some bad interaction between >>>> jpackage and Panama both trying to load ucrtbase.dll (and only one >>>> can win). Apparently, the Panama code isn't executed early enough >>>> in the jpackage case. >>>> >>>> We'll need to investigate more. >>>> >>>> Maurizio >>>> >>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>>> Hello everybody, >>>>> >>>>> I am the developer of project librawfx >>>>> (github.com/lanthale/librawfx) and the app Photoslide >>>>> (github.com/lanthale/photoslide). >>>>> >>>>> At the begining of Photoslide the whole app was modularized and >>>>> therefore all was working including librawfx which is using >>>>> project Panama. After a while I had to change to a mixed >>>>> (modulepath for jdk+javafx libs and classpath for the rest) >>>>> environment and deployed my app PhotoSlide again. Under Linux and >>>>> OSX all is working as expected. The problem exists only under >>>>> Windows. Furthermore it exists only if I am creating a >>>>> Jlink/Jpackage distribution. Running the app from maven was >>>>> working as expected. Only the JPackage launcher have the issue and >>>>> I have no clue what the root cause is. >>>>> >>>>> The exception I am always seeing is: >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>> SCHWERWIEGEND: null >>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>> classloader >>>>> (Full stacktrace below) >>>>> >>>>> How can you reproduce the issue: >>>>> >>>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>>>> ?2. Start the app with "mvn javafx:run at default-cli" >>>>> ?3. Click on the open icon in the toolbar and select file >>>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>>> >>>>> ?4. The app is showing the image below the textarea >>>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>>>> ??? install" >>>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>>> ?7. Open the same file again -> No image is shown below the text >>>>> ??? area and the exception is thrown in the background >>>>> >>>>> >>>>> I have tried many things but it is only happening if I have >>>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>>>> files on the classpath. All libs which are not having any Panama >>>>> code inside of the app are working perfectly and it is only >>>>> happening on Windows. >>>>> >>>>> Thank you in advance for your help! >>>>> >>>>> best regards, >>>>> Clemens >>>>> >>>>> >>>>> >>>>> >>>>> *Full stacktrace from Photoslide:* >>>>> >>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>>>> createSearchIndex >>>>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>>>> lambda$checkForSoftwareUpdates$2 >>>>> INFORMATION: No new version found! >>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>>>> lambda$createSearchIndex$0 >>>>> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>> SCHWERWIEGEND: null >>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>> classloader >>>>> at >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>> Source) >>>>> at >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>>>> Source) >>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>>> at >>>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>>> >>>>> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>>>> Source) >>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>>>> at >>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>>> >>>>> at >>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>>> >>>>> at >>>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>>>> Source) >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>> at >>>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>>>> Source) >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>> at >>>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>>> Source) >>>>> at >>>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>> Source) >>>>> at java.base/java.lang.Thread.run(Unknown Source) > > From clemens.lanthaler at itarchitects.at Mon Feb 7 15:32:05 2022 From: clemens.lanthaler at itarchitects.at (clemens.lanthaler at itarchitects.at) Date: Mon, 7 Feb 2022 16:32:05 +0100 Subject: Issue in combination with JLink/JPackage In-Reply-To: <527b1a18-e506-caaf-56bc-e28961a49a40@gmail.com> References: <527b1a18-e506-caaf-56bc-e28961a49a40@gmail.com> Message-ID: Ok I will try your first workaround with jextract flag and see if something is going better. > On 7. Feb 2022, at 15:57, Duncan Gittins wrote: > > ?Excuse my bad explanation, line below should read: > > Because by default jextract puts multiple definitions per class, trying to access a required symbol loads all symbols generated into the same class. If one of those additional symbols is un-resolvable such as a Windows global variable, the alternative branch of RuntimeHelper.lookup() accesses ucrtbase.dll => hits the conflict with jpackage/JavaFX. > > I've tried undoing my changes for 1/2 below, removing either workaround causes "UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll" regression in my application. > > Kind regards > > Duncan > >> On 07/02/2022 14:24, Duncan Gittins wrote: >> See my other email on this. I found that the issue in RuntimeHelper.lookup() was caused by failed symbol lookups for global variables that I did not depend on (and which cannot be found in DLL, only static LIB - so won't ever resolve in Panama?) >> >> Because jextract puts multiple definitions per class trying accessing a required caused failed lookups to try to access ucrtbase.dll >> >> You may be able to bypass the issue by either: >> 1) using jextract with "-Djextract.constants.per.class=0". This puts every symbol into own class, so when any class is loaded it does not trigger any unnecessary symbol lookups >> 2) use jextract with exact types so jextract only generates the exact set of symbols you need: >> --include-macro xyz >> --include-function xyz >> >> The above should help as long as you aren't depending on the actual library load of ucrtbase.dll. >> >> Kind regards >> >> Duncan >> >>> On 07/02/2022 12:19, Maurizio Cimadamore wrote: >>> No problem. >>> >>> I've filed this: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8281335 >>> >>> Cheers >>> Maurizio >>> >>> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >>>> Hi Maurizio, >>>> >>>> thanks allot for your help and for the investigation. >>>> >>>> best regards, >>>> Clemens >>>> >>>> >>>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore wrote: >>>>> >>>>> ? >>>>> >>>>> Hi Clemens (it seems like your message got dropped by the mailing list, not sure why). >>>>> >>>>> Your message seems to point at some bad interaction between jpackage and Panama both trying to load ucrtbase.dll (and only one can win). Apparently, the Panama code isn't executed early enough in the jpackage case. >>>>> >>>>> We'll need to investigate more. >>>>> >>>>> Maurizio >>>>> >>>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>>>> Hello everybody, >>>>>> >>>>>> I am the developer of project librawfx (github.com/lanthale/librawfx) and the app Photoslide (github.com/lanthale/photoslide). >>>>>> >>>>>> At the begining of Photoslide the whole app was modularized and therefore all was working including librawfx which is using project Panama. After a while I had to change to a mixed (modulepath for jdk+javafx libs and classpath for the rest) environment and deployed my app PhotoSlide again. Under Linux and OSX all is working as expected. The problem exists only under Windows. Furthermore it exists only if I am creating a Jlink/Jpackage distribution. Running the app from maven was working as expected. Only the JPackage launcher have the issue and I have no clue what the root cause is. >>>>>> >>>>>> The exception I am always seeing is: >>>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>>> SCHWERWIEGEND: null >>>>>> java.lang.UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>>>>> (Full stacktrace below) >>>>>> >>>>>> How can you reproduce the issue: >>>>>> >>>>>> 1. Git clone project https://github.com/lanthale/JeditFX.git >>>>>> 2. Start the app with "mvn javafx:run at default-cli" >>>>>> 3. Click on the open icon in the toolbar and select file >>>>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>>>> 4. The app is showing the image below the textarea >>>>>> 5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>>>>> install" >>>>>> 6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>>>> 7. Open the same file again -> No image is shown below the text >>>>>> area and the exception is thrown in the background >>>>>> >>>>>> >>>>>> I have tried many things but it is only happening if I have OpenJFX+JDK Modules on the module path and the rest of the jar files on the classpath. All libs which are not having any Panama code inside of the app are working perfectly and it is only happening on Windows. >>>>>> >>>>>> Thank you in advance for your help! >>>>>> >>>>>> best regards, >>>>>> Clemens >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Full stacktrace from Photoslide:* >>>>>> >>>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex createSearchIndex >>>>>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater lambda$checkForSoftwareUpdates$2 >>>>>> INFORMATION: No new version found! >>>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex lambda$createSearchIndex$0 >>>>>> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >>>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>>> SCHWERWIEGEND: null >>>>>> java.lang.UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>>>>> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) >>>>>> at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) >>>>>> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown Source) >>>>>> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown Source) >>>>>> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown Source) >>>>>> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown Source) >>>>>> at jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown Source) >>>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>>>> at org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>>>> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>>>> at javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown Source) >>>>>> at javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown Source) >>>>>> at javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown Source) >>>>>> at javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown Source) >>>>>> at javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown Source) >>>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown Source) >>>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown Source) >>>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>>>>> at org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>>>> at org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>>>> at javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown Source) >>>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>>> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) >>>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>>> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) >>>>>> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) >>>>>> at java.base/java.lang.Thread.run(Unknown Source) >> >> > From maurizio.cimadamore at oracle.com Mon Feb 7 16:18:50 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 16:18:50 +0000 Subject: experiments in panama code generation In-Reply-To: <4215ee1d-29bf-afc6-9f9d-e06091dfd452@gmail.com> References: <4215ee1d-29bf-afc6-9f9d-e06091dfd452@gmail.com> Message-ID: <66ca0f2a-f904-3198-5394-43b99cbac97f@oracle.com> On 06/02/2022 02:38, Michael Zucchi wrote: > Structures and unions are similar. ? Classes are typed holders of > MemorySegment and have normal java getters and setters, anything can > be renamed to be more java-like, fields can be excluded if they're > private or not useful, can be read/write and indexed acceess is > optional.? It's quit a pity you can't implement Addressable as it > would just be so much tidier than having to reimplement the same thing > for the same purpose but in an incompatible way. Actually, we did some back and forth on this. There is no reason as to why Addressable could not be unsealed. I had in mind cases where structs would want to implement this - but then when reviewing it was decided it was better to start tighter and relax later on as required. Your use case seems to be similar to what I had in mind - and seems a good argument towards opening up Addressable. Maurizio From maurizio.cimadamore at oracle.com Mon Feb 7 17:43:08 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 17:43:08 +0000 Subject: experiments in panama code generation In-Reply-To: <66ca0f2a-f904-3198-5394-43b99cbac97f@oracle.com> References: <4215ee1d-29bf-afc6-9f9d-e06091dfd452@gmail.com> <66ca0f2a-f904-3198-5394-43b99cbac97f@oracle.com> Message-ID: <4be9ebf5-f1a9-0d6e-1b3c-5443b602e76e@oracle.com> On 07/02/2022 16:18, Maurizio Cimadamore wrote: > > On 06/02/2022 02:38, Michael Zucchi wrote: >> Structures and unions are similar. Classes are typed holders of >> MemorySegment and have normal java getters and setters, anything can >> be renamed to be more java-like, fields can be excluded if they're >> private or not useful, can be read/write and indexed acceess is >> optional.? It's quit a pity you can't implement Addressable as it >> would just be so much tidier than having to reimplement the same >> thing for the same purpose but in an incompatible way. > > Actually, we did some back and forth on this. There is no reason as to > why Addressable could not be unsealed. I had in mind cases where > structs would want to implement this - but then when reviewing it was > decided it was better to start tighter and relax later on as required. > > Your use case seems to be similar to what I had in mind - and seems a > good argument towards opening up Addressable. Hit "Send" too fast. There were actually reasons as to why having custom subtypes implementing Addressable might not be as useful as it seems at first. I captured that here: https://bugs.openjdk.java.net/browse/JDK-8281382 Long story short - instead of mapping StructFoo down to an address - if you have a MemorySegment, have a MS accessor instead, as that will work with the linker in the "correct" way (e.g. by keeping the segment alive for the duration of the call). In other words, Addresable is, mostly, an interface used by the foreign API to denote "by-ref" entities, whose temporal bounds have to be reasoned upon in various ways. Having custom "by-ref" is possible, but it's more than just having custom "Addressable" subtypes (you need a way to get at the scope too). Maurizio > > Maurizio > From jvernee at openjdk.java.net Mon Feb 7 17:59:32 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Feb 2022 17:59:32 GMT Subject: [foreign-preview] RFR: 8281334: MemorySegment.ofBuffer does not keep byte buffer alive In-Reply-To: <6FxtEVxBYrgV6Xslt_rbV-qqMXmHaS-cWRriGs2lU6U=.2280e0a6-f6a2-4d35-84cc-7b3d4529131d@github.com> References: <6FxtEVxBYrgV6Xslt_rbV-qqMXmHaS-cWRriGs2lU6U=.2280e0a6-f6a2-4d35-84cc-7b3d4529131d@github.com> Message-ID: On Mon, 7 Feb 2022 13:09:16 GMT, Maurizio Cimadamore wrote: > This patch tweaks AbstractMemorySegmentImpl::ofBuffer to create an heap scope which keeps the input ByteBuffer alive, in case the returned segment has to be associated with a global scope. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/639 From psandoz at openjdk.java.net Mon Feb 7 18:10:24 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 7 Feb 2022 18:10:24 GMT Subject: [foreign-preview] RFR: 8281334: MemorySegment.ofBuffer does not keep byte buffer alive In-Reply-To: <6FxtEVxBYrgV6Xslt_rbV-qqMXmHaS-cWRriGs2lU6U=.2280e0a6-f6a2-4d35-84cc-7b3d4529131d@github.com> References: <6FxtEVxBYrgV6Xslt_rbV-qqMXmHaS-cWRriGs2lU6U=.2280e0a6-f6a2-4d35-84cc-7b3d4529131d@github.com> Message-ID: On Mon, 7 Feb 2022 13:09:16 GMT, Maurizio Cimadamore wrote: > This patch tweaks AbstractMemorySegmentImpl::ofBuffer to create an heap scope which keeps the input ByteBuffer alive, in case the returned segment has to be associated with a global scope. Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/639 From mcimadamore at openjdk.java.net Mon Feb 7 18:10:25 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 18:10:25 GMT Subject: [foreign-preview] Integrated: 8281334: MemorySegment.ofBuffer does not keep byte buffer alive In-Reply-To: <6FxtEVxBYrgV6Xslt_rbV-qqMXmHaS-cWRriGs2lU6U=.2280e0a6-f6a2-4d35-84cc-7b3d4529131d@github.com> References: <6FxtEVxBYrgV6Xslt_rbV-qqMXmHaS-cWRriGs2lU6U=.2280e0a6-f6a2-4d35-84cc-7b3d4529131d@github.com> Message-ID: On Mon, 7 Feb 2022 13:09:16 GMT, Maurizio Cimadamore wrote: > This patch tweaks AbstractMemorySegmentImpl::ofBuffer to create an heap scope which keeps the input ByteBuffer alive, in case the returned segment has to be associated with a global scope. This pull request has now been integrated. Changeset: ccaa71ad Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/ccaa71adf2ca27021e98899c44492cf00a5e76be Stats: 25 lines in 2 files changed: 24 ins; 0 del; 1 mod 8281334: MemorySegment.ofBuffer does not keep byte buffer alive Reviewed-by: jvernee, psandoz ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/639 From clemens.lanthaler at itarchitects.at Mon Feb 7 21:21:38 2022 From: clemens.lanthaler at itarchitects.at (Clemens Lanthaler) Date: Mon, 7 Feb 2022 22:21:38 +0100 Subject: Issue in combination with JLink/JPackage In-Reply-To: <527b1a18-e506-caaf-56bc-e28961a49a40@gmail.com> References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> <527b1a18-e506-caaf-56bc-e28961a49a40@gmail.com> Message-ID: <4338b8c0-ca76-e65a-0a04-77907761b1e1@itarchitects.at> Hi everyone, as a workaround I have now commented out in RuntimeHelper.class under Windows the calls to CLinker.systemLookup(). Now it works again. Thanks for all the hint. Hopefully there will be a permanent fix for Windows and JPackage. Am 07.02.22 um 15:57 schrieb Duncan Gittins: > Excuse my bad explanation, line below should read: > > Because by default jextract puts multiple definitions per class, > trying to access a required symbol loads all symbols generated into > the same class. If one of those additional symbols is un-resolvable > such as a Windows global variable, the alternative branch of > RuntimeHelper.lookup() accesses ucrtbase.dll => hits the conflict with > jpackage/JavaFX. > > I've tried undoing my changes for 1/2 below, removing either > workaround causes "UnsatisfiedLinkError: Native Library > C:\Windows\System32\ucrtbase.dll" regression in my application. > > Kind regards > > Duncan > > On 07/02/2022 14:24, Duncan Gittins wrote: >> See my other email on this. I found that the issue in >> RuntimeHelper.lookup() was caused by failed symbol lookups for global >> variables that I did not depend on (and which cannot be found in DLL, >> only static LIB - so won't ever resolve in Panama?) >> >> Because jextract puts multiple definitions per class trying accessing >> a required caused failed lookups to try to access ucrtbase.dll >> >> You may be able to bypass the issue by either: >> 1) using jextract with "-Djextract.constants.per.class=0". This puts >> every symbol into own class, so when any class is loaded it does not >> trigger any unnecessary symbol lookups >> 2) use jextract with exact types so jextract only generates the exact >> set of symbols you need: >> ??? --include-macro xyz >> ??? --include-function xyz >> >> The above should help as long as you aren't depending on the actual >> library load of ucrtbase.dll. >> >> Kind regards >> >> Duncan >> >> On 07/02/2022 12:19, Maurizio Cimadamore wrote: >>> No problem. >>> >>> I've filed this: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8281335 >>> >>> Cheers >>> Maurizio >>> >>> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >>>> Hi Maurizio, >>>> >>>> thanks allot for your help and for the investigation. >>>> >>>> best regards, >>>> Clemens >>>> >>>> >>>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>>>> wrote: >>>>> >>>>> ? >>>>> >>>>> Hi Clemens (it seems like your message got dropped by the mailing >>>>> list, not sure why). >>>>> >>>>> Your message seems to point at some bad interaction between >>>>> jpackage and Panama both trying to load ucrtbase.dll (and only one >>>>> can win). Apparently, the Panama code isn't executed early enough >>>>> in the jpackage case. >>>>> >>>>> We'll need to investigate more. >>>>> >>>>> Maurizio >>>>> >>>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>>>> Hello everybody, >>>>>> >>>>>> I am the developer of project librawfx >>>>>> (github.com/lanthale/librawfx) and the app Photoslide >>>>>> (github.com/lanthale/photoslide). >>>>>> >>>>>> At the begining of Photoslide the whole app was modularized and >>>>>> therefore all was working including librawfx which is using >>>>>> project Panama. After a while I had to change to a mixed >>>>>> (modulepath for jdk+javafx libs and classpath for the rest) >>>>>> environment and deployed my app PhotoSlide again. Under Linux and >>>>>> OSX all is working as expected. The problem exists only under >>>>>> Windows. Furthermore it exists only if I am creating a >>>>>> Jlink/Jpackage distribution. Running the app from maven was >>>>>> working as expected. Only the JPackage launcher have the issue >>>>>> and I have no clue what the root cause is. >>>>>> >>>>>> The exception I am always seeing is: >>>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>>> SCHWERWIEGEND: null >>>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>>> classloader >>>>>> (Full stacktrace below) >>>>>> >>>>>> How can you reproduce the issue: >>>>>> >>>>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>>>>> ?2. Start the app with "mvn javafx:run at default-cli" >>>>>> ?3. Click on the open icon in the toolbar and select file >>>>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>>>> >>>>>> ?4. The app is showing the image below the textarea >>>>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>>>>> ??? install" >>>>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>>>> ?7. Open the same file again -> No image is shown below the text >>>>>> ??? area and the exception is thrown in the background >>>>>> >>>>>> >>>>>> I have tried many things but it is only happening if I have >>>>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>>>>> files on the classpath. All libs which are not having any Panama >>>>>> code inside of the app are working perfectly and it is only >>>>>> happening on Windows. >>>>>> >>>>>> Thank you in advance for your help! >>>>>> >>>>>> best regards, >>>>>> Clemens >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Full stacktrace from Photoslide:* >>>>>> >>>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>>>>> createSearchIndex >>>>>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>>>>> lambda$checkForSoftwareUpdates$2 >>>>>> INFORMATION: No new version found! >>>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>>>>> lambda$createSearchIndex$0 >>>>>> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >>>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>>> SCHWERWIEGEND: null >>>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>>> classloader >>>>>> at >>>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>>> Source) >>>>>> at >>>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>>> Source) >>>>>> at >>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>>>>> Source) >>>>>> at >>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>>>>> Source) >>>>>> at >>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>>>>> Source) >>>>>> at >>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>>>>> Source) >>>>>> at >>>>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>>>>> Source) >>>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>>>> at >>>>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>>>> >>>>>> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>>>> at >>>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>>> Source) >>>>>> at >>>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>>> Source) >>>>>> at >>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>>>>> Source) >>>>>> at >>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>>>>> Source) >>>>>> at >>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>>>>> Source) >>>>>> at >>>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>>>>> Source) >>>>>> at >>>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>>>>> Source) >>>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>>>>> at >>>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>>>> >>>>>> at >>>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>>>> >>>>>> at >>>>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>>>>> Source) >>>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>>> at >>>>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>>>>> Source) >>>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>>> at >>>>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>>>> Source) >>>>>> at >>>>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>>> Source) >>>>>> at java.base/java.lang.Thread.run(Unknown Source) >> >> > -- ITArchitects CEO: B.Sc. Clemens Lanthaler Forchachstrasse 3 A-6166 Fulpmes Tel.: +43 (0)650 855 2954 email: office at itarchitects.at homepage: http://www.itarchitects.at ------------------------------------------------- Notice: This e-mail and any attachments are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. From maurizio.cimadamore at oracle.com Mon Feb 7 21:23:00 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 21:23:00 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: <4338b8c0-ca76-e65a-0a04-77907761b1e1@itarchitects.at> References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> <527b1a18-e506-caaf-56bc-e28961a49a40@gmail.com> <4338b8c0-ca76-e65a-0a04-77907761b1e1@itarchitects.at> Message-ID: <2240d868-79c6-2e90-6049-cd54ae9bd54b@oracle.com> Glad it works (for now). We'll see if we can do a more permanent fix (I certainly hope so!). Thanks Maurizio On 07/02/2022 21:21, Clemens Lanthaler wrote: > Hi everyone, > > as a workaround I have now commented out in RuntimeHelper.class under > Windows the calls to CLinker.systemLookup(). > > Now it works again. Thanks for all the hint. > > Hopefully there will be a permanent fix for Windows and JPackage. > > > > Am 07.02.22 um 15:57 schrieb Duncan Gittins: >> Excuse my bad explanation, line below should read: >> >> Because by default jextract puts multiple definitions per class, >> trying to access a required symbol loads all symbols generated into >> the same class. If one of those additional symbols is un-resolvable >> such as a Windows global variable, the alternative branch of >> RuntimeHelper.lookup() accesses ucrtbase.dll => hits the conflict >> with jpackage/JavaFX. >> >> I've tried undoing my changes for 1/2 below, removing either >> workaround causes "UnsatisfiedLinkError: Native Library >> C:\Windows\System32\ucrtbase.dll" regression in my application. >> >> Kind regards >> >> Duncan >> >> On 07/02/2022 14:24, Duncan Gittins wrote: >>> See my other email on this. I found that the issue in >>> RuntimeHelper.lookup() was caused by failed symbol lookups for >>> global variables that I did not depend on (and which cannot be found >>> in DLL, only static LIB - so won't ever resolve in Panama?) >>> >>> Because jextract puts multiple definitions per class trying >>> accessing a required caused failed lookups to try to access >>> ucrtbase.dll >>> >>> You may be able to bypass the issue by either: >>> 1) using jextract with "-Djextract.constants.per.class=0". This puts >>> every symbol into own class, so when any class is loaded it does not >>> trigger any unnecessary symbol lookups >>> 2) use jextract with exact types so jextract only generates the >>> exact set of symbols you need: >>> ??? --include-macro xyz >>> ??? --include-function xyz >>> >>> The above should help as long as you aren't depending on the actual >>> library load of ucrtbase.dll. >>> >>> Kind regards >>> >>> Duncan >>> >>> On 07/02/2022 12:19, Maurizio Cimadamore wrote: >>>> No problem. >>>> >>>> I've filed this: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8281335 >>>> >>>> Cheers >>>> Maurizio >>>> >>>> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >>>>> Hi Maurizio, >>>>> >>>>> thanks allot for your help and for the investigation. >>>>> >>>>> best regards, >>>>> Clemens >>>>> >>>>> >>>>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>>>>> wrote: >>>>>> >>>>>> ? >>>>>> >>>>>> Hi Clemens (it seems like your message got dropped by the mailing >>>>>> list, not sure why). >>>>>> >>>>>> Your message seems to point at some bad interaction between >>>>>> jpackage and Panama both trying to load ucrtbase.dll (and only >>>>>> one can win). Apparently, the Panama code isn't executed early >>>>>> enough in the jpackage case. >>>>>> >>>>>> We'll need to investigate more. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>>>>> Hello everybody, >>>>>>> >>>>>>> I am the developer of project librawfx >>>>>>> (github.com/lanthale/librawfx) and the app Photoslide >>>>>>> (github.com/lanthale/photoslide). >>>>>>> >>>>>>> At the begining of Photoslide the whole app was modularized and >>>>>>> therefore all was working including librawfx which is using >>>>>>> project Panama. After a while I had to change to a mixed >>>>>>> (modulepath for jdk+javafx libs and classpath for the rest) >>>>>>> environment and deployed my app PhotoSlide again. Under Linux >>>>>>> and OSX all is working as expected. The problem exists only >>>>>>> under Windows. Furthermore it exists only if I am creating a >>>>>>> Jlink/Jpackage distribution. Running the app from maven was >>>>>>> working as expected. Only the JPackage launcher have the issue >>>>>>> and I have no clue what the root cause is. >>>>>>> >>>>>>> The exception I am always seeing is: >>>>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>>>> SCHWERWIEGEND: null >>>>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>>>> classloader >>>>>>> (Full stacktrace below) >>>>>>> >>>>>>> How can you reproduce the issue: >>>>>>> >>>>>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>>>>>> ?2. Start the app with "mvn javafx:run at default-cli" >>>>>>> ?3. Click on the open icon in the toolbar and select file >>>>>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>>>>> >>>>>>> ?4. The app is showing the image below the textarea >>>>>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>>>>>> ??? install" >>>>>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>>>>> ?7. Open the same file again -> No image is shown below the text >>>>>>> ??? area and the exception is thrown in the background >>>>>>> >>>>>>> >>>>>>> I have tried many things but it is only happening if I have >>>>>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>>>>>> files on the classpath. All libs which are not having any Panama >>>>>>> code inside of the app are working perfectly and it is only >>>>>>> happening on Windows. >>>>>>> >>>>>>> Thank you in advance for your help! >>>>>>> >>>>>>> best regards, >>>>>>> Clemens >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Full stacktrace from Photoslide:* >>>>>>> >>>>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>>>>>> createSearchIndex >>>>>>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>>>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>>>>>> lambda$checkForSoftwareUpdates$2 >>>>>>> INFORMATION: No new version found! >>>>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>>>>>> lambda$createSearchIndex$0 >>>>>>> INFORMATION: End time create searchDB: >>>>>>> 2022-02-03T19:44:43.186194400 >>>>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>>>> SCHWERWIEGEND: null >>>>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>>>> classloader >>>>>>> at >>>>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>>>>>> Source) >>>>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>>>>> at >>>>>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>>>>> >>>>>>> at >>>>>>> org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>>>>> at >>>>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>>>>>> Source) >>>>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>>>>>> at >>>>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>>>>> >>>>>>> at >>>>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>>>>> >>>>>>> at >>>>>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>>>>>> Source) >>>>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>>>> at >>>>>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>>>>>> Source) >>>>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>>>> at >>>>>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>>>>> Source) >>>>>>> at >>>>>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>>>> Source) >>>>>>> at java.base/java.lang.Thread.run(Unknown Source) >>> >>> >> > From maurizio.cimadamore at oracle.com Mon Feb 7 22:15:39 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 7 Feb 2022 22:15:39 +0000 Subject: experiments in panama code generation In-Reply-To: <4215ee1d-29bf-afc6-9f9d-e06091dfd452@gmail.com> References: <4215ee1d-29bf-afc6-9f9d-e06091dfd452@gmail.com> Message-ID: On 06/02/2022 02:38, Michael Zucchi wrote: > Structures and unions are similar. ? Classes are typed holders of > MemorySegment and have normal java getters and setters, anything can > be renamed to be more java-like, fields can be excluded if they're > private or not useful, can be read/write and indexed acceess is > optional.? It's quit a pity you can't implement Addressable as it > would just be so much tidier than having to reimplement the same thing > for the same purpose but in an incompatible way. So, to go back to the topic of having a scope accessor, if I read this correctly, you could _still_ implement everything with your generator, but your structs will go from something like: ``` class FooStruct { ??? MemorySegment fooSegment; ??? private FooStruct(MemorySegment segment) { this.segment = segment; } ??? public FooStruct ofAddress(MemoryAddress address, ResourceScope scope) { // public API ??????? new FooStruct(MemorySegment.ofAddress(address, sccope)); ??? } ??? // getters/setters } ``` to: ``` class FooStruct { ??? MemorySegment fooSegment; ??? ResourceScope scope; ??? private FooStruct(MemorySegment segment, ResourceScope scope) { ???????? this.segment = segment; ???????? this.scope = scope; ???? } ??? public FooStruct ofAddress(MemoryAddress address, ResourceScope scope) { // public API ??????? new FooStruct(MemorySegment.ofAddress(address, scope), scope); ??? } ??? // getters/setters } ``` E.g. this is a doable transformation, but I guess you are not satisfied by the need to keep track both the segment and the scope (esp. given that you need the scope to build the segment). So, while it's doable (esp. if using code generator), your argument is that having to repeat things feels not very pleasing. Correct? In case it wasn't clear: I'm not trying to downplay any concerns here - but I'm trying to understand if removing the accessor will leave some of your code completely broken and without a possibility to get rectified as opposed to, (as I suspect) more verbose, but equally functional. Thanks Maurizio From maurizio.cimadamore at oracle.com Tue Feb 8 16:11:15 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 8 Feb 2022 16:11:15 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: References: Message-ID: Hi, I played with the benchmark some more, and I ended up converting it into a single JMH benchmark, extending it and adding other variants (e.g. byte buffer, memory address). The benchmark can be found here: http://cr.openjdk.java.net/~mcimadamore/panama/TrieBenchmark.java The numbers I get out of JMH are similar to those generated by your harness. The numbers I got are below (tested against latest Java 19): Benchmark Mode Cnt Score Error Units TrieBenchmark.address_seek avgt 30 2561.813 ? 24.697 ms/op TrieBenchmark.buffer_seek avgt 30 3402.664 ? 32.409 ms/op TrieBenchmark.native_seek avgt 30 3251.644 ? 48.709 ms/op TrieBenchmark.native_seek_alt avgt 30 2405.684 ? 14.005 ms/op TrieBenchmark.segment_seek avgt 30 3390.148 ? 15.195 ms/op TrieBenchmark.unsafe_seek avgt 30 2537.085 ? 20.125 ms/op (note that each "op" in JMH is a fulll round of 10M seek, so if you want to find the avg time per query in nanoseconds, you can just divide the above number by 10). So, both ByteBuffer and MemorySegment are the slowest. This is, as you posited, because of the bound checks. There's no way C2 can optimize those checks as the pattern of access is essentially unscrutable by C2 (e.g. we read an address from a segment and we use that dynamicaly read address to access another location). Unsafe and MemoryAddress, by dropping bound checks, receive a boost, and end up with similar numbers. The first native reader, which is basically a copy of the code you include is indeed slower than expected - it seems as slow as using buffers or segment. (Note that running the included C++ benchmark I get ~190ns/op). I verified there's no GC allocation (-prof gc) and also tried to profile (-prof perfasm), but I could only see (as you did) that most time was spent in the assembly. So, I thought, what if the native call is not the issue? What if the problem is in the surrounding Java code, the one that looks for a terminator char? So I looked at the C++ more closely and realized that the logic of the loop was written in a slightly different way; basically we have two loops there, an outer loop and an inner loop which only focuses on finding the terminator. This makes the logic a bit more linear. So, I've tried to copy that logic into `native_seek_alt` and I got a massive boost. Initially I thought it might have been an issue with the rewrital, but then I put together a test which ran both the old and the new versions and ensured that the native function was called (a) the same number of times and (b) with the same parameters (and, if not, throw an exception). And, lo and behold, no exceptions were thrown. This seems to get close to the results you were looking for. I don't have a really good explanation as to why changing the outer loop affects things so much. I imagine that the Java version of the "findSeparator" routine is more easily optimized by C2 (since it's a tight loop which accesses consecutive positions). I wonder if the presence of the native call in the middle of the loop in the base version adds some barriers which then make the sequential scan for the separator less optimal. If I replace the call in the "seek" function with your "noop" function, I go from 22ns/op to 10ns/op, which is ~2x boost. But, if I just do a loop where I call "noop" in a loop 10M times, I get down to ~7ns/op. Which seems to indicate that 7ns/op is (on my machine) the overhead for a native call (which is compatible with our other microbenchmarks), and, in the original version, 12ns were spent _outside_ the native call (which, in turns, explains why changing the loop shape affects things so much). I also played a bit with removing native thread transition (as the Java 19 allows to do so by tweaking some code). With that the overhead per call goes down to 1.5ns/op and the overall result for native_seek_alt is ~220ns/op. So, transitions make some difference here (expected, given that we do native calls back to back), but the overall impact of transitions on the throughput remains low. I hope this helps. Maurizio On 05/02/2022 17:01, Cleber Muramoto wrote: > Hello, I'm trying to understand the overhead of calling a downcall stub > generated by jextract. > > The source I'm using can be found on > https://github.com/cmuramoto/test-jextract > > Basically, I have the following piece of code > > MemorySegment data = loadFile(); // mmaps a text file with keywords, 1 per > line (\n = separator) > MemorySegment trie = loadTrie(); // mmaps a trie data structure that maps > string->int > > The trie is a contiguous array of pairs (int, int), which are fetched using > > int base(MemorySegment ms,long offset) { > return ms.get(JAVA_INT, offset<<3); > } > > int check(MemorySegment ms,long offset) { > return ms.get(JAVA_INT, 4L + ( offset<<3)); > } > > And the lookup method is as follows > > // finds the value associated with the key data.slice(pos, end - pos) > long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ > var from = 0L; > var to = 0L; > > while (pos < end) { > to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); > if(check(trie, to) != from) { > return ABSENT; // 1L<<33 > } > from = to; > pos++; > } > > to = base(trie, from); > var check = check(trie, to); > > if (check != i32(from)) { > return NO_VALUE; // 1L << 32 > } > return base(array, to); > } > > Running this code on a file with ~10 million lines with a fully populated > trie (so that every lookup succeeds), I measured a peak throughput of > 391ns/query. > > This lookup code suffers from bounds checking (which are unnecessary given > how the trie constrains its 'jumps' from a previous to a current offset, > but the JVM can't possibly know about this) and using Unsafe directly gives > a pretty decent boost, but still can't match a C++ counterpart. > > Based on the lookup code, I created an assembly version that receives the > segment's raw addresses and the length of the string, compiled it with > nasm, and created a shared library with ld: > > nasm -felf64 trie.asm -o trie.o > ld -z noexecstack -shared trie.o -o libtrie.so > > Then generated the stubs with jextract: > > jextract -t trie.asm --source -ltrie trie.h > > trie.h declares de lookup function and a noop ( xor rax, rax ret) which I > used as a baseline to measure a 3-arg call overhead, which in my > environment is about ~18ns/call. > > A compiled C++ code linked against libtrie.so manages to achieve > ~210ns/query. > > My naive expectation was that on the Java side I would get, roughly, C > throughput + 20ns ? 230ns/call, but so far I have the following: > > (best out of 10 loops) > jdk-17 branch > -native - 288 ns/query > -unsafe - 282 ns/query > > jdk-19 branch > -native - 372 ns/query > -memory-segments - 391 ns/query > -unsafe - 317 ns/query > > I did not use JMH, but the tests were executed with EpsilonGC and the hot > paths are allocation-free. > > So I wonder, on the JVM side, is there any difference in the intrinsic call > overhead when invoking a noop vs a real function (both with the same type > of arguments)? If not, how can I profile the culprit? I tried > async-profiler but the flame graph seems dominated by the assembly labels > of libtrie.so (especially the inc3) > > Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? > > Cheers! From cleber.muramoto at gmail.com Tue Feb 8 17:47:09 2022 From: cleber.muramoto at gmail.com (Cleber Muramoto) Date: Tue, 8 Feb 2022 14:47:09 -0300 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: References: Message-ID: Thank you Maurizio, nice catch on the loop shape logic! How did you remove the native thread transition? Does it require modifying and recompiling the JDK? I put together some JMH benchmarks as well using @BenchmarkMode(Mode.AverageTime) and created a jdk-17 branch. Results are very similar, probably I was messing something up in my previous comparison. # VM version: JDK 17-panama, OpenJDK 64-Bit Server VM, 17-panama+3-167 Benchmark Mode Cnt Score Error Units EstimateCallOverhead.run avgt 3 9.202 ? 0.145 ns/op Reader.run avgt 3 353.020 ? 20.584 ns/op ReaderNative.run avgt 3 281.826 ? 3.419 ns/op ReaderUnsafe.run avgt 3 298.737 ? 21.465 ns/op # VM version: JDK 19-panama, OpenJDK 64-Bit Server VM, 19-panama+1-13 Benchmark Mode Cnt Score Error Units EstimateCallOverhead.run avgt 3 9.778 ? 0.348 ns/op Reader.run avgt 3 356.468 ? 22.297 ns/op ReaderNative.run avgt 3 289.500 ? 8.928 ns/op ReaderUnsafe.run avgt 3 293.697 ? 3.299 ns/op Regards On Tue, Feb 8, 2022 at 1:11 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > I played with the benchmark some more, and I ended up converting it into a > single JMH benchmark, extending it and adding other variants (e.g. byte > buffer, memory address). > > The benchmark can be found here: > > http://cr.openjdk.java.net/~mcimadamore/panama/TrieBenchmark.java > > The numbers I get out of JMH are similar to those generated by your > harness. The numbers I got are below (tested against latest Java 19): > > Benchmark Mode Cnt Score Error Units > TrieBenchmark.address_seek avgt 30 2561.813 ? 24.697 ms/op > TrieBenchmark.buffer_seek avgt 30 3402.664 ? 32.409 ms/op > TrieBenchmark.native_seek avgt 30 3251.644 ? 48.709 ms/op > TrieBenchmark.native_seek_alt avgt 30 2405.684 ? 14.005 ms/op > TrieBenchmark.segment_seek avgt 30 3390.148 ? 15.195 ms/op > TrieBenchmark.unsafe_seek avgt 30 2537.085 ? 20.125 ms/op > > > (note that each "op" in JMH is a fulll round of 10M seek, so if you want > to find the avg time per query in nanoseconds, you can just divide the > above number by 10). > > So, both ByteBuffer and MemorySegment are the slowest. This is, as you > posited, because of the bound checks. There's no way C2 can optimize those > checks as the pattern of access is essentially unscrutable by C2 (e.g. we > read an address from a segment and we use that dynamicaly read address to > access another location). > > Unsafe and MemoryAddress, by dropping bound checks, receive a boost, and > end up with similar numbers. > > The first native reader, which is basically a copy of the code you include > is indeed slower than expected - it seems as slow as using buffers or > segment. (Note that running the included C++ benchmark I get ~190ns/op). > > I verified there's no GC allocation (-prof gc) and also tried to profile > (-prof perfasm), but I could only see (as you did) that most time was spent > in the assembly. So, I thought, what if the native call is not the issue? > What if the problem is in the surrounding Java code, the one that looks for > a terminator char? > So I looked at the C++ more closely and realized that the logic of the > loop was written in a slightly different way; basically we have two loops > there, an outer loop and an inner loop which only focuses on finding the > terminator. This makes the logic a bit more linear. So, I've tried to copy > that logic into `native_seek_alt` and I got a massive boost. > > Initially I thought it might have been an issue with the rewrital, but > then I put together a test which ran both the old and the new versions and > ensured that the native function was called (a) the same number of times > and (b) with the same parameters (and, if not, throw an exception). And, lo > and behold, no exceptions were thrown. > > This seems to get close to the results you were looking for. I don't have > a really good explanation as to why changing the outer loop affects things > so much. I imagine that the Java version of the "findSeparator" routine is > more easily optimized by C2 (since it's a tight loop which accesses > consecutive positions). I wonder if the presence of the native call in the > middle of the loop in the base version adds some barriers which then make > the sequential scan for the separator less optimal. If I replace the call > in the "seek" function with your "noop" function, I go from 22ns/op to > 10ns/op, which is ~2x boost. But, if I just do a loop where I call "noop" > in a loop 10M times, I get down to ~7ns/op. Which seems to indicate that > 7ns/op is (on my machine) the overhead for a native call (which is > compatible with our other microbenchmarks), and, in the original version, > 12ns were spent _outside_ the native call (which, in turns, explains why > changing the loop shape affects things so much). > > I also played a bit with removing native thread transition (as the Java 19 > allows to do so by tweaking some code). With that the overhead per call > goes down to 1.5ns/op and the overall result for native_seek_alt is > ~220ns/op. So, transitions make some difference here (expected, given that > we do native calls back to back), but the overall impact of transitions on > the throughput remains low. > > I hope this helps. > > Maurizio > > > On 05/02/2022 17:01, Cleber Muramoto wrote: > > Hello, I'm trying to understand the overhead of calling a downcall stub > generated by jextract. > > The source I'm using can be found onhttps://github.com/cmuramoto/test-jextract > > Basically, I have the following piece of code > > MemorySegment data = loadFile(); // mmaps a text file with keywords, 1 per > line (\n = separator) > MemorySegment trie = loadTrie(); // mmaps a trie data structure that maps > string->int > > The trie is a contiguous array of pairs (int, int), which are fetched using > > int base(MemorySegment ms,long offset) { > return ms.get(JAVA_INT, offset<<3); > } > > int check(MemorySegment ms,long offset) { > return ms.get(JAVA_INT, 4L + ( offset<<3)); > } > > And the lookup method is as follows > > // finds the value associated with the key data.slice(pos, end - pos) > long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ > var from = 0L; > var to = 0L; > > while (pos < end) { > to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); > if(check(trie, to) != from) { > return ABSENT; // 1L<<33 > } > from = to; > pos++; > } > > to = base(trie, from); > var check = check(trie, to); > > if (check != i32(from)) { > return NO_VALUE; // 1L << 32 > } > return base(array, to); > } > > Running this code on a file with ~10 million lines with a fully populated > trie (so that every lookup succeeds), I measured a peak throughput of > 391ns/query. > > This lookup code suffers from bounds checking (which are unnecessary given > how the trie constrains its 'jumps' from a previous to a current offset, > but the JVM can't possibly know about this) and using Unsafe directly gives > a pretty decent boost, but still can't match a C++ counterpart. > > Based on the lookup code, I created an assembly version that receives the > segment's raw addresses and the length of the string, compiled it with > nasm, and created a shared library with ld: > > nasm -felf64 trie.asm -o trie.o > ld -z noexecstack -shared trie.o -o libtrie.so > > Then generated the stubs with jextract: > > jextract -t trie.asm --source -ltrie trie.h > > trie.h declares de lookup function and a noop ( xor rax, rax ret) which I > used as a baseline to measure a 3-arg call overhead, which in my > environment is about ~18ns/call. > > A compiled C++ code linked against libtrie.so manages to achieve > ~210ns/query. > > My naive expectation was that on the Java side I would get, roughly, C > throughput + 20ns ? 230ns/call, but so far I have the following: > > (best out of 10 loops) > jdk-17 branch > -native - 288 ns/query > -unsafe - 282 ns/query > > jdk-19 branch > -native - 372 ns/query > -memory-segments - 391 ns/query > -unsafe - 317 ns/query > > I did not use JMH, but the tests were executed with EpsilonGC and the hot > paths are allocation-free. > > So I wonder, on the JVM side, is there any difference in the intrinsic call > overhead when invoking a noop vs a real function (both with the same type > of arguments)? If not, how can I profile the culprit? I tried > async-profiler but the flame graph seems dominated by the assembly labels > of libtrie.so (especially the inc3) > > Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? > > Cheers! > > From maurizio.cimadamore at oracle.com Tue Feb 8 18:22:16 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 8 Feb 2022 18:22:16 +0000 Subject: [foreign] Mesuring downcall stub performance In-Reply-To: References: Message-ID: <9ad87608-3284-fdae-a5d6-0c05775ee470@oracle.com> Hi, this is the crude patch I used to disable state transition. diff --git a/src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java b/src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java index 12e832a582d..2b027d5186e 100644 --- a/src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java +++ b/src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java @@ -52,7 +52,7 @@ public class NativeEntryPoint { ???????? this.shadowSpace = shadowSpace; ???????? this.argMoves = Objects.requireNonNull(argMoves); ???????? this.returnMoves = Objects.requireNonNull(returnMoves); -??????? this.needTransition = needTransition; +??????? this.needTransition = false; ???????? this.methodType = methodType; ???????? this.name = name; ???? } The C linker machinery is able to omit state transitions - but we don't currently expose a way for developers to select that behavior (we might in the future). In general, unless you are doing pretty specific stuff, the cost of the transition (~5ns) is negligible compared to everything else going on in the application. But of course if you want to compare Java code with C++, that cost has to be taken into the equation as well (which is why I tried, just for fun, to see how close we could get). Maurizio On 08/02/2022 17:47, Cleber Muramoto wrote: > Thank you Maurizio, nice catch on the loop shape logic! > > How did you remove the native thread transition? Does it require > modifying and recompiling the JDK? > > I put together some JMH benchmarks as well using > @BenchmarkMode(Mode.AverageTime) and created a jdk-17 branch. Results > are very similar,?probably I was messing something?up in my previous > comparison. > > # VM version: JDK 17-panama, OpenJDK 64-Bit Server VM, 17-panama+3-167 > Benchmark ? ? ? ? Mode ?Cnt ? ?Score ? ?Error ?Units > EstimateCallOverhead.run ?avgt ? ?3 ? ?9.202 ? ?0.145 ?ns/op > Reader.run ? ? ? ?avgt ? ?3 ?353.020 ? 20.584 ?ns/op > ReaderNative.run ?avgt ? ?3 ?281.826 ? ?3.419 ?ns/op > ReaderUnsafe.run ?avgt ? ?3 ?298.737 ? 21.465 ?ns/op > > # VM version: JDK 19-panama, OpenJDK 64-Bit Server VM, 19-panama+1-13 > Benchmark ? ? ? ? Mode ?Cnt ? ?Score ? ?Error ?Units > EstimateCallOverhead.run ?avgt ? ?3 ? ?9.778 ? ?0.348 ?ns/op > Reader.run ? ? ? ? ? ? ? ?avgt ? ?3 ?356.468 ? 22.297 ?ns/op > ReaderNative.run ? ? ? ? ?avgt ? ?3 ?289.500 ? ?8.928 ?ns/op > ReaderUnsafe.run ? ? ? ? ?avgt ? ?3 ?293.697 ? ?3.299 ?ns/op > > > Regards > > On Tue, Feb 8, 2022 at 1:11 PM Maurizio Cimadamore > wrote: > > Hi, > I played with the benchmark some more, and I ended up converting > it into a single JMH benchmark, extending it and adding other > variants (e.g. byte buffer, memory address). > > The benchmark can be found here: > > http://cr.openjdk.java.net/~mcimadamore/panama/TrieBenchmark.java > > The numbers I get out of JMH are similar to those generated by > your harness. The numbers I got are below (tested against latest > Java 19): > > Benchmark Mode Cnt Score Error Units > TrieBenchmark.address_seek avgt 30 2561.813 ? 24.697 ms/op > TrieBenchmark.buffer_seek avgt 30 3402.664 ? 32.409 ms/op > TrieBenchmark.native_seek avgt 30 3251.644 ? 48.709 ms/op > TrieBenchmark.native_seek_alt avgt 30 2405.684 ? 14.005 ms/op > TrieBenchmark.segment_seek avgt 30 3390.148 ? 15.195 ms/op > TrieBenchmark.unsafe_seek avgt 30 2537.085 ? 20.125 ms/op > > > (note that each "op" in JMH is a fulll round of 10M seek, so if > you want to find the avg time per query in nanoseconds, you can > just divide the above number by 10). > > So, both ByteBuffer and MemorySegment are the slowest. This is, as > you posited, because of the bound checks. There's no way C2 can > optimize those checks as the pattern of access is essentially > unscrutable by C2 (e.g. we read an address from a segment and we > use that dynamicaly read address to access another location). > > Unsafe and MemoryAddress, by dropping bound checks, receive a > boost, and end up with similar numbers. > > The first native reader, which is basically a copy of the code you > include is indeed slower than expected - it seems as slow as using > buffers or segment. (Note that running the included C++ benchmark > I get ~190ns/op). > > I verified there's no GC allocation (-prof gc) and also tried to > profile (-prof perfasm), but I could only see (as you did) that > most time was spent in the assembly. So, I thought, what if the > native call is not the issue? What if the problem is in the > surrounding Java code, the one that looks for a terminator char? > So I looked at the C++ more closely and realized that the logic of > the loop was written in a slightly different way; basically we > have two loops there, an outer loop and an inner loop which only > focuses on finding the terminator. This makes the logic a bit more > linear. So, I've tried to copy that logic into `native_seek_alt` > and I got a massive boost. > > Initially I thought it might have been an issue with the rewrital, > but then I put together a test which ran both the old and the new > versions and ensured that the native function was called (a) the > same number of times and (b) with the same parameters (and, if > not, throw an exception). And, lo and behold, no exceptions were > thrown. > > This seems to get close to the results you were looking for. I > don't have a really good explanation as to why changing the outer > loop affects things so much. I imagine that the Java version of > the "findSeparator" routine is more easily optimized by C2 (since > it's a tight loop which accesses consecutive positions). I wonder > if the presence of the native call in the middle of the loop in > the base version adds some barriers which then make the sequential > scan for the separator less optimal. If I replace the call in the > "seek" function with your "noop" function, I go from 22ns/op to > 10ns/op, which is ~2x boost. But, if I just do a loop where I call > "noop" in a loop 10M times, I get down to ~7ns/op. Which seems to > indicate that 7ns/op is (on my machine) the overhead for a native > call (which is compatible with our other microbenchmarks), and, in > the original version, 12ns were spent _outside_ the native call > (which, in turns, explains why changing the loop shape affects > things so much). > > I also played a bit with removing native thread transition (as the > Java 19 allows to do so by tweaking some code). With that the > overhead per call goes down to 1.5ns/op and the overall result for > native_seek_alt is ~220ns/op. So, transitions make some difference > here (expected, given that we do native calls back to back), but > the overall impact of transitions on the throughput remains low. > > I hope this helps. > > Maurizio > > > On 05/02/2022 17:01, Cleber Muramoto wrote: >> Hello, I'm trying to understand the overhead of calling a downcall stub >> generated by jextract. >> >> The source I'm using can be found on >> https://github.com/cmuramoto/test-jextract >> >> Basically, I have the following piece of code >> >> MemorySegment data = loadFile(); // mmaps a text file with keywords, 1 per >> line (\n = separator) >> MemorySegment trie = loadTrie(); // mmaps a trie data structure that maps >> string->int >> >> The trie is a contiguous array of pairs (int, int), which are fetched using >> >> int base(MemorySegment ms,long offset) { >> return ms.get(JAVA_INT, offset<<3); >> } >> >> int check(MemorySegment ms,long offset) { >> return ms.get(JAVA_INT, 4L + ( offset<<3)); >> } >> >> And the lookup method is as follows >> >> // finds the value associated with the key data.slice(pos, end - pos) >> long lookup(MemorySegment trie, MemorySegment data, int pos, int end){ >> var from = 0L; >> var to = 0L; >> >> while (pos < end) { >> to = ((long)(base(trie, from))) ^ (data.get(JAVA_BYTE,pos) & 0xFF); >> if(check(trie, to) != from) { >> return ABSENT; // 1L<<33 >> } >> from = to; >> pos++; >> } >> >> to = base(trie, from); >> var check = check(trie, to); >> >> if (check != i32(from)) { >> return NO_VALUE; // 1L << 32 >> } >> return base(array, to); >> } >> >> Running this code on a file with ~10 million lines with a fully populated >> trie (so that every lookup succeeds), I measured a peak throughput of >> 391ns/query. >> >> This lookup code suffers from bounds checking (which are unnecessary given >> how the trie constrains its 'jumps' from a previous to a current offset, >> but the JVM can't possibly know about this) and using Unsafe directly gives >> a pretty decent boost, but still can't match a C++ counterpart. >> >> Based on the lookup code, I created an assembly version that receives the >> segment's raw addresses and the length of the string, compiled it with >> nasm, and created a shared library with ld: >> >> nasm -felf64 trie.asm -o trie.o >> ld -z noexecstack -shared trie.o -o libtrie.so >> >> Then generated the stubs with jextract: >> >> jextract -t trie.asm --source -ltrie trie.h >> >> trie.h declares de lookup function and a noop ( xor rax, rax ret) which I >> used as a baseline to measure a 3-arg call overhead, which in my >> environment is about ~18ns/call. >> >> A compiled C++ code linked against libtrie.so manages to achieve >> ~210ns/query. >> >> My naive expectation was that on the Java side I would get, roughly, C >> throughput + 20ns ? 230ns/call, but so far I have the following: >> >> (best out of 10 loops) >> jdk-17 branch >> -native - 288 ns/query >> -unsafe - 282 ns/query >> >> jdk-19 branch >> -native - 372 ns/query >> -memory-segments - 391 ns/query >> -unsafe - 317 ns/query >> >> I did not use JMH, but the tests were executed with EpsilonGC and the hot >> paths are allocation-free. >> >> So I wonder, on the JVM side, is there any difference in the intrinsic call >> overhead when invoking a noop vs a real function (both with the same type >> of arguments)? If not, how can I profile the culprit? I tried >> async-profiler but the flame graph seems dominated by the assembly labels >> of libtrie.so (especially the inc3) >> >> Is the ~30% degradation of jdk-19 when compared to jdk-17 expected? >> >> Cheers! > From notzed at gmail.com Wed Feb 9 02:19:24 2022 From: notzed at gmail.com (Michael Zucchi) Date: Wed, 9 Feb 2022 12:49:24 +1030 Subject: resource scopes and close actions In-Reply-To: <311b838b-e44a-4d91-6f7f-3a50b0eb8e76@oracle.com> References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> <311b838b-e44a-4d91-6f7f-3a50b0eb8e76@oracle.com> Message-ID: Ok cheers that should probably do.? I only just noticed you can use it as an addressable a couple of days ago but using it for non-symbol things isn't obvious especially given it's name and it's documentation. So it seems a 'typed' handle-like object that wanted to use a scope on close action will have to: - use NativeSymbol as the native 'this', which contains a copy of the MemoryAddress, a string and the scope handle. - keep a private copy of the MemoryAddress so any close function can use it after the scope is closed (whether it be in the object or in a lambda, it may as well be in the object) - (based on the proposed api change) also keep a copy of the ResourceScope if it wants to be able to propagate it automatically which would often be desirable (... i think). Doesn't seem too elegant but that should work?? I'll explore that with opencl as i've the most experience with that api and it has some consistent conventions that i think will mesh well. e.g. as a first thought, does this look about right? An example case is CLCommandQueue which is an object which is created by and belongs to a CLContext and can be closed either by an explicit unref or when the context is unreffed. public CLCommandQueue { ??? NativeSymbol symbol; ??? ResourceScope scope; ??? MemoryAddress addr; ?? // package private ??? close() { ???????? clReleaseCommandQueue$MH.invokeExact((Addressable)addr); ??? } } public CLContext { ??? NativeSymbol symbol; ??? ResourceScope scope; ??? MemoryAddress addr; ?? public static CLContext create(..., ResourceScope scope) { ... } ?? public CLCommandQueue createCommandQueue(, ...scope) { ?????? MemoryAddress addr = clContextCreateCommandQueue(...); ?????? CLCommandQueue q = CLCommandQueue.create(addr, scope); ?????? if (scope != this.scope) ?? ? ????? this.scope.addCloseAction(() -> scope.close()); ?????? scope.addOnCloseAction(()-> q.close()); ?????? return q; ?? } } I have to think about it a bit more though, there are some cases where this might not be a good fit.? Or you end up having create a scope for single objects and now have to keep track of two references (or add some public close() which calls scope.close()).? Also, dynamic method handles add a wrinkle if they are a release() function. My JNI code uses reference queues so both explicit and gc-release are possible, this is particularly handy for lambda-based processing chains where there's no 'object' to hold references around and ownership is basically passed by argument in a graph of unpredictable ways.? A common shared scope with a cleaner should work i think but that would require a different design. ?!Z On 7/2/22 21:19, Maurizio Cimadamore wrote: > If you want a "scoped" memory address, please look at NativeSymbol. > This is used by the lookup functions provided by the JDK, but is also > useful to capture an address and associate a scope with it. This > allows you to model everything with one field (NativeSymbol) and then > no liveness check is needed, just pass the symbol to the method > handle, and standard safety checks will apply. > > Maurizio > > On 05/02/2022 09:16, Michael Zucchi wrote: >> OpenCL (& Vulkan) does everything via handles (typed anonymous >> pointers), so presumably represented by MemoryAddress.? What approach >> to use here to make them scope-safe?? Have explicit scope tests >> before using them in calls? >> >> If one wanted a scope-protected MemoryAddress this seems to be the >> only solution in the present api: >> >> CLCommandQueue { >> ? ResourceScope scope; >> ? MemoryAddress handle; >> >> ? void enqueueNDRangeKernel(...) { >> ??? try (ResourceScope scope = ResourceScope.newConfinedScope()) { >> ?????? scope.keepAlive(this.scope); >> enqueueNDRangeKernel$MH.invokeExact((Addressable)handle, ...); >> ??? } catch (IllegalStateException ex) { >> ??? } >> ? } >> } >> >> Actually it's a bit worse because there will be handles (possibly in >> different scopes) in the argument list and they would all need to be >> checked in the same way. >> >> So for practicality they would have to be MemorySegment (ideally >> length=0) since they are always checked? From maurizio.cimadamore at oracle.com Wed Feb 9 02:42:15 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 Feb 2022 02:42:15 +0000 Subject: resource scopes and close actions In-Reply-To: References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> <311b838b-e44a-4d91-6f7f-3a50b0eb8e76@oracle.com> Message-ID: <0fcadce9-f1c2-d392-7aa6-40150b8441b4@oracle.com> On 09/02/2022 02:19, Michael Zucchi wrote: > > Ok cheers that should probably do.? I only just noticed you can use it > as an addressable a couple of days ago but using it for non-symbol > things isn't obvious especially given it's name and it's documentation. > > So it seems a 'typed' handle-like object that wanted to use a scope on > close action will have to: > > - use NativeSymbol as the native 'this', which contains a copy of the > MemoryAddress, a string and the scope handle. > - keep a private copy of the MemoryAddress so any close function can > use it after the scope is closed (whether it be in the object or in a > lambda, it may as well be in the object) yes > - (based on the proposed api change) also keep a copy of the > ResourceScope if it wants to be able to propagate it automatically > which would often be desirable (... i think). stay tuned on this. We're looking into ways to mitigate the impact of the proposed changes which will not require you to keep a ResourceScope around (and use a segment instead as a "proxy" of the temporal bounds you want to use e.g. to create another segment). > > Doesn't seem too elegant but that should work?? I'll explore that with > opencl as i've the most experience with that api and it has some > consistent conventions that i think will mesh well. > > e.g. as a first thought, does this look about right? > > An example case is CLCommandQueue which is an object which is created > by and belongs to a CLContext and can be closed either by an explicit > unref or when the context is unreffed. > > public CLCommandQueue { > ??? NativeSymbol symbol; > ??? ResourceScope scope; > ??? MemoryAddress addr; > > ?? // package private > ??? close() { > ???????? clReleaseCommandQueue$MH.invokeExact((Addressable)addr); > ??? } > } This looks mostly ok - not sure whether you need to keep the `addr` around. I would have expected `addr` to only really be used in a close action, so when you create CLCommandQueue (e.g. CLCommandQueue::create). Am I missing something? > > public CLContext { > ??? NativeSymbol symbol; > ??? ResourceScope scope; > ??? MemoryAddress addr; > > ?? public static CLContext create(..., ResourceScope scope) { ... } > > ?? public CLCommandQueue createCommandQueue(, ...scope) { > ?????? MemoryAddress addr = clContextCreateCommandQueue(...); > ?????? CLCommandQueue q = CLCommandQueue.create(addr, scope); > > ?????? if (scope != this.scope) > ?? ? ????? this.scope.addCloseAction(() -> scope.close()); > ?????? scope.addOnCloseAction(()-> q.close()); > > ?????? return q; > ?? } > } > > I have to think about it a bit more though, there are some cases where > this might not be a good fit.? Or you end up having create a scope for > single objects and now have to keep track of two references (or add > some public close() which calls scope.close()).? Also, dynamic method > handles add a wrinkle if they are a release() function. Creating a scope for single objects doesn't seem optimal - scopes are mostly intended to aggregate resources together (which share a common lifecycle). Overall though, there's no real right or wrong - the API gives you option when it comes to dealing with lifetime of entities - it is mostly a choice of the API designer whether to take advantage of that, or ignore that (in order to expose a simpler API). I also expect that some libraries might be more scope-friendly than others. Given that C is so varied when it comes to management of resource lifecycle, that should also not come too much as a surprise. > > My JNI code uses reference queues so both explicit and gc-release are > possible, this is particularly handy for lambda-based processing > chains where there's no 'object' to hold references around and > ownership is basically passed by argument in a graph of unpredictable > ways.? A common shared scope with a cleaner should work i think but > that would require a different design. In general, starting off with single scope, GC-managed, sounds like a good default choice - and then sprinkle scopes as you see needs to deallocate more promptly and/or add more fine-grained lifecycle management to your library (assuming that is required). Btw, note that a GC-backed scope can still be released explicitly, if you so wish (so you have both options at once). Cheers Maurizio > > ?!Z > > On 7/2/22 21:19, Maurizio Cimadamore wrote: >> If you want a "scoped" memory address, please look at NativeSymbol. >> This is used by the lookup functions provided by the JDK, but is also >> useful to capture an address and associate a scope with it. This >> allows you to model everything with one field (NativeSymbol) and then >> no liveness check is needed, just pass the symbol to the method >> handle, and standard safety checks will apply. >> >> Maurizio >> >> On 05/02/2022 09:16, Michael Zucchi wrote: >>> OpenCL (& Vulkan) does everything via handles (typed anonymous >>> pointers), so presumably represented by MemoryAddress.? What >>> approach to use here to make them scope-safe?? Have explicit scope >>> tests before using them in calls? >>> >>> If one wanted a scope-protected MemoryAddress this seems to be the >>> only solution in the present api: >>> >>> CLCommandQueue { >>> ? ResourceScope scope; >>> ? MemoryAddress handle; >>> >>> ? void enqueueNDRangeKernel(...) { >>> ??? try (ResourceScope scope = ResourceScope.newConfinedScope()) { >>> ?????? scope.keepAlive(this.scope); >>> enqueueNDRangeKernel$MH.invokeExact((Addressable)handle, ...); >>> ??? } catch (IllegalStateException ex) { >>> ??? } >>> ? } >>> } >>> >>> Actually it's a bit worse because there will be handles (possibly in >>> different scopes) in the argument list and they would all need to be >>> checked in the same way. >>> >>> So for practicality they would have to be MemorySegment (ideally >>> length=0) since they are always checked? > From maurizio.cimadamore at oracle.com Wed Feb 9 03:08:12 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 Feb 2022 03:08:12 +0000 Subject: resource scopes and close actions In-Reply-To: References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> <311b838b-e44a-4d91-6f7f-3a50b0eb8e76@oracle.com> Message-ID: On 09/02/2022 02:19, Michael Zucchi wrote: > public CLContext { > ??? NativeSymbol symbol; > ??? ResourceScope scope; > ??? MemoryAddress addr; > > ?? public static CLContext create(..., ResourceScope scope) { ... } > > ?? public CLCommandQueue createCommandQueue(, ...scope) { > ?????? MemoryAddress addr = clContextCreateCommandQueue(...); > ?????? CLCommandQueue q = CLCommandQueue.create(addr, scope); > > ?????? if (scope != this.scope) > ?? ? ????? this.scope.addCloseAction(() -> scope.close()); > ?????? scope.addOnCloseAction(()-> q.close()); > > ?????? return q; > ?? } > } Quick comment - if I were you I would avoid calling scope::close from another close action. In general you don't know if the scope you want to close is confined or not. If it is confined, and you call close on a different thread (which is possible if the main scope is managed by a cleaner) you have a problem. In this case I'd keep things simple, just by verifying that the scope provided in createCommandQueue is the same as the expected one (or even omit the scope parameter from createCommandQueue). In other words, I see value in having a scope for a CLContext, so that you can bring everything down when no longer needed. I see less value (and a lot more complexity) in having to support a mix and match of different lifecycles. If you need to have a long-lived object (CLContext) and have it coexist with many shorter-lived ones (like a CLCommandQueue), I think one strategy that works, and is relatively simple, is to use an implicit scope for CLContext, and leave that to the GC. Then you can use explicitly closed scopes for the short-lived entities (and maybe you can store a CLContext reference - or? its implicit scope - inside the dependent entities, to make sure the CLContext won't go away prematurely). This way you probably get best of both worlds: ``` CLContext clContext = CLContext.create(); // implicit scope here try (var scope = ResourceScope.newConfinedScope) { ??? CLCommandQueue queue = clContext.createCommandQueue(scope); ??? ... } // queue cleaned up here ``` Of course this is my 0.02$. Maurizio From notzed at gmail.com Wed Feb 9 04:23:38 2022 From: notzed at gmail.com (Michael Zucchi) Date: Wed, 9 Feb 2022 14:53:38 +1030 Subject: resource scopes and close actions In-Reply-To: <0fcadce9-f1c2-d392-7aa6-40150b8441b4@oracle.com> References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> <311b838b-e44a-4d91-6f7f-3a50b0eb8e76@oracle.com> <0fcadce9-f1c2-d392-7aa6-40150b8441b4@oracle.com> Message-ID: <30435743-a061-bc2d-9298-141a0ec4ff47@gmail.com> On 9/2/22 13:12, Maurizio Cimadamore wrote: > > On 09/02/2022 02:19, Michael Zucchi wrote: >> >> Ok cheers that should probably do.? I only just noticed you can use >> it as an addressable a couple of days ago but using it for non-symbol >> things isn't obvious especially given it's name and it's documentation. >> >> So it seems a 'typed' handle-like object that wanted to use a scope >> on close action will have to: >> >> - use NativeSymbol as the native 'this', which contains a copy of the >> MemoryAddress, a string and the scope handle. >> - keep a private copy of the MemoryAddress so any close function can >> use it after the scope is closed (whether it be in the object or in a >> lambda, it may as well be in the object) > yes >> - (based on the proposed api change) also keep a copy of the >> ResourceScope if it wants to be able to propagate it automatically >> which would often be desirable (... i think). > stay tuned on this. We're looking into ways to mitigate the impact of > the proposed changes which will not require you to keep a > ResourceScope around (and use a segment instead as a "proxy" of the > temporal bounds you want to use e.g. to create another segment). What if you have a NativeSymbol instead? >> >> Doesn't seem too elegant but that should work?? I'll explore that >> with opencl as i've the most experience with that api and it has some >> consistent conventions that i think will mesh well. >> >> e.g. as a first thought, does this look about right? >> >> An example case is CLCommandQueue which is an object which is created >> by and belongs to a CLContext and can be closed either by an explicit >> unref or when the context is unreffed. >> >> public CLCommandQueue { >> ??? NativeSymbol symbol; >> ??? ResourceScope scope; >> ??? MemoryAddress addr; >> >> ?? // package private >> ??? close() { >> clReleaseCommandQueue$MH.invokeExact((Addressable)addr); >> ??? } >> } > This looks mostly ok - not sure whether you need to keep the `addr` > around. I would have expected `addr` to only really be used in a close > action, so when you create CLCommandQueue (e.g. > CLCommandQueue::create). Am I missing something? Only because it needs to be stored somewhere, either in the lambda or the object.? I was thinking of having the ability to implement an idempotent close at the time so you can't just have it in the lambda, but I don't think that will be possible with scopes - unless you have scope-per-object which as you mentioned isn't optimal. Otherwise you're basically just back to a stale object on an open scope and would need more checks every time you use it.? I was also thinking broader such as the ffmpeg AVFormatContext example earlier where some other object state defines which close to use. An implementation that used a cleaner would have to do something else anyway. > >> >> My JNI code uses reference queues so both explicit and gc-release are >> possible, this is particularly handy for lambda-based processing >> chains where there's no 'object' to hold references around and >> ownership is basically passed by argument in a graph of unpredictable >> ways.? A common shared scope with a cleaner should work i think but >> that would require a different design. > > In general, starting off with single scope, GC-managed, sounds like a > good default choice - and then sprinkle scopes as you see needs to > deallocate more promptly and/or add more fine-grained lifecycle > management to your library (assuming that is required). Btw, note that > a GC-backed scope can still be released explicitly, if you so wish (so > you have both options at once). > The case i'm trying to solve is where you don't really know the lifecycle of the object.? With opencl you use reference counting to hold objects as long as you need them so they can change ownership and/or be shared amongst different functions and libraries in ways the caller can't control.? My JNI wrapping hid all that by just using java reference gc to effectively do the same thing as far as java was concerned. I've also made an embarrassing mistake, closing the context doesn't release it's objects, in opencl they all have a reference count on the context so the other discussion is a little moot.? I believe it does in vulkan although it's an error to close the instance before all of it's objects are closed. Oh well i'll have to about it more.? Implicit scopes wont be enough in the case of such an api unless each object also retains a java reference to it's parent - leaving it up to the application isn't really safe enough is it? Just FYI command queues are not short lived, a simple app might be: create a context create a small number of queues create your kernels then set up a processing pipeline - could be multiple, could come and go: create some memory buffers and images maybe create some specific kernels then execute a processing pipeline - this will happen multiple times, and an individual execution could span multiple threads: execute kernels, track execution using events - some will have the lifetime of the pipeline, others a fragment of it, perhaps allocate/free temp image/memory along the way close everything in reverse Given the realisation of my mistake on how the refcounting works in opencl i think this should be covered by a few relatively simple scope mechanisms under application control. ?!Z From maurizio.cimadamore at oracle.com Wed Feb 9 11:30:36 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 Feb 2022 11:30:36 +0000 Subject: resource scopes and close actions In-Reply-To: <30435743-a061-bc2d-9298-141a0ec4ff47@gmail.com> References: <906c7774-ebf6-acfa-5c74-9364d769d0cd@gmail.com> <4816c63e-a449-9708-c300-34fb9176aa9d@oracle.com> <7c84cacb-9e05-4af9-025a-63f1a7ade724@oracle.com> <6733701e-9456-b512-0a24-3bc1019ca7d7@gmail.com> <311b838b-e44a-4d91-6f7f-3a50b0eb8e76@oracle.com> <0fcadce9-f1c2-d392-7aa6-40150b8441b4@oracle.com> <30435743-a061-bc2d-9298-141a0ec4ff47@gmail.com> Message-ID: <571a1dad-8be6-ddfb-84ce-dabbc7048d62@oracle.com> >>> - (based on the proposed api change) also keep a copy of the >>> ResourceScope if it wants to be able to propagate it automatically >>> which would often be desirable (... i think). >> stay tuned on this. We're looking into ways to mitigate the impact of >> the proposed changes which will not require you to keep a >> ResourceScope around (and use a segment instead as a "proxy" of the >> temporal bounds you want to use e.g. to create another segment). > > What if you have a NativeSymbol instead? The mechanism we had in mind would work with all "scoped" resources - segments, valist, native symbols. > >>> >>> Doesn't seem too elegant but that should work?? I'll explore that >>> with opencl as i've the most experience with that api and it has >>> some consistent conventions that i think will mesh well. >>> >>> e.g. as a first thought, does this look about right? >>> >>> An example case is CLCommandQueue which is an object which is >>> created by and belongs to a CLContext and can be closed either by an >>> explicit unref or when the context is unreffed. >>> >>> public CLCommandQueue { >>> ??? NativeSymbol symbol; >>> ??? ResourceScope scope; >>> ??? MemoryAddress addr; >>> >>> ?? // package private >>> ??? close() { >>> clReleaseCommandQueue$MH.invokeExact((Addressable)addr); >>> ??? } >>> } >> This looks mostly ok - not sure whether you need to keep the `addr` >> around. I would have expected `addr` to only really be used in a >> close action, so when you create CLCommandQueue (e.g. >> CLCommandQueue::create). Am I missing something? > > Only because it needs to be stored somewhere, either in the lambda or > the object.? I was thinking of having the ability to implement an > idempotent close at the time so you can't just have it in the lambda, > but I don't think that will be possible with scopes - unless you have > scope-per-object which as you mentioned isn't optimal. Otherwise > you're basically just back to a stale object on an open scope and > would need more checks every time you use it.? I was also thinking > broader such as the ffmpeg AVFormatContext example earlier where some > other object state defines which close to use. Btw, it's not that having a scope per object isn't optimal - you basically get what you used to get with previous iterations of the API: each segment has its own private lifetime instance. If the objects you create are relatively long-lived, that might work. If not, you might see extra overhead for creating a scope for each new struct. Again, it really depends on the library you are dealing with. But yes, if you are using scopes to manage _groups_ of resources, having a close() on a single resource doesn't make a lot of sense (as then one resource can bring down everything else with it). > >> >> In general, starting off with single scope, GC-managed, sounds like a >> good default choice - and then sprinkle scopes as you see needs to >> deallocate more promptly and/or add more fine-grained lifecycle >> management to your library (assuming that is required). Btw, note >> that a GC-backed scope can still be released explicitly, if you so >> wish (so you have both options at once). >> > > The case i'm trying to solve is where you don't really know the > lifecycle of the object.? With opencl you use reference counting to > hold objects as long as you need them so they can change ownership > and/or be shared amongst different functions and libraries in ways the > caller can't control.? My JNI wrapping hid all that by just using java > reference gc to effectively do the same thing as far as java was > concerned. Yep, I recall that from our previous discussions. In reality there's no reason why you couldn't do the same thing here, right? E.g. you could set up a map between memory address and some resource XYZ (to dedup, as you did in ZCL), and then create a separate implicit scope for each resource XYZ created in the system (with a corresponding cleanup action for when it becomes unreachable). And, if you have a separate scope per (deduped) Object, you can also support explicit closure as well (although that might not make sense for OpenCL in general). If that system works well for you, and for the library you are working it, maybe that's ok? We have explored ideas for managing complex network of temporal dependencies using scopes: https://inside.java/2021/10/12/panama-scope-dependencies/ This is based on the idea that if we had a way to set up explicit temporal dependencies between scope A and scope B (such that B cannot be closed until A is), you can now reason about these dependencies in a meaningful way. Consider the case of a function which takes two segments and return a new one: MemorySegment makeFrom(MemorySegment a, MemorySegment b, ResourceScope target) With the API we have today, the only sensible option for this API is to force that? scope(a) ==(b) == target (with a corner case where target == global scope). If we had dependencies, we could be more flexible: * we could check that scope(a) <= target and that scope(b) <= target (where <= means "child of", meaning that e.g. target cannot be closed while scope(a)? is alive) * we could not even accept a scope, look at infer a scope = min(scope(a), scope(b)) - that is, the smaller lifecycle between a and b (reasoning being that if either a/b are destroyed, the same should happen for the returned segment) I believe these ideas are promising and powerful, but I also believe that they need more bake time, and more evaluation. But I would certainly would like to leave the door open in the API to revisit this at some later point, as I think that, especially when managing nested structs in native library, being able to define dependencies between different lifetime is a crucial aspect (at least if you want to lean on the explicit closure mechanism). > > > I've also made an embarrassing mistake, closing the context doesn't > release it's objects, in opencl they all have a reference count on the > context so the other discussion is a little moot.? I believe it does > in vulkan although it's an error to close the instance before all of > it's objects are closed. > > Oh well i'll have to about it more.? Implicit scopes wont be enough in > the case of such an api unless each object also retains a java > reference to it's parent - leaving it up to the application isn't > really safe enough is it? Implicit scopes alone rely on reachability, so you would need to keep things reachable somehow (but something like that was probably also done in ZCL, otherwise how did you keep things alive there?). > > > Just FYI command queues are not short lived, a simple app might be: > > create a context > create a small number of queues > create your kernels > > then set up a processing pipeline - could be multiple, could come and go: > create some memory buffers and images > maybe create some specific kernels > > then execute a processing pipeline - this will happen multiple times, > and an individual execution could span multiple threads: > execute kernels, track execution using events - some will have the > lifetime of the pipeline, others a fragment of it, perhaps > allocate/free temp image/memory along the way > > close everything in reverse > > Given the realisation of my mistake on how the refcounting works in > opencl i think this should be covered by a few relatively simple scope > mechanisms under application control. I believe that to be the case. Having a separate scope per every single OpenCL entity that can be created independently, while theoretically possible, seems overkill to me. In reality, as you outline above, some of these entities will always be created in batches, to perform a certain task. I think that's the time unit you should be focussing on. E.g. from the above, I'd be tempted to put all "global stuff" (context, queues, kernels) in a long-lived, implicit scope. And then have shorter-lived, client managed, scopes for each processing pipeline (and maybe even shorter-lived ones on top to allocate temp data when executing kernels). Maurizio > > ?!Z > From jbhateja at openjdk.java.net Wed Feb 9 19:09:10 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 9 Feb 2022 19:09:10 GMT Subject: [vectorIntrinsics+fp16] RFR: [vectorIntrinsics+fp16] Fix for failing HalfFloat base test. Message-ID: - Create DummyVector backed by short[] arrays for HalffloatSpecies till Halffloat becomes a value type. ------------- Commit messages: - Fix for failing HalfFloat base test. - Fixed space and tabs in code - FP16 Java support Changes: https://git.openjdk.java.net/panama-vector/pull/172/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=172&range=00 Stats: 9583 lines in 22 files changed: 9466 ins; 8 del; 109 mod Patch: https://git.openjdk.java.net/panama-vector/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/172/head:pull/172 PR: https://git.openjdk.java.net/panama-vector/pull/172 From jbhateja at openjdk.java.net Wed Feb 9 19:20:19 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 9 Feb 2022 19:20:19 GMT Subject: [vectorIntrinsics+fp16] Withdrawn: [vectorIntrinsics+fp16] Fix for failing HalfFloat base test. In-Reply-To: References: Message-ID: <9BEp7nafGU46Ju3R100S5pFbPaYYw2XtNHb8vRoEFOM=.4e2a60d3-cb43-4958-aae7-bf63a1ef263d@github.com> On Wed, 9 Feb 2022 19:03:48 GMT, Jatin Bhateja wrote: > - Create DummyVector backed by short[] arrays for HalffloatSpecies till Halffloat becomes a value type. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/172 From svkamath at openjdk.java.net Wed Feb 9 22:57:53 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Wed, 9 Feb 2022 22:57:53 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation Message-ID: 8281562:[vectorapi] Add support for popcount operation ------------- Commit messages: - Add support for popcount operation for Integer and Long types. Changes: https://git.openjdk.java.net/panama-vector/pull/173/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=00 Stats: 181 lines in 8 files changed: 181 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/173/head:pull/173 PR: https://git.openjdk.java.net/panama-vector/pull/173 From svkamath at openjdk.java.net Wed Feb 9 22:57:53 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Wed, 9 Feb 2022 22:57:53 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: <-B-VinFG_aA13HZGKUa-nUZrLihxzy554PyEdmxiB9w=.758ee010-c2c1-478f-92d4-3b14d002f6b6@github.com> On Wed, 9 Feb 2022 22:41:36 GMT, Smita Kamath wrote: > 8281562:[vectorapi] Add support for popcount operation Ive added java changes for popcount operation for Integer and Long types. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From psandoz at openjdk.java.net Wed Feb 9 23:29:26 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Feb 2022 23:29:26 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 22:41:36 GMT, Smita Kamath wrote: > 8281562:[vectorapi] Add support for popcount operation src/hotspot/share/prims/vectorSupport.cpp line 482: > 480: break; > 481: } > 482: case VECTOR_OP_POPCNT: { Can the fall through ever occur? since the operation is only supported for `int` and `long`. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java line 449: > 447: /*package-private*/ > 448: @ForceInline > 449: static int popcount(int a) { This method is not needed. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java line 1806: > 1804: @ForceInline > 1805: public final > 1806: IntVector popcnt() { I recommend not adding such a specific lanewise method for now, and let users use the operation directly. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java line 449: > 447: /*package-private*/ > 448: @ForceInline > 449: static int popcount(long a) { Method is unnecessary. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 454: > 452: public static final Unary NEG = unary("NEG", "-a", VectorSupport.VECTOR_OP_NEG, VO_ALL|VO_SPECIAL); > 453: /** Produce {@code bitCount(a)} */ > 454: public static final Unary POPCNT = unary("POPCNT", "popcnt", VectorSupport.VECTOR_OP_POPCNT, VO_NOFP); Suggest we rename to BIT_COUNT, so its the same as the method on `Integer` and `Long`. LIkewise for the internal opcode VECTOR_OP_POPCNT -> VECTOR_OP_BIT_COUNT. test/jdk/jdk/incubator/vector/PopcountUnitTest.java line 39: > 37: import java.util.stream.IntStream; > 38: > 39: public class PopcountUnitTest { You should replace this test by adding a bitcount test to test framework. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From svkamath at openjdk.java.net Thu Feb 10 00:04:46 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Thu, 10 Feb 2022 00:04:46 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: <2qm3-E4BvevPdUPIvnSGzMpPD89Rzb3tUWog9ArX8E0=.e3eddb67-13a1-443f-8727-57e25919fc65@github.com> On Wed, 9 Feb 2022 23:10:17 GMT, Paul Sandoz wrote: >> 8281562:[vectorapi] Add support for popcount operation > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 454: > >> 452: public static final Unary NEG = unary("NEG", "-a", VectorSupport.VECTOR_OP_NEG, VO_ALL|VO_SPECIAL); >> 453: /** Produce {@code bitCount(a)} */ >> 454: public static final Unary POPCNT = unary("POPCNT", "popcnt", VectorSupport.VECTOR_OP_POPCNT, VO_NOFP); > > Suggest we rename to BIT_COUNT, so its the same as the method on `Integer` and `Long`. LIkewise for the internal opcode VECTOR_OP_POPCNT -> VECTOR_OP_BIT_COUNT. Thanks for your comments, Paul. I will make the required changes. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From svkamath at openjdk.java.net Thu Feb 10 00:59:35 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Thu, 10 Feb 2022 00:59:35 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: <16yZRY7HUV89Qt5NYyoqcBiKUcgKCXPeKh6Liq__q5Y=.6d518092-9d43-4be5-afa6-6b3ff39a1e6b@github.com> On Wed, 9 Feb 2022 23:09:26 GMT, Paul Sandoz wrote: >> 8281562:[vectorapi] Add support for popcount operation > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java line 449: > >> 447: /*package-private*/ >> 448: @ForceInline >> 449: static int popcount(long a) { > > Method is unnecessary. @PaulSandoz Byte and Short types don't have a bitCount method. I will need this supporting method when I implement popcount for them. Do you think it's alright to keep this method? Do let me know. Thank you. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From psandoz at openjdk.java.net Thu Feb 10 01:03:23 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Feb 2022 01:03:23 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: <16yZRY7HUV89Qt5NYyoqcBiKUcgKCXPeKh6Liq__q5Y=.6d518092-9d43-4be5-afa6-6b3ff39a1e6b@github.com> References: <16yZRY7HUV89Qt5NYyoqcBiKUcgKCXPeKh6Liq__q5Y=.6d518092-9d43-4be5-afa6-6b3ff39a1e6b@github.com> Message-ID: On Thu, 10 Feb 2022 00:56:40 GMT, Smita Kamath wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java line 449: >> >>> 447: /*package-private*/ >>> 448: @ForceInline >>> 449: static int popcount(long a) { >> >> Method is unnecessary. > > @PaulSandoz Byte and Short types don't have a bitCount method. I will need this supporting method when I implement popcount for them. Do you think it's alright to keep this method? Do let me know. Thank you. I see. My recommendation is to only add them for byte/short, then as a separate PR to jdk add those methods directly to `Byte` and `Short`. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From duke at openjdk.java.net Thu Feb 10 01:22:17 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 10 Feb 2022 01:22:17 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 23:18:59 GMT, Paul Sandoz wrote: >> 8281562:[vectorapi] Add support for popcount operation > > src/hotspot/share/prims/vectorSupport.cpp line 482: > >> 480: break; >> 481: } >> 482: case VECTOR_OP_POPCNT: { > > Can the fall through ever occur? since the operation is only supported for `int` and `long`. It is also wrong, you can't use the scalar `PopCountI` on byte and short ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From duke at openjdk.java.net Thu Feb 10 01:22:17 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 10 Feb 2022 01:22:17 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 01:17:39 GMT, Quan Anh Mai wrote: >> src/hotspot/share/prims/vectorSupport.cpp line 482: >> >>> 480: break; >>> 481: } >>> 482: case VECTOR_OP_POPCNT: { >> >> Can the fall through ever occur? since the operation is only supported for `int` and `long`. > > It is also wrong, you can't use the scalar `PopCountI` on byte and short Also, are you sure this will work? Since PopCountVL takes a long vector and returns an int vector, I think you need to adjust the C2 compiler before trying to intrinsify this. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From svkamath at openjdk.java.net Thu Feb 10 02:14:22 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Thu, 10 Feb 2022 02:14:22 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 01:19:31 GMT, Quan Anh Mai wrote: >> It is also wrong, you can't use the scalar `PopCountI` on byte and short > > Also, are you sure this will work? Since PopCountVL takes a long vector and returns an int vector, I think you need to adjust the C2 compiler before trying to intrinsify this. @merykitty Thanks for your comment. There will be a follow up patch for C2 compiler related changes. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From jbhateja at openjdk.java.net Thu Feb 10 02:33:24 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 10 Feb 2022 02:33:24 GMT Subject: [vectorIntrinsics+fp16] RFR: 8277304: Java support for FP16 In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 23:52:01 GMT, Smita Kamath wrote: > Initial FP16 vectorAPI Java support. Hi Smita, Following patch fixes the failing base testcase. Thanks, Jatin diff --git a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java index 18c0cb9a725..9def1acdd61 100644 --- a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java +++ b/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java @@ -298,7 +298,16 @@ abstract class AbstractSpecies extends jdk.internal.vm.vector.VectorSupport.V return makeDummyVector(); } private AbstractVector makeDummyVector() { - Object za = Array.newInstance(elementType(), laneCount); + Object za; + // FIXME: Remove following special handling for Halffloat + // till Valhalla integration when Halffloat will become a + // primitive class. + if (elementType() == Halffloat.class) { + za = Array.newInstance(short.class, laneCount); + } else { + za = Array.newInstance(elementType(), laneCount); + } + return dummyVector = vectorFactory.apply(za); // This is the only use of vectorFactory. // All other factory requests are routed diff --git a/test/jdk/jdk/incubator/vector/AddTest.java b/test/jdk/jdk/incubator/vector/AddTest.java index 7c6329a7a3c..7ce077f75ec 100644 --- a/test/jdk/jdk/incubator/vector/AddTest.java +++ b/test/jdk/jdk/incubator/vector/AddTest.java @@ -44,20 +44,18 @@ public class AddTest { static short[] a = new short[SIZE]; static short[] b = new short[SIZE]; static short[] c = new short[SIZE]; - static { for (int i = 0; i < SIZE; i++) { - a[i] = 0x3C66; - b[i] = 0x4066; + a[i] = Halffloat.valueOf((float)i); + b[i] = Halffloat.valueOf((float)i); } } static void workload() { for (int i = 0; i < a.length; i += SPECIES.length()) { HalffloatVector av = HalffloatVector.fromArray(SPECIES, a, i); - //HalffloatVector bv = HalffloatVector.fromArray(SPECIES, b, i); - //av.add(bv).intoArray(c, i); - av.intoArray(c,i); + HalffloatVector bv = HalffloatVector.fromArray(SPECIES, b, i); + av.add(bv).intoArray(c, i); } } @@ -76,8 +74,14 @@ public class AddTest { workload(); } for (int i = 0; i < a.length; i++) { - if (c[i] != a[i] + b[i]) + Halffloat hfa = new Halffloat(a[i]); + Halffloat hfb = new Halffloat(b[i]); + Halffloat hfc = new Halffloat(c[i]); + + if (hfc.floatValue() != (hfa.floatValue() + hfb.floatValue())) { + System.out.println("RES: " + hfc.floatValue() + " EXPECTED: " + (hfa.floatValue() + hfb.floatValue())); throw new AssertionError(); + } } /*Arrays.fill(c, 0.0f); @@ -89,5 +93,6 @@ public class AddTest { if (c[i] != a[i] + b[i]) throw new AssertionError(); }*/ + System.out.println("PASSED"); } } ------------- PR: https://git.openjdk.java.net/panama-vector/pull/164 From maurizio.cimadamore at oracle.com Thu Feb 10 10:05:02 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Feb 2022 10:05:02 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> Message-ID: I have managed to create a simple reproducer on Windows: import jdk.incubator.foreign.CLinker; public class TestLookup { ??? public static void main(String[] args) { ??????? System.load("C:\\Windows\\System32\\ucrtbase.dll"); ??????? CLinker.systemCLinker().lookup("foo"); ??? } } The call to CLinker::lookup fails with UnsatisfiedLinkError as ucrtbase is already loaded by the application class loader. This seems to be a bug in the library loading mechanism - we do have a "raw" library loading mechanism that is not subject to JNI restrictions: https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L99 This library loader ends up calling this method which contains a class loader check: https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L203 I believe this loader check should be guarded by a "isJNI" flag, as we did for other checks - e.g. whether JNI_OnLoad should be called. Cheers Maurizio On 07/02/2022 12:19, Maurizio Cimadamore wrote: > No problem. > > I've filed this: > > https://bugs.openjdk.java.net/browse/JDK-8281335 > > Cheers > Maurizio > > On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >> Hi Maurizio, >> >> thanks allot for your help and for the investigation. >> >> best regards, >> Clemens >> >> >>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>> wrote: >>> >>> ? >>> >>> Hi Clemens (it seems like your message got dropped by the mailing >>> list, not sure why). >>> >>> Your message seems to point at some bad interaction between jpackage >>> and Panama both trying to load ucrtbase.dll (and only one can win). >>> Apparently, the Panama code isn't executed early enough in the >>> jpackage case. >>> >>> We'll need to investigate more. >>> >>> Maurizio >>> >>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>> Hello everybody, >>>> >>>> I am the developer of project librawfx >>>> (github.com/lanthale/librawfx) and the app Photoslide >>>> (github.com/lanthale/photoslide). >>>> >>>> At the begining of Photoslide the whole app was modularized and >>>> therefore all was working including librawfx which is using project >>>> Panama. After a while I had to change to a mixed (modulepath for >>>> jdk+javafx libs and classpath for the rest) environment and >>>> deployed my app PhotoSlide again. Under Linux and OSX all is >>>> working as expected. The problem exists only under Windows. >>>> Furthermore it exists only if I am creating a Jlink/Jpackage >>>> distribution. Running the app from maven was working as expected. >>>> Only the JPackage launcher have the issue and I have no clue what >>>> the root cause is. >>>> >>>> The exception I am always seeing is: >>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>> SCHWERWIEGEND: null >>>> java.lang.UnsatisfiedLinkError: Native Library >>>> C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>>> (Full stacktrace below) >>>> >>>> How can you reproduce the issue: >>>> >>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>>> ?2. Start the app with "mvn javafx:run at default-cli" >>>> ?3. Click on the open icon in the toolbar and select file >>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>> ?4. The app is showing the image below the textarea >>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>>> ??? install" >>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>> ?7. Open the same file again -> No image is shown below the text >>>> ??? area and the exception is thrown in the background >>>> >>>> >>>> I have tried many things but it is only happening if I have >>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>>> files on the classpath. All libs which are not having any Panama >>>> code inside of the app are working perfectly and it is only >>>> happening on Windows. >>>> >>>> Thank you in advance for your help! >>>> >>>> best regards, >>>> Clemens >>>> >>>> >>>> >>>> >>>> *Full stacktrace from Photoslide:* >>>> >>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>>> createSearchIndex >>>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>>> lambda$checkForSoftwareUpdates$2 >>>> INFORMATION: No new version found! >>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>>> lambda$createSearchIndex$0 >>>> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>> SCHWERWIEGEND: null >>>> java.lang.UnsatisfiedLinkError: Native Library >>>> C:\Windows\System32\ucrtbase.dll already loaded in another classloader >>>> at >>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>> Source) >>>> at >>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>>> Source) >>>> at jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>>> Source) >>>> at >>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>>> Source) >>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>> at >>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>>> Source) >>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>>> Source) >>>> at >>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>>> Source) >>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>>> at >>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>> >>>> at >>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>> >>>> at >>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>>> Source) >>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>> at >>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>>> Source) >>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>> Source) >>>> at >>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>> Source) >>>> at java.base/java.lang.Thread.run(Unknown Source) From duke at openjdk.java.net Fri Feb 11 11:05:57 2022 From: duke at openjdk.java.net (duke) Date: Fri, 11 Feb 2022 11:05:57 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 69 new changesets Message-ID: Changeset: 3d926dd6 Author: Rob McKenna Date: 2022-02-04 13:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a 8277795: ldap connection timeout not honoured under contention Reviewed-by: dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java + test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java Changeset: 01f93ddf Author: Matthias Baesken Date: 2022-02-04 07:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01f93ddf18daea5c0798ac949c6717c37d9cefa0 8279385: [test] Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344 Reviewed-by: mullan, xuelei Backport-of: 9bdf6eb7b2412ecff523015f1430dfb6a0e4dd09 ! test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java Changeset: 7207f2a3 Author: Jesper Wilhelmsson Date: 2022-02-04 14:47:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7207f2a3b59c684d9d51d378257629729fa7041d Merge Changeset: 66b2c3b6 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 15:25:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66b2c3b66e253ac3d8718c0c6d7c7551dbe04001 8280948: [TESTBUG] Write a regression test for JDK-4659800 Reviewed-by: aivanov + test/jdk/javax/swing/JButton/4659800/EnterKeyActivatesButton.java Changeset: d4b99bc0 Author: Albert Mingkun Yang Date: 2022-02-04 16:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4b99bc029771d29c2119a9b5f381cae3fe21ec1 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to update_for_block Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: f5d6fddc Author: Daniel D. Daugherty Date: 2022-02-04 17:37:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d6fddc6df8c5c5456a2544b131833d5227292b 8280476: [macOS] : hotspot arm64 bug exposed by latest clang Reviewed-by: kbarrett, adinn ! src/hotspot/cpu/aarch64/immediate_aarch64.cpp Changeset: 8e4ef818 Author: Yumin Qi Date: 2022-02-04 19:20:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8e4ef818a90de35ae75e7f82a780653d623bb29c 8280767: -XX:ArchiveClassesAtExit does not archive BoundMethodHandle$Species classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/lambdaFormInvokers.cpp ! src/hotspot/share/cds/lambdaFormInvokers.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvm.cpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestLambdaInvokers.java Changeset: 48523b09 Author: Kevin Walls Date: 2022-02-04 21:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48523b090886f7b24ed4009f0c150efaa6f7b056 8281049: man page update for jstatd Security Manager dependency removal Reviewed-by: cjplummer ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 42e272e1 Author: Xue-Lei Andrew Fan Date: 2022-02-05 07:44:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42e272e181f188c89fa88f144715f19235943fca 8281289: Improve with List.copyOf Reviewed-by: jnimeh, hchao ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: 77b0240d Author: Joe Darcy Date: 2022-02-06 02:19:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77b0240d44fd356711d75bc241e198f6f89ada8f 8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: f7814c12 Author: Toshio Nakamura Committer: Phil Race Date: 2022-02-06 18:39:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7814c120bf84d7e9b459f81a6ce19b44fa122ec 8139173: [macosx] JInternalFrame shadow is not properly drawn Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java + test/jdk/javax/swing/plaf/aqua/JInternalFrameBorderTest.java Changeset: 2f48a3f0 Author: Phil Race Date: 2022-02-06 21:13:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f48a3f032dcfe159a7ab4a3d0afd0a0760d0a04 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on Ubuntu 21.10 Reviewed-by: serb ! test/jdk/java/awt/font/JNICheck/JNICheck.sh Changeset: 5dfff740 Author: Prasanta Sadhukhan Date: 2022-02-07 04:48:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5dfff7406ef3dc37a77ce9545f6f56c49b41e466 8166050: partialArray is not created in javax.swing.text.html.parser.NPrintWriter.println(...) method Reviewed-by: prr ! src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java Changeset: f2302822 Author: Xue-Lei Andrew Fan Date: 2022-02-07 06:30:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2302822c0ef30fbf7cb4e31b8dc1513e9413a23 8281298: Revise the creation of unmodifiable list Reviewed-by: redestad ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: f5e08700 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-07 08:18:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5e0870091ad9534e7a3dd08ef2e3ee7cd781c6d 8281117: Add regression test for JDK-8280587 Reviewed-by: chagedorn, thartmann, xliu + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead2.java Changeset: 95fd9d20 Author: Alex Menkov Date: 2022-02-07 09:08:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95fd9d20f329b15d68e613ec7f932254715e9130 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing Reviewed-by: sspitsyn, dcubed, lmesnik ! test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java Changeset: f3e82426 Author: Julia Boes Date: 2022-02-07 09:28:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3e8242683f6c729d89e2f49b0977889b4786f4a 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 Reviewed-by: dfuchs ! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java Changeset: 4c169495 Author: Aleksei Efimov Date: 2022-02-07 12:10:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c169495a2c4bfdcbc82e94e9ca1ee0cc050daf9 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled Reviewed-by: dfuchs ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java Changeset: 76677716 Author: Albert Mingkun Yang Date: 2022-02-07 12:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76677716abf1124992c8f5d4d5b159b1ec0f3cab 8281114: G1: Remove PreservedMarks::init_forwarded_mark Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 22a1a32c Author: Stephanie Crater Committer: Thomas Schatzl Date: 2022-02-07 12:43:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22a1a32c7e5ceb7be6725f5369dcfc2a11fecc2f 8268387: Rename maximum compaction to maximal compaction in G1 Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullCollector.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.cpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: a0f6f240 Author: Sean Mullan Date: 2022-02-07 14:06:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0f6f2409ea61ff9ed9dc2e2b46e309c751d456d 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR Reviewed-by: weijun, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + test/jdk/java/security/SignedJar/CustomClassLoader.java + test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java Changeset: 2ed1f4cf Author: Weijun Wang Date: 2022-02-07 15:05:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ed1f4cf32b1cef4ccb129d622f9368c3469d1d4 8281175: Add a -providerPath option to jarsigner Reviewed-by: xuelei, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java ! test/jdk/sun/security/tools/jarsigner/AltProvider.java Changeset: 1dfc94dd Author: Kevin Walls Date: 2022-02-07 17:36:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1dfc94dd561f6a91ef3784fe28c83f839f8188c4 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. Reviewed-by: sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 8a662105 Author: Kevin Walls Date: 2022-02-07 18:16:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a662105c2da1f0fb9b7ecc5058fc85858439ed9 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java Reviewed-by: cjplummer, dfuchs ! test/jdk/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java Changeset: 2f71a6b3 Author: Erik Gahlin Date: 2022-02-07 19:54:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff 8279613: JFR: Snippify Javadoc Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/AnnotationElement.java ! src/jdk.jfr/share/classes/jdk/jfr/Event.java ! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java ! src/jdk.jfr/share/classes/jdk/jfr/EventSettings.java ! src/jdk.jfr/share/classes/jdk/jfr/FlightRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/MetadataDefinition.java ! src/jdk.jfr/share/classes/jdk/jfr/Recording.java ! src/jdk.jfr/share/classes/jdk/jfr/SettingControl.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/EventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/package-info.java + src/jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files/Snippets.java + src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 4eacacb5 Author: Aleksey Shipilev Date: 2022-02-08 07:19:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eacacb5ad61020c11a521111c40af9fa72e2ff5 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages multipliers Reviewed-by: stuefe, coleenp, xliu ! src/hotspot/share/runtime/stackOverflow.cpp Changeset: f2a9627c Author: Masanori Yano Committer: Alan Bateman Date: 2022-02-08 08:31:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2a9627c05f9ef82eb83d8c1b9d4209bf42e7d8d 8279329: Remove hardcoded IPv4 available policy on Windows Reviewed-by: djelinski, alanb, dfuchs, aefimov ! src/java.base/windows/native/libnet/net_util_md.c Changeset: 861f2797 Author: Kim Barrett Date: 2022-02-08 09:02:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/861f2797f7d56ab185117f27dae2660af9250f6a 8280917: Simplify G1ConcurrentRefineThread activation Reviewed-by: iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: f5d8cebb Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-08 12:39:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d8cebbb6f1b38247c3b30ba8859874a0e98115 8281296: Create a regression test for JDK-4515999 Reviewed-by: aivanov + test/jdk/javax/swing/JSpinner/4515999/JSpinnerMouseAndKeyPressTest.java Changeset: 83d67452 Author: Thomas Stuefe Date: 2022-02-08 14:43:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83d67452da248db17bc72de80247a670d6813cf5 8281450: Remove unnecessary operator new and delete from ObjectMonitor Reviewed-by: dholmes ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 380378c5 Author: Harold Seigel Date: 2022-02-08 16:00:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/380378c551b4243ef72d868571f725b390e12124 8281400: Remove unused wcslen() function Reviewed-by: dcubed, coleenp, lfoltan ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: 7f19c700 Author: Martin Doerr Date: 2022-02-08 17:48:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f19c700707573000a37910dd6d2f2bb6e8439ad 8281061: [s390] JFR runs into assertions while validating interpreter frames Reviewed-by: lucy, rrich ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: 92f4f40d Author: Christian Stein Committer: Lance Andersen Date: 2022-02-08 17:53:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92f4f40da6c4ff55c7ed334007c9c6ca0dc15d99 8281104: jar --create should create missing parent directories Reviewed-by: lancea ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties + test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: 5fb56dbb Author: Daniel D. Daugherty Date: 2022-02-08 20:16:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5fb56dbb0b4e3345ca6f48ba9c01bd467f04aa6f 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java Reviewed-by: azvegint, bpb, lancea ! test/jdk/ProblemList.txt Changeset: d658d945 Author: Kim Barrett Date: 2022-02-08 20:29:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d658d945cf57bab8e61302841dcb56b36e48eff3 8280828: Improve invariants in NonblockingQueue::append Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: fb17a8ec Author: Quan Anh Mai Committer: Jie Fu Date: 2022-02-08 23:38:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb17a8ece0a3593c51a8be60533916bf70778a93 8278947: Support for array constants in constant table Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/opto/constantTable.cpp ! src/hotspot/share/opto/constantTable.hpp Changeset: 2f46af05 Author: Sergey Bylokhov Date: 2022-02-09 01:26:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f46af05ce2d43e19e0095680eb3a52fd904c774 8280132: Incorrect comparator com.sun.beans.introspect.MethodInfo.MethodOrder Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java ! test/jdk/java/beans/Introspector/MethodOrderException.java Changeset: 13f739d3 Author: Kim Barrett Date: 2022-02-09 04:10:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13f739d330e393f840d134f5327a025957e1f795 8280830: Change NonblockingQueue::try_pop variable named "result" Reviewed-by: dholmes ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: bce5dd17 Author: Kim Barrett Date: 2022-02-09 04:38:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bce5dd17665d1cdf2901690ca54f84ec200560af 8280438: Improve BufferNode::Allocator::release to avoid walking pending list Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp Changeset: fc772178 Author: Aleksey Shipilev Date: 2022-02-09 06:28:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc77217814eb1a346d7380299abdc2b01a69b4de 8281168: Micro-optimize VarForm.getMemberName for interpreter Reviewed-by: redestad, vlivanov, mchung ! src/java.base/share/classes/java/lang/invoke/VarForm.java Changeset: cb2f8cae Author: Artem Semenov Date: 2022-02-09 06:50:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb2f8caed2de1bf0a85a7ebfd232c36371e06c98 8281338: NSAccessibilityPressAction action for tree node and NSAccessibilityShowMenuAcgtion action not working Reviewed-by: ant, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m + test/jdk/java/awt/a11y/AccessibleActionsTest.java Changeset: 072e7b4d Author: Kim Barrett Date: 2022-02-09 06:53:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c 8272807: Permit use of memory concurrent with pretouch Reviewed-by: shade, stuefe ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: f924e50c Author: Daniel Jeli?ski Committer: Alexey Ivanov Date: 2022-02-09 08:34:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f924e50c42c2f9548d2983449a98c45af40b0d35 8281440: AWT: Conversion from string literal loses const qualifier Reviewed-by: prr, aivanov ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DesktopProperties.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DrawingSurface.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp Changeset: f092baba Author: Alexey Pavlyutkin Committer: Aleksey Shipilev Date: 2022-02-09 09:33:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f092babafb58563a4044463e157e02c397d8c9bc 8281195: Mistakenly used logging causes significant overhead in interpreter Reviewed-by: shade, dholmes ! src/hotspot/share/interpreter/oopMapCache.cpp Changeset: 69e390a0 Author: Roland Westrelin Date: 2022-02-09 10:18:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69e390a0e86f82eaa7bcdbc3ef509734dbe3b22f 8262721: Add Tests to verify single iteration loops are properly optimized Reviewed-by: neliasso, chagedorn, kvn + test/hotspot/jtreg/compiler/c2/irTests/TestFewIterationsCountedLoop.java Changeset: bb2e10cc Author: Matthias Baesken Date: 2022-02-09 11:33:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb2e10ccea0c0b89b06ace034c99253e9999ec47 8281274: deal with ActiveProcessorCount in os::Linux::print_container_info Reviewed-by: stuefe, sgehwolf, dholmes, iklam ! src/hotspot/os/linux/os_linux.cpp ! test/hotspot/jtreg/containers/docker/TestMisc.java Changeset: 8b384b98 Author: Christian Stein Committer: Lance Andersen Date: 2022-02-09 11:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b384b986a0a6a972c29a2f7a4d9fd40dc479b48 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" Reviewed-by: lancea ! test/jdk/ProblemList.txt ! test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: f823bed0 Author: Bhavana Kilambi Committer: Paul Hohensee Date: 2022-02-09 13:18:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f823bed043dc38d838baaf8c2024ef24b8a50e9b 8280007: Enable Neoverse N1 optimizations for Arm Neoverse V1 & N2 Reviewed-by: phh ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp Changeset: c5c8c064 Author: Vladimir Ivanov Date: 2022-02-09 13:56:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5c8c0644d9442846de15422285fffeb91c3e0a1 8279822: CI: Constant pool entries in error state are not supported Reviewed-by: kvn, thartmann ! src/hotspot/share/ci/bcEscapeAnalyzer.cpp ! src/hotspot/share/ci/ciConstant.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciStreams.hpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/utilities/constantTag.hpp + test/hotspot/jtreg/compiler/runtime/TestConstantsInError.java Changeset: 178b962e Author: Hai-May Chao Date: 2022-02-09 16:53:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/178b962e01cc6c150442bf41dc6bd199caff0042 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty Reviewed-by: weijun ! src/java.base/share/classes/sun/security/provider/DomainKeyStore.java + test/jdk/sun/security/provider/KeyStore/DksWithEmptyKeystore.java Changeset: fd8a3dcc Author: Alexey Ivanov Date: 2022-02-09 19:12:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd8a3dcc52dc5d6b62edd83eacef5934f6294e80 8280820: Clean up bug8033699 and bug8075609.java tests: regtesthelpers aren't used Reviewed-by: prr ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java ! test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java Changeset: 7218d844 Author: John Jiang Date: 2022-02-10 08:11:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7218d8449bfaa3f121b66088a88a194f77f06753 8281567: Remove @throws IOException from X509CRLImpl::getExtension docs Reviewed-by: xuelei, jiefu ! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java Changeset: fa0a72c0 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-10 09:29:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa0a72c030432f9ea4ad9913a2bb4096324410aa 8252496: C2: Useless code in MergeMemNode::Ideal Reviewed-by: thartmann, chagedorn, vlivanov ! src/hotspot/share/opto/memnode.cpp Changeset: c820d1ac Author: Leo Korinth Date: 2022-02-10 10:34:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c820d1acb7c6e600a890e4205eef0be8a4c7a791 8281379: Assign package declarations to all jtreg test cases under gc Reviewed-by: kbarrett, tschatzl ! test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java ! test/hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java ! test/hotspot/jtreg/gc/z/TestGarbageCollectorMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryManagerMXBean.java Changeset: d442328b Author: Maxim Kartashev Committer: Magnus Ihse Bursie Date: 2022-02-10 10:46:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d442328bc2f2f4bc35dd054487a78552e3d9a759 8281262: Windows builds in different directories are not fully reproducible Co-authored-by: Erik Joelsson Reviewed-by: erikj, ihse ! make/TestImage.gmk ! make/autoconf/flags-cflags.m4 ! test/jdk/build/AbsPathsInImage.java Changeset: 3ce1c5b6 Author: Kim Barrett Date: 2022-02-10 11:28:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3ce1c5b6ce02749ef8f9d35409b7bcbf27f47203 8280832: Update usage docs for NonblockingQueue Reviewed-by: iwalulya, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 039313d6 Author: Prasanta Sadhukhan Date: 2022-02-10 12:02:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/039313d65d47dc85cb8c91d3e1d2752d365f70f9 8054449: Incompatible type in example code in TreePath Reviewed-by: aivanov, dmarkov ! src/java.desktop/share/classes/javax/swing/tree/TreePath.java Changeset: 83b6e4bc Author: Paul Sandoz Date: 2022-02-10 18:37:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83b6e4bc04db89a846a1b6c2d0666efe139f8f61 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors Reviewed-by: jrose ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Max-op.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Min-op.template + test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-op-func.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template Changeset: 58c2bd31 Author: Erik Gahlin Date: 2022-02-10 22:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58c2bd315836b9c4fbffa212497fd84c8f589c17 8281536: JFR: Improve jdk.jfr.ContentType documentation Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/ContentType.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 84868e39 Author: David Holmes Date: 2022-02-10 23:23:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/84868e39be4522ba87e603beea0f8da9efa43b6d 8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath separator in gc paths Reviewed-by: shade, dcubed ! src/hotspot/share/logging/logConfiguration.cpp ! test/hotspot/gtest/logging/test_logConfiguration.cpp Changeset: eee6a562 Author: Thomas Stuefe Date: 2022-02-11 05:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eee6a5622dca683d4d6a701daa48e09e8d17b54e 8281522: Rename ADLC classes which have the same name as hotspot variants Reviewed-by: neliasso, kvn + src/hotspot/share/adlc/adlArena.cpp + src/hotspot/share/adlc/adlArena.hpp ! src/hotspot/share/adlc/adlc.hpp ! src/hotspot/share/adlc/adlparse.cpp - src/hotspot/share/adlc/arena.cpp - src/hotspot/share/adlc/arena.hpp ! src/hotspot/share/adlc/dfa.cpp ! src/hotspot/share/adlc/dict2.cpp ! src/hotspot/share/adlc/dict2.hpp ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/forms.hpp ! src/hotspot/share/adlc/formsopt.cpp ! src/hotspot/share/adlc/formssel.cpp Changeset: 65831eb2 Author: Aleksey Shipilev Date: 2022-02-11 06:45:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65831eb294b6f1f5f99988836c00005d41c27fd3 8281318: Improve jfr/event/allocation tests reliability Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationInNewTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationOutsideTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventThrottling.java Changeset: a037b3c3 Author: Thomas Stuefe Date: 2022-02-11 07:21:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a037b3c35831f029d23a88bdd49e7f2c2d951631 8281460: Let ObjectMonitor have its own NMT category Reviewed-by: dholmes, dcubed, shade ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 8441d51e Author: Sergey Bylokhov Date: 2022-02-11 07:41:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8441d51e71e143250b44eea74114a624cf00cc3e 8281419: The source data for the color conversion can be discarded Reviewed-by: prr, aivanov ! src/java.desktop/share/native/liblcms/LCMS.c Changeset: 3a13425b Author: Aleksey Shipilev Date: 2022-02-11 08:46:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3a13425bc9088cbb6d95e1a46248d7eba27fb1a6 8072070: Improve interpreter stack banging Reviewed-by: xliu, coleenp, mdoerr ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/stackOverflow.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 90939cb8 Author: Kim Barrett Date: 2022-02-11 09:05:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90939cb80193c671cae635b7a4e41bd2e6bcdbd5 8281626: NonblockingQueue should use nullptr Reviewed-by: shade, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 4d640760 Author: Prasanta Sadhukhan Date: 2022-02-11 09:39:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d64076058a4ec5df101b06572195ed5fdee6f64 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect Reviewed-by: aivanov ! src/java.desktop/share/classes/javax/swing/plaf/TreeUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: 2d985cd7 Author: duke Date: 2022-02-11 11:00:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d985cd71ed870ed87329888fa389860153694d7 Automatic merge of jdk:master into master Changeset: 8230a7f6 Author: duke Date: 2022-02-11 11:01:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8230a7f60de38ffc50a8460a9e891b539084cdd8 Automatic merge of master into foreign-memaccess+abi ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.cpp From duke at openjdk.java.net Fri Feb 11 11:10:05 2022 From: duke at openjdk.java.net (duke) Date: Fri, 11 Feb 2022 11:10:05 GMT Subject: git: openjdk/panama-foreign: master: 68 new changesets Message-ID: <22b49e26-8474-41d4-b785-308a24c31830@openjdk.org> Changeset: 3d926dd6 Author: Rob McKenna Date: 2022-02-04 13:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a 8277795: ldap connection timeout not honoured under contention Reviewed-by: dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java + test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java Changeset: 01f93ddf Author: Matthias Baesken Date: 2022-02-04 07:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01f93ddf18daea5c0798ac949c6717c37d9cefa0 8279385: [test] Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344 Reviewed-by: mullan, xuelei Backport-of: 9bdf6eb7b2412ecff523015f1430dfb6a0e4dd09 ! test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java Changeset: 7207f2a3 Author: Jesper Wilhelmsson Date: 2022-02-04 14:47:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7207f2a3b59c684d9d51d378257629729fa7041d Merge Changeset: 66b2c3b6 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 15:25:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66b2c3b66e253ac3d8718c0c6d7c7551dbe04001 8280948: [TESTBUG] Write a regression test for JDK-4659800 Reviewed-by: aivanov + test/jdk/javax/swing/JButton/4659800/EnterKeyActivatesButton.java Changeset: d4b99bc0 Author: Albert Mingkun Yang Date: 2022-02-04 16:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4b99bc029771d29c2119a9b5f381cae3fe21ec1 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to update_for_block Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: f5d6fddc Author: Daniel D. Daugherty Date: 2022-02-04 17:37:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d6fddc6df8c5c5456a2544b131833d5227292b 8280476: [macOS] : hotspot arm64 bug exposed by latest clang Reviewed-by: kbarrett, adinn ! src/hotspot/cpu/aarch64/immediate_aarch64.cpp Changeset: 8e4ef818 Author: Yumin Qi Date: 2022-02-04 19:20:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8e4ef818a90de35ae75e7f82a780653d623bb29c 8280767: -XX:ArchiveClassesAtExit does not archive BoundMethodHandle$Species classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/lambdaFormInvokers.cpp ! src/hotspot/share/cds/lambdaFormInvokers.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvm.cpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestLambdaInvokers.java Changeset: 48523b09 Author: Kevin Walls Date: 2022-02-04 21:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48523b090886f7b24ed4009f0c150efaa6f7b056 8281049: man page update for jstatd Security Manager dependency removal Reviewed-by: cjplummer ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 42e272e1 Author: Xue-Lei Andrew Fan Date: 2022-02-05 07:44:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42e272e181f188c89fa88f144715f19235943fca 8281289: Improve with List.copyOf Reviewed-by: jnimeh, hchao ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: 77b0240d Author: Joe Darcy Date: 2022-02-06 02:19:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77b0240d44fd356711d75bc241e198f6f89ada8f 8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: f7814c12 Author: Toshio Nakamura Committer: Phil Race Date: 2022-02-06 18:39:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7814c120bf84d7e9b459f81a6ce19b44fa122ec 8139173: [macosx] JInternalFrame shadow is not properly drawn Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java + test/jdk/javax/swing/plaf/aqua/JInternalFrameBorderTest.java Changeset: 2f48a3f0 Author: Phil Race Date: 2022-02-06 21:13:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f48a3f032dcfe159a7ab4a3d0afd0a0760d0a04 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on Ubuntu 21.10 Reviewed-by: serb ! test/jdk/java/awt/font/JNICheck/JNICheck.sh Changeset: 5dfff740 Author: Prasanta Sadhukhan Date: 2022-02-07 04:48:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5dfff7406ef3dc37a77ce9545f6f56c49b41e466 8166050: partialArray is not created in javax.swing.text.html.parser.NPrintWriter.println(...) method Reviewed-by: prr ! src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java Changeset: f2302822 Author: Xue-Lei Andrew Fan Date: 2022-02-07 06:30:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2302822c0ef30fbf7cb4e31b8dc1513e9413a23 8281298: Revise the creation of unmodifiable list Reviewed-by: redestad ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: f5e08700 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-07 08:18:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5e0870091ad9534e7a3dd08ef2e3ee7cd781c6d 8281117: Add regression test for JDK-8280587 Reviewed-by: chagedorn, thartmann, xliu + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead2.java Changeset: 95fd9d20 Author: Alex Menkov Date: 2022-02-07 09:08:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95fd9d20f329b15d68e613ec7f932254715e9130 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing Reviewed-by: sspitsyn, dcubed, lmesnik ! test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java Changeset: f3e82426 Author: Julia Boes Date: 2022-02-07 09:28:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3e8242683f6c729d89e2f49b0977889b4786f4a 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 Reviewed-by: dfuchs ! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java Changeset: 4c169495 Author: Aleksei Efimov Date: 2022-02-07 12:10:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c169495a2c4bfdcbc82e94e9ca1ee0cc050daf9 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled Reviewed-by: dfuchs ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java Changeset: 76677716 Author: Albert Mingkun Yang Date: 2022-02-07 12:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76677716abf1124992c8f5d4d5b159b1ec0f3cab 8281114: G1: Remove PreservedMarks::init_forwarded_mark Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 22a1a32c Author: Stephanie Crater Committer: Thomas Schatzl Date: 2022-02-07 12:43:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22a1a32c7e5ceb7be6725f5369dcfc2a11fecc2f 8268387: Rename maximum compaction to maximal compaction in G1 Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullCollector.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.cpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: a0f6f240 Author: Sean Mullan Date: 2022-02-07 14:06:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0f6f2409ea61ff9ed9dc2e2b46e309c751d456d 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR Reviewed-by: weijun, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + test/jdk/java/security/SignedJar/CustomClassLoader.java + test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java Changeset: 2ed1f4cf Author: Weijun Wang Date: 2022-02-07 15:05:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ed1f4cf32b1cef4ccb129d622f9368c3469d1d4 8281175: Add a -providerPath option to jarsigner Reviewed-by: xuelei, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java ! test/jdk/sun/security/tools/jarsigner/AltProvider.java Changeset: 1dfc94dd Author: Kevin Walls Date: 2022-02-07 17:36:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1dfc94dd561f6a91ef3784fe28c83f839f8188c4 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. Reviewed-by: sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 8a662105 Author: Kevin Walls Date: 2022-02-07 18:16:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a662105c2da1f0fb9b7ecc5058fc85858439ed9 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java Reviewed-by: cjplummer, dfuchs ! test/jdk/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java Changeset: 2f71a6b3 Author: Erik Gahlin Date: 2022-02-07 19:54:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff 8279613: JFR: Snippify Javadoc Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/AnnotationElement.java ! src/jdk.jfr/share/classes/jdk/jfr/Event.java ! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java ! src/jdk.jfr/share/classes/jdk/jfr/EventSettings.java ! src/jdk.jfr/share/classes/jdk/jfr/FlightRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/MetadataDefinition.java ! src/jdk.jfr/share/classes/jdk/jfr/Recording.java ! src/jdk.jfr/share/classes/jdk/jfr/SettingControl.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/EventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/package-info.java + src/jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files/Snippets.java + src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 4eacacb5 Author: Aleksey Shipilev Date: 2022-02-08 07:19:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eacacb5ad61020c11a521111c40af9fa72e2ff5 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages multipliers Reviewed-by: stuefe, coleenp, xliu ! src/hotspot/share/runtime/stackOverflow.cpp Changeset: f2a9627c Author: Masanori Yano Committer: Alan Bateman Date: 2022-02-08 08:31:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2a9627c05f9ef82eb83d8c1b9d4209bf42e7d8d 8279329: Remove hardcoded IPv4 available policy on Windows Reviewed-by: djelinski, alanb, dfuchs, aefimov ! src/java.base/windows/native/libnet/net_util_md.c Changeset: 861f2797 Author: Kim Barrett Date: 2022-02-08 09:02:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/861f2797f7d56ab185117f27dae2660af9250f6a 8280917: Simplify G1ConcurrentRefineThread activation Reviewed-by: iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: f5d8cebb Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-08 12:39:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d8cebbb6f1b38247c3b30ba8859874a0e98115 8281296: Create a regression test for JDK-4515999 Reviewed-by: aivanov + test/jdk/javax/swing/JSpinner/4515999/JSpinnerMouseAndKeyPressTest.java Changeset: 83d67452 Author: Thomas Stuefe Date: 2022-02-08 14:43:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83d67452da248db17bc72de80247a670d6813cf5 8281450: Remove unnecessary operator new and delete from ObjectMonitor Reviewed-by: dholmes ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 380378c5 Author: Harold Seigel Date: 2022-02-08 16:00:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/380378c551b4243ef72d868571f725b390e12124 8281400: Remove unused wcslen() function Reviewed-by: dcubed, coleenp, lfoltan ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: 7f19c700 Author: Martin Doerr Date: 2022-02-08 17:48:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f19c700707573000a37910dd6d2f2bb6e8439ad 8281061: [s390] JFR runs into assertions while validating interpreter frames Reviewed-by: lucy, rrich ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: 92f4f40d Author: Christian Stein Committer: Lance Andersen Date: 2022-02-08 17:53:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92f4f40da6c4ff55c7ed334007c9c6ca0dc15d99 8281104: jar --create should create missing parent directories Reviewed-by: lancea ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties + test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: 5fb56dbb Author: Daniel D. Daugherty Date: 2022-02-08 20:16:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5fb56dbb0b4e3345ca6f48ba9c01bd467f04aa6f 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java Reviewed-by: azvegint, bpb, lancea ! test/jdk/ProblemList.txt Changeset: d658d945 Author: Kim Barrett Date: 2022-02-08 20:29:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d658d945cf57bab8e61302841dcb56b36e48eff3 8280828: Improve invariants in NonblockingQueue::append Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: fb17a8ec Author: Quan Anh Mai Committer: Jie Fu Date: 2022-02-08 23:38:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb17a8ece0a3593c51a8be60533916bf70778a93 8278947: Support for array constants in constant table Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/opto/constantTable.cpp ! src/hotspot/share/opto/constantTable.hpp Changeset: 2f46af05 Author: Sergey Bylokhov Date: 2022-02-09 01:26:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f46af05ce2d43e19e0095680eb3a52fd904c774 8280132: Incorrect comparator com.sun.beans.introspect.MethodInfo.MethodOrder Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java ! test/jdk/java/beans/Introspector/MethodOrderException.java Changeset: 13f739d3 Author: Kim Barrett Date: 2022-02-09 04:10:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13f739d330e393f840d134f5327a025957e1f795 8280830: Change NonblockingQueue::try_pop variable named "result" Reviewed-by: dholmes ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: bce5dd17 Author: Kim Barrett Date: 2022-02-09 04:38:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bce5dd17665d1cdf2901690ca54f84ec200560af 8280438: Improve BufferNode::Allocator::release to avoid walking pending list Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp Changeset: fc772178 Author: Aleksey Shipilev Date: 2022-02-09 06:28:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc77217814eb1a346d7380299abdc2b01a69b4de 8281168: Micro-optimize VarForm.getMemberName for interpreter Reviewed-by: redestad, vlivanov, mchung ! src/java.base/share/classes/java/lang/invoke/VarForm.java Changeset: cb2f8cae Author: Artem Semenov Date: 2022-02-09 06:50:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb2f8caed2de1bf0a85a7ebfd232c36371e06c98 8281338: NSAccessibilityPressAction action for tree node and NSAccessibilityShowMenuAcgtion action not working Reviewed-by: ant, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m + test/jdk/java/awt/a11y/AccessibleActionsTest.java Changeset: 072e7b4d Author: Kim Barrett Date: 2022-02-09 06:53:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c 8272807: Permit use of memory concurrent with pretouch Reviewed-by: shade, stuefe ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: f924e50c Author: Daniel Jeli?ski Committer: Alexey Ivanov Date: 2022-02-09 08:34:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f924e50c42c2f9548d2983449a98c45af40b0d35 8281440: AWT: Conversion from string literal loses const qualifier Reviewed-by: prr, aivanov ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DesktopProperties.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DrawingSurface.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp Changeset: f092baba Author: Alexey Pavlyutkin Committer: Aleksey Shipilev Date: 2022-02-09 09:33:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f092babafb58563a4044463e157e02c397d8c9bc 8281195: Mistakenly used logging causes significant overhead in interpreter Reviewed-by: shade, dholmes ! src/hotspot/share/interpreter/oopMapCache.cpp Changeset: 69e390a0 Author: Roland Westrelin Date: 2022-02-09 10:18:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69e390a0e86f82eaa7bcdbc3ef509734dbe3b22f 8262721: Add Tests to verify single iteration loops are properly optimized Reviewed-by: neliasso, chagedorn, kvn + test/hotspot/jtreg/compiler/c2/irTests/TestFewIterationsCountedLoop.java Changeset: bb2e10cc Author: Matthias Baesken Date: 2022-02-09 11:33:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb2e10ccea0c0b89b06ace034c99253e9999ec47 8281274: deal with ActiveProcessorCount in os::Linux::print_container_info Reviewed-by: stuefe, sgehwolf, dholmes, iklam ! src/hotspot/os/linux/os_linux.cpp ! test/hotspot/jtreg/containers/docker/TestMisc.java Changeset: 8b384b98 Author: Christian Stein Committer: Lance Andersen Date: 2022-02-09 11:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b384b986a0a6a972c29a2f7a4d9fd40dc479b48 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" Reviewed-by: lancea ! test/jdk/ProblemList.txt ! test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: f823bed0 Author: Bhavana Kilambi Committer: Paul Hohensee Date: 2022-02-09 13:18:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f823bed043dc38d838baaf8c2024ef24b8a50e9b 8280007: Enable Neoverse N1 optimizations for Arm Neoverse V1 & N2 Reviewed-by: phh ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp Changeset: c5c8c064 Author: Vladimir Ivanov Date: 2022-02-09 13:56:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5c8c0644d9442846de15422285fffeb91c3e0a1 8279822: CI: Constant pool entries in error state are not supported Reviewed-by: kvn, thartmann ! src/hotspot/share/ci/bcEscapeAnalyzer.cpp ! src/hotspot/share/ci/ciConstant.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciStreams.hpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/utilities/constantTag.hpp + test/hotspot/jtreg/compiler/runtime/TestConstantsInError.java Changeset: 178b962e Author: Hai-May Chao Date: 2022-02-09 16:53:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/178b962e01cc6c150442bf41dc6bd199caff0042 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty Reviewed-by: weijun ! src/java.base/share/classes/sun/security/provider/DomainKeyStore.java + test/jdk/sun/security/provider/KeyStore/DksWithEmptyKeystore.java Changeset: fd8a3dcc Author: Alexey Ivanov Date: 2022-02-09 19:12:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd8a3dcc52dc5d6b62edd83eacef5934f6294e80 8280820: Clean up bug8033699 and bug8075609.java tests: regtesthelpers aren't used Reviewed-by: prr ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java ! test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java Changeset: 7218d844 Author: John Jiang Date: 2022-02-10 08:11:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7218d8449bfaa3f121b66088a88a194f77f06753 8281567: Remove @throws IOException from X509CRLImpl::getExtension docs Reviewed-by: xuelei, jiefu ! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java Changeset: fa0a72c0 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-10 09:29:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa0a72c030432f9ea4ad9913a2bb4096324410aa 8252496: C2: Useless code in MergeMemNode::Ideal Reviewed-by: thartmann, chagedorn, vlivanov ! src/hotspot/share/opto/memnode.cpp Changeset: c820d1ac Author: Leo Korinth Date: 2022-02-10 10:34:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c820d1acb7c6e600a890e4205eef0be8a4c7a791 8281379: Assign package declarations to all jtreg test cases under gc Reviewed-by: kbarrett, tschatzl ! test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java ! test/hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java ! test/hotspot/jtreg/gc/z/TestGarbageCollectorMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryManagerMXBean.java Changeset: d442328b Author: Maxim Kartashev Committer: Magnus Ihse Bursie Date: 2022-02-10 10:46:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d442328bc2f2f4bc35dd054487a78552e3d9a759 8281262: Windows builds in different directories are not fully reproducible Co-authored-by: Erik Joelsson Reviewed-by: erikj, ihse ! make/TestImage.gmk ! make/autoconf/flags-cflags.m4 ! test/jdk/build/AbsPathsInImage.java Changeset: 3ce1c5b6 Author: Kim Barrett Date: 2022-02-10 11:28:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3ce1c5b6ce02749ef8f9d35409b7bcbf27f47203 8280832: Update usage docs for NonblockingQueue Reviewed-by: iwalulya, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 039313d6 Author: Prasanta Sadhukhan Date: 2022-02-10 12:02:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/039313d65d47dc85cb8c91d3e1d2752d365f70f9 8054449: Incompatible type in example code in TreePath Reviewed-by: aivanov, dmarkov ! src/java.desktop/share/classes/javax/swing/tree/TreePath.java Changeset: 83b6e4bc Author: Paul Sandoz Date: 2022-02-10 18:37:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83b6e4bc04db89a846a1b6c2d0666efe139f8f61 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors Reviewed-by: jrose ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Max-op.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Min-op.template + test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-op-func.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template Changeset: 58c2bd31 Author: Erik Gahlin Date: 2022-02-10 22:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58c2bd315836b9c4fbffa212497fd84c8f589c17 8281536: JFR: Improve jdk.jfr.ContentType documentation Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/ContentType.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 84868e39 Author: David Holmes Date: 2022-02-10 23:23:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/84868e39be4522ba87e603beea0f8da9efa43b6d 8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath separator in gc paths Reviewed-by: shade, dcubed ! src/hotspot/share/logging/logConfiguration.cpp ! test/hotspot/gtest/logging/test_logConfiguration.cpp Changeset: eee6a562 Author: Thomas Stuefe Date: 2022-02-11 05:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eee6a5622dca683d4d6a701daa48e09e8d17b54e 8281522: Rename ADLC classes which have the same name as hotspot variants Reviewed-by: neliasso, kvn + src/hotspot/share/adlc/adlArena.cpp + src/hotspot/share/adlc/adlArena.hpp ! src/hotspot/share/adlc/adlc.hpp ! src/hotspot/share/adlc/adlparse.cpp - src/hotspot/share/adlc/arena.cpp - src/hotspot/share/adlc/arena.hpp ! src/hotspot/share/adlc/dfa.cpp ! src/hotspot/share/adlc/dict2.cpp ! src/hotspot/share/adlc/dict2.hpp ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/forms.hpp ! src/hotspot/share/adlc/formsopt.cpp ! src/hotspot/share/adlc/formssel.cpp Changeset: 65831eb2 Author: Aleksey Shipilev Date: 2022-02-11 06:45:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65831eb294b6f1f5f99988836c00005d41c27fd3 8281318: Improve jfr/event/allocation tests reliability Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationInNewTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationOutsideTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventThrottling.java Changeset: a037b3c3 Author: Thomas Stuefe Date: 2022-02-11 07:21:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a037b3c35831f029d23a88bdd49e7f2c2d951631 8281460: Let ObjectMonitor have its own NMT category Reviewed-by: dholmes, dcubed, shade ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 8441d51e Author: Sergey Bylokhov Date: 2022-02-11 07:41:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8441d51e71e143250b44eea74114a624cf00cc3e 8281419: The source data for the color conversion can be discarded Reviewed-by: prr, aivanov ! src/java.desktop/share/native/liblcms/LCMS.c Changeset: 3a13425b Author: Aleksey Shipilev Date: 2022-02-11 08:46:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3a13425bc9088cbb6d95e1a46248d7eba27fb1a6 8072070: Improve interpreter stack banging Reviewed-by: xliu, coleenp, mdoerr ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/stackOverflow.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 90939cb8 Author: Kim Barrett Date: 2022-02-11 09:05:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90939cb80193c671cae635b7a4e41bd2e6bcdbd5 8281626: NonblockingQueue should use nullptr Reviewed-by: shade, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 4d640760 Author: Prasanta Sadhukhan Date: 2022-02-11 09:39:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d64076058a4ec5df101b06572195ed5fdee6f64 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect Reviewed-by: aivanov ! src/java.desktop/share/classes/javax/swing/plaf/TreeUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: 2d985cd7 Author: duke Date: 2022-02-11 11:00:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d985cd71ed870ed87329888fa389860153694d7 Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Feb 11 11:16:27 2022 From: duke at openjdk.java.net (duke) Date: Fri, 11 Feb 2022 11:16:27 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 70 new changesets Message-ID: <32d61b94-b6c5-4a1f-82c9-8587881ffcf2@openjdk.org> Changeset: 3d926dd6 Author: Rob McKenna Date: 2022-02-04 13:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a 8277795: ldap connection timeout not honoured under contention Reviewed-by: dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java + test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java Changeset: 01f93ddf Author: Matthias Baesken Date: 2022-02-04 07:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01f93ddf18daea5c0798ac949c6717c37d9cefa0 8279385: [test] Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344 Reviewed-by: mullan, xuelei Backport-of: 9bdf6eb7b2412ecff523015f1430dfb6a0e4dd09 ! test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java Changeset: 7207f2a3 Author: Jesper Wilhelmsson Date: 2022-02-04 14:47:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7207f2a3b59c684d9d51d378257629729fa7041d Merge Changeset: 66b2c3b6 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 15:25:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66b2c3b66e253ac3d8718c0c6d7c7551dbe04001 8280948: [TESTBUG] Write a regression test for JDK-4659800 Reviewed-by: aivanov + test/jdk/javax/swing/JButton/4659800/EnterKeyActivatesButton.java Changeset: d4b99bc0 Author: Albert Mingkun Yang Date: 2022-02-04 16:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4b99bc029771d29c2119a9b5f381cae3fe21ec1 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to update_for_block Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: f5d6fddc Author: Daniel D. Daugherty Date: 2022-02-04 17:37:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d6fddc6df8c5c5456a2544b131833d5227292b 8280476: [macOS] : hotspot arm64 bug exposed by latest clang Reviewed-by: kbarrett, adinn ! src/hotspot/cpu/aarch64/immediate_aarch64.cpp Changeset: 8e4ef818 Author: Yumin Qi Date: 2022-02-04 19:20:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8e4ef818a90de35ae75e7f82a780653d623bb29c 8280767: -XX:ArchiveClassesAtExit does not archive BoundMethodHandle$Species classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/lambdaFormInvokers.cpp ! src/hotspot/share/cds/lambdaFormInvokers.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvm.cpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestLambdaInvokers.java Changeset: 48523b09 Author: Kevin Walls Date: 2022-02-04 21:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48523b090886f7b24ed4009f0c150efaa6f7b056 8281049: man page update for jstatd Security Manager dependency removal Reviewed-by: cjplummer ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 42e272e1 Author: Xue-Lei Andrew Fan Date: 2022-02-05 07:44:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42e272e181f188c89fa88f144715f19235943fca 8281289: Improve with List.copyOf Reviewed-by: jnimeh, hchao ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: 77b0240d Author: Joe Darcy Date: 2022-02-06 02:19:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77b0240d44fd356711d75bc241e198f6f89ada8f 8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: f7814c12 Author: Toshio Nakamura Committer: Phil Race Date: 2022-02-06 18:39:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7814c120bf84d7e9b459f81a6ce19b44fa122ec 8139173: [macosx] JInternalFrame shadow is not properly drawn Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java + test/jdk/javax/swing/plaf/aqua/JInternalFrameBorderTest.java Changeset: 2f48a3f0 Author: Phil Race Date: 2022-02-06 21:13:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f48a3f032dcfe159a7ab4a3d0afd0a0760d0a04 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on Ubuntu 21.10 Reviewed-by: serb ! test/jdk/java/awt/font/JNICheck/JNICheck.sh Changeset: 5dfff740 Author: Prasanta Sadhukhan Date: 2022-02-07 04:48:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5dfff7406ef3dc37a77ce9545f6f56c49b41e466 8166050: partialArray is not created in javax.swing.text.html.parser.NPrintWriter.println(...) method Reviewed-by: prr ! src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java Changeset: f2302822 Author: Xue-Lei Andrew Fan Date: 2022-02-07 06:30:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2302822c0ef30fbf7cb4e31b8dc1513e9413a23 8281298: Revise the creation of unmodifiable list Reviewed-by: redestad ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: f5e08700 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-07 08:18:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5e0870091ad9534e7a3dd08ef2e3ee7cd781c6d 8281117: Add regression test for JDK-8280587 Reviewed-by: chagedorn, thartmann, xliu + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead2.java Changeset: 95fd9d20 Author: Alex Menkov Date: 2022-02-07 09:08:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95fd9d20f329b15d68e613ec7f932254715e9130 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing Reviewed-by: sspitsyn, dcubed, lmesnik ! test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java Changeset: f3e82426 Author: Julia Boes Date: 2022-02-07 09:28:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3e8242683f6c729d89e2f49b0977889b4786f4a 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 Reviewed-by: dfuchs ! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java Changeset: 4c169495 Author: Aleksei Efimov Date: 2022-02-07 12:10:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c169495a2c4bfdcbc82e94e9ca1ee0cc050daf9 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled Reviewed-by: dfuchs ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java Changeset: 76677716 Author: Albert Mingkun Yang Date: 2022-02-07 12:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76677716abf1124992c8f5d4d5b159b1ec0f3cab 8281114: G1: Remove PreservedMarks::init_forwarded_mark Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 22a1a32c Author: Stephanie Crater Committer: Thomas Schatzl Date: 2022-02-07 12:43:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22a1a32c7e5ceb7be6725f5369dcfc2a11fecc2f 8268387: Rename maximum compaction to maximal compaction in G1 Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullCollector.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.cpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: a0f6f240 Author: Sean Mullan Date: 2022-02-07 14:06:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0f6f2409ea61ff9ed9dc2e2b46e309c751d456d 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR Reviewed-by: weijun, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + test/jdk/java/security/SignedJar/CustomClassLoader.java + test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java Changeset: 2ed1f4cf Author: Weijun Wang Date: 2022-02-07 15:05:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ed1f4cf32b1cef4ccb129d622f9368c3469d1d4 8281175: Add a -providerPath option to jarsigner Reviewed-by: xuelei, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java ! test/jdk/sun/security/tools/jarsigner/AltProvider.java Changeset: 1dfc94dd Author: Kevin Walls Date: 2022-02-07 17:36:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1dfc94dd561f6a91ef3784fe28c83f839f8188c4 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. Reviewed-by: sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 8a662105 Author: Kevin Walls Date: 2022-02-07 18:16:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a662105c2da1f0fb9b7ecc5058fc85858439ed9 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java Reviewed-by: cjplummer, dfuchs ! test/jdk/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java Changeset: 2f71a6b3 Author: Erik Gahlin Date: 2022-02-07 19:54:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff 8279613: JFR: Snippify Javadoc Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/AnnotationElement.java ! src/jdk.jfr/share/classes/jdk/jfr/Event.java ! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java ! src/jdk.jfr/share/classes/jdk/jfr/EventSettings.java ! src/jdk.jfr/share/classes/jdk/jfr/FlightRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/MetadataDefinition.java ! src/jdk.jfr/share/classes/jdk/jfr/Recording.java ! src/jdk.jfr/share/classes/jdk/jfr/SettingControl.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/EventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/package-info.java + src/jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files/Snippets.java + src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 4eacacb5 Author: Aleksey Shipilev Date: 2022-02-08 07:19:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eacacb5ad61020c11a521111c40af9fa72e2ff5 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages multipliers Reviewed-by: stuefe, coleenp, xliu ! src/hotspot/share/runtime/stackOverflow.cpp Changeset: f2a9627c Author: Masanori Yano Committer: Alan Bateman Date: 2022-02-08 08:31:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2a9627c05f9ef82eb83d8c1b9d4209bf42e7d8d 8279329: Remove hardcoded IPv4 available policy on Windows Reviewed-by: djelinski, alanb, dfuchs, aefimov ! src/java.base/windows/native/libnet/net_util_md.c Changeset: 861f2797 Author: Kim Barrett Date: 2022-02-08 09:02:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/861f2797f7d56ab185117f27dae2660af9250f6a 8280917: Simplify G1ConcurrentRefineThread activation Reviewed-by: iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: f5d8cebb Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-08 12:39:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d8cebbb6f1b38247c3b30ba8859874a0e98115 8281296: Create a regression test for JDK-4515999 Reviewed-by: aivanov + test/jdk/javax/swing/JSpinner/4515999/JSpinnerMouseAndKeyPressTest.java Changeset: 83d67452 Author: Thomas Stuefe Date: 2022-02-08 14:43:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83d67452da248db17bc72de80247a670d6813cf5 8281450: Remove unnecessary operator new and delete from ObjectMonitor Reviewed-by: dholmes ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 380378c5 Author: Harold Seigel Date: 2022-02-08 16:00:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/380378c551b4243ef72d868571f725b390e12124 8281400: Remove unused wcslen() function Reviewed-by: dcubed, coleenp, lfoltan ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: 7f19c700 Author: Martin Doerr Date: 2022-02-08 17:48:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f19c700707573000a37910dd6d2f2bb6e8439ad 8281061: [s390] JFR runs into assertions while validating interpreter frames Reviewed-by: lucy, rrich ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: 92f4f40d Author: Christian Stein Committer: Lance Andersen Date: 2022-02-08 17:53:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92f4f40da6c4ff55c7ed334007c9c6ca0dc15d99 8281104: jar --create should create missing parent directories Reviewed-by: lancea ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties + test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: 5fb56dbb Author: Daniel D. Daugherty Date: 2022-02-08 20:16:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5fb56dbb0b4e3345ca6f48ba9c01bd467f04aa6f 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java Reviewed-by: azvegint, bpb, lancea ! test/jdk/ProblemList.txt Changeset: d658d945 Author: Kim Barrett Date: 2022-02-08 20:29:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d658d945cf57bab8e61302841dcb56b36e48eff3 8280828: Improve invariants in NonblockingQueue::append Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: fb17a8ec Author: Quan Anh Mai Committer: Jie Fu Date: 2022-02-08 23:38:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb17a8ece0a3593c51a8be60533916bf70778a93 8278947: Support for array constants in constant table Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/opto/constantTable.cpp ! src/hotspot/share/opto/constantTable.hpp Changeset: 2f46af05 Author: Sergey Bylokhov Date: 2022-02-09 01:26:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f46af05ce2d43e19e0095680eb3a52fd904c774 8280132: Incorrect comparator com.sun.beans.introspect.MethodInfo.MethodOrder Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java ! test/jdk/java/beans/Introspector/MethodOrderException.java Changeset: 13f739d3 Author: Kim Barrett Date: 2022-02-09 04:10:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13f739d330e393f840d134f5327a025957e1f795 8280830: Change NonblockingQueue::try_pop variable named "result" Reviewed-by: dholmes ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: bce5dd17 Author: Kim Barrett Date: 2022-02-09 04:38:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bce5dd17665d1cdf2901690ca54f84ec200560af 8280438: Improve BufferNode::Allocator::release to avoid walking pending list Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp Changeset: fc772178 Author: Aleksey Shipilev Date: 2022-02-09 06:28:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc77217814eb1a346d7380299abdc2b01a69b4de 8281168: Micro-optimize VarForm.getMemberName for interpreter Reviewed-by: redestad, vlivanov, mchung ! src/java.base/share/classes/java/lang/invoke/VarForm.java Changeset: cb2f8cae Author: Artem Semenov Date: 2022-02-09 06:50:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb2f8caed2de1bf0a85a7ebfd232c36371e06c98 8281338: NSAccessibilityPressAction action for tree node and NSAccessibilityShowMenuAcgtion action not working Reviewed-by: ant, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m + test/jdk/java/awt/a11y/AccessibleActionsTest.java Changeset: 072e7b4d Author: Kim Barrett Date: 2022-02-09 06:53:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c 8272807: Permit use of memory concurrent with pretouch Reviewed-by: shade, stuefe ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: f924e50c Author: Daniel Jeli?ski Committer: Alexey Ivanov Date: 2022-02-09 08:34:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f924e50c42c2f9548d2983449a98c45af40b0d35 8281440: AWT: Conversion from string literal loses const qualifier Reviewed-by: prr, aivanov ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DesktopProperties.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DrawingSurface.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp Changeset: f092baba Author: Alexey Pavlyutkin Committer: Aleksey Shipilev Date: 2022-02-09 09:33:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f092babafb58563a4044463e157e02c397d8c9bc 8281195: Mistakenly used logging causes significant overhead in interpreter Reviewed-by: shade, dholmes ! src/hotspot/share/interpreter/oopMapCache.cpp Changeset: 69e390a0 Author: Roland Westrelin Date: 2022-02-09 10:18:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69e390a0e86f82eaa7bcdbc3ef509734dbe3b22f 8262721: Add Tests to verify single iteration loops are properly optimized Reviewed-by: neliasso, chagedorn, kvn + test/hotspot/jtreg/compiler/c2/irTests/TestFewIterationsCountedLoop.java Changeset: bb2e10cc Author: Matthias Baesken Date: 2022-02-09 11:33:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb2e10ccea0c0b89b06ace034c99253e9999ec47 8281274: deal with ActiveProcessorCount in os::Linux::print_container_info Reviewed-by: stuefe, sgehwolf, dholmes, iklam ! src/hotspot/os/linux/os_linux.cpp ! test/hotspot/jtreg/containers/docker/TestMisc.java Changeset: 8b384b98 Author: Christian Stein Committer: Lance Andersen Date: 2022-02-09 11:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b384b986a0a6a972c29a2f7a4d9fd40dc479b48 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" Reviewed-by: lancea ! test/jdk/ProblemList.txt ! test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: f823bed0 Author: Bhavana Kilambi Committer: Paul Hohensee Date: 2022-02-09 13:18:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f823bed043dc38d838baaf8c2024ef24b8a50e9b 8280007: Enable Neoverse N1 optimizations for Arm Neoverse V1 & N2 Reviewed-by: phh ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp Changeset: c5c8c064 Author: Vladimir Ivanov Date: 2022-02-09 13:56:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5c8c0644d9442846de15422285fffeb91c3e0a1 8279822: CI: Constant pool entries in error state are not supported Reviewed-by: kvn, thartmann ! src/hotspot/share/ci/bcEscapeAnalyzer.cpp ! src/hotspot/share/ci/ciConstant.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciStreams.hpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/utilities/constantTag.hpp + test/hotspot/jtreg/compiler/runtime/TestConstantsInError.java Changeset: 178b962e Author: Hai-May Chao Date: 2022-02-09 16:53:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/178b962e01cc6c150442bf41dc6bd199caff0042 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty Reviewed-by: weijun ! src/java.base/share/classes/sun/security/provider/DomainKeyStore.java + test/jdk/sun/security/provider/KeyStore/DksWithEmptyKeystore.java Changeset: fd8a3dcc Author: Alexey Ivanov Date: 2022-02-09 19:12:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd8a3dcc52dc5d6b62edd83eacef5934f6294e80 8280820: Clean up bug8033699 and bug8075609.java tests: regtesthelpers aren't used Reviewed-by: prr ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java ! test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java Changeset: 7218d844 Author: John Jiang Date: 2022-02-10 08:11:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7218d8449bfaa3f121b66088a88a194f77f06753 8281567: Remove @throws IOException from X509CRLImpl::getExtension docs Reviewed-by: xuelei, jiefu ! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java Changeset: fa0a72c0 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-10 09:29:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa0a72c030432f9ea4ad9913a2bb4096324410aa 8252496: C2: Useless code in MergeMemNode::Ideal Reviewed-by: thartmann, chagedorn, vlivanov ! src/hotspot/share/opto/memnode.cpp Changeset: c820d1ac Author: Leo Korinth Date: 2022-02-10 10:34:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c820d1acb7c6e600a890e4205eef0be8a4c7a791 8281379: Assign package declarations to all jtreg test cases under gc Reviewed-by: kbarrett, tschatzl ! test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java ! test/hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java ! test/hotspot/jtreg/gc/z/TestGarbageCollectorMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryManagerMXBean.java Changeset: d442328b Author: Maxim Kartashev Committer: Magnus Ihse Bursie Date: 2022-02-10 10:46:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d442328bc2f2f4bc35dd054487a78552e3d9a759 8281262: Windows builds in different directories are not fully reproducible Co-authored-by: Erik Joelsson Reviewed-by: erikj, ihse ! make/TestImage.gmk ! make/autoconf/flags-cflags.m4 ! test/jdk/build/AbsPathsInImage.java Changeset: 3ce1c5b6 Author: Kim Barrett Date: 2022-02-10 11:28:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3ce1c5b6ce02749ef8f9d35409b7bcbf27f47203 8280832: Update usage docs for NonblockingQueue Reviewed-by: iwalulya, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 039313d6 Author: Prasanta Sadhukhan Date: 2022-02-10 12:02:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/039313d65d47dc85cb8c91d3e1d2752d365f70f9 8054449: Incompatible type in example code in TreePath Reviewed-by: aivanov, dmarkov ! src/java.desktop/share/classes/javax/swing/tree/TreePath.java Changeset: 83b6e4bc Author: Paul Sandoz Date: 2022-02-10 18:37:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83b6e4bc04db89a846a1b6c2d0666efe139f8f61 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors Reviewed-by: jrose ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Max-op.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Min-op.template + test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-op-func.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template Changeset: 58c2bd31 Author: Erik Gahlin Date: 2022-02-10 22:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58c2bd315836b9c4fbffa212497fd84c8f589c17 8281536: JFR: Improve jdk.jfr.ContentType documentation Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/ContentType.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 84868e39 Author: David Holmes Date: 2022-02-10 23:23:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/84868e39be4522ba87e603beea0f8da9efa43b6d 8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath separator in gc paths Reviewed-by: shade, dcubed ! src/hotspot/share/logging/logConfiguration.cpp ! test/hotspot/gtest/logging/test_logConfiguration.cpp Changeset: eee6a562 Author: Thomas Stuefe Date: 2022-02-11 05:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eee6a5622dca683d4d6a701daa48e09e8d17b54e 8281522: Rename ADLC classes which have the same name as hotspot variants Reviewed-by: neliasso, kvn + src/hotspot/share/adlc/adlArena.cpp + src/hotspot/share/adlc/adlArena.hpp ! src/hotspot/share/adlc/adlc.hpp ! src/hotspot/share/adlc/adlparse.cpp - src/hotspot/share/adlc/arena.cpp - src/hotspot/share/adlc/arena.hpp ! src/hotspot/share/adlc/dfa.cpp ! src/hotspot/share/adlc/dict2.cpp ! src/hotspot/share/adlc/dict2.hpp ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/forms.hpp ! src/hotspot/share/adlc/formsopt.cpp ! src/hotspot/share/adlc/formssel.cpp Changeset: 65831eb2 Author: Aleksey Shipilev Date: 2022-02-11 06:45:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65831eb294b6f1f5f99988836c00005d41c27fd3 8281318: Improve jfr/event/allocation tests reliability Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationInNewTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationOutsideTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventThrottling.java Changeset: a037b3c3 Author: Thomas Stuefe Date: 2022-02-11 07:21:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a037b3c35831f029d23a88bdd49e7f2c2d951631 8281460: Let ObjectMonitor have its own NMT category Reviewed-by: dholmes, dcubed, shade ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 8441d51e Author: Sergey Bylokhov Date: 2022-02-11 07:41:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8441d51e71e143250b44eea74114a624cf00cc3e 8281419: The source data for the color conversion can be discarded Reviewed-by: prr, aivanov ! src/java.desktop/share/native/liblcms/LCMS.c Changeset: 3a13425b Author: Aleksey Shipilev Date: 2022-02-11 08:46:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3a13425bc9088cbb6d95e1a46248d7eba27fb1a6 8072070: Improve interpreter stack banging Reviewed-by: xliu, coleenp, mdoerr ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/stackOverflow.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 90939cb8 Author: Kim Barrett Date: 2022-02-11 09:05:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90939cb80193c671cae635b7a4e41bd2e6bcdbd5 8281626: NonblockingQueue should use nullptr Reviewed-by: shade, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 4d640760 Author: Prasanta Sadhukhan Date: 2022-02-11 09:39:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d64076058a4ec5df101b06572195ed5fdee6f64 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect Reviewed-by: aivanov ! src/java.desktop/share/classes/javax/swing/plaf/TreeUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: 2d985cd7 Author: duke Date: 2022-02-11 11:00:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d985cd71ed870ed87329888fa389860153694d7 Automatic merge of jdk:master into master Changeset: 8230a7f6 Author: duke Date: 2022-02-11 11:01:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8230a7f60de38ffc50a8460a9e891b539084cdd8 Automatic merge of master into foreign-memaccess+abi ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.cpp Changeset: da4b3c8e Author: duke Date: 2022-02-11 11:01:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da4b3c8ef6a5e8751861b4d6114aaffade2292d1 Automatic merge of foreign-memaccess+abi into foreign-jextract From duke at openjdk.java.net Fri Feb 11 11:20:44 2022 From: duke at openjdk.java.net (duke) Date: Fri, 11 Feb 2022 11:20:44 GMT Subject: git: openjdk/panama-foreign: foreign-preview: 69 new changesets Message-ID: Changeset: 3d926dd6 Author: Rob McKenna Date: 2022-02-04 13:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a 8277795: ldap connection timeout not honoured under contention Reviewed-by: dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java + test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java Changeset: 01f93ddf Author: Matthias Baesken Date: 2022-02-04 07:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01f93ddf18daea5c0798ac949c6717c37d9cefa0 8279385: [test] Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344 Reviewed-by: mullan, xuelei Backport-of: 9bdf6eb7b2412ecff523015f1430dfb6a0e4dd09 ! test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java Changeset: 7207f2a3 Author: Jesper Wilhelmsson Date: 2022-02-04 14:47:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7207f2a3b59c684d9d51d378257629729fa7041d Merge Changeset: 66b2c3b6 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-04 15:25:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66b2c3b66e253ac3d8718c0c6d7c7551dbe04001 8280948: [TESTBUG] Write a regression test for JDK-4659800 Reviewed-by: aivanov + test/jdk/javax/swing/JButton/4659800/EnterKeyActivatesButton.java Changeset: d4b99bc0 Author: Albert Mingkun Yang Date: 2022-02-04 16:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4b99bc029771d29c2119a9b5f381cae3fe21ec1 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to update_for_block Reviewed-by: tschatzl, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: f5d6fddc Author: Daniel D. Daugherty Date: 2022-02-04 17:37:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d6fddc6df8c5c5456a2544b131833d5227292b 8280476: [macOS] : hotspot arm64 bug exposed by latest clang Reviewed-by: kbarrett, adinn ! src/hotspot/cpu/aarch64/immediate_aarch64.cpp Changeset: 8e4ef818 Author: Yumin Qi Date: 2022-02-04 19:20:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8e4ef818a90de35ae75e7f82a780653d623bb29c 8280767: -XX:ArchiveClassesAtExit does not archive BoundMethodHandle$Species classes Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/lambdaFormInvokers.cpp ! src/hotspot/share/cds/lambdaFormInvokers.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvm.cpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestLambdaInvokers.java Changeset: 48523b09 Author: Kevin Walls Date: 2022-02-04 21:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48523b090886f7b24ed4009f0c150efaa6f7b056 8281049: man page update for jstatd Security Manager dependency removal Reviewed-by: cjplummer ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 42e272e1 Author: Xue-Lei Andrew Fan Date: 2022-02-05 07:44:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42e272e181f188c89fa88f144715f19235943fca 8281289: Improve with List.copyOf Reviewed-by: jnimeh, hchao ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: 77b0240d Author: Joe Darcy Date: 2022-02-06 02:19:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77b0240d44fd356711d75bc241e198f6f89ada8f 8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java Changeset: f7814c12 Author: Toshio Nakamura Committer: Phil Race Date: 2022-02-06 18:39:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7814c120bf84d7e9b459f81a6ce19b44fa122ec 8139173: [macosx] JInternalFrame shadow is not properly drawn Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java + test/jdk/javax/swing/plaf/aqua/JInternalFrameBorderTest.java Changeset: 2f48a3f0 Author: Phil Race Date: 2022-02-06 21:13:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f48a3f032dcfe159a7ab4a3d0afd0a0760d0a04 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on Ubuntu 21.10 Reviewed-by: serb ! test/jdk/java/awt/font/JNICheck/JNICheck.sh Changeset: 5dfff740 Author: Prasanta Sadhukhan Date: 2022-02-07 04:48:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5dfff7406ef3dc37a77ce9545f6f56c49b41e466 8166050: partialArray is not created in javax.swing.text.html.parser.NPrintWriter.println(...) method Reviewed-by: prr ! src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java Changeset: f2302822 Author: Xue-Lei Andrew Fan Date: 2022-02-07 06:30:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2302822c0ef30fbf7cb4e31b8dc1513e9413a23 8281298: Revise the creation of unmodifiable list Reviewed-by: redestad ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: f5e08700 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-07 08:18:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5e0870091ad9534e7a3dd08ef2e3ee7cd781c6d 8281117: Add regression test for JDK-8280587 Reviewed-by: chagedorn, thartmann, xliu + test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead2.java Changeset: 95fd9d20 Author: Alex Menkov Date: 2022-02-07 09:08:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95fd9d20f329b15d68e613ec7f932254715e9130 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing Reviewed-by: sspitsyn, dcubed, lmesnik ! test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java Changeset: f3e82426 Author: Julia Boes Date: 2022-02-07 09:28:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3e8242683f6c729d89e2f49b0977889b4786f4a 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 Reviewed-by: dfuchs ! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java Changeset: 4c169495 Author: Aleksei Efimov Date: 2022-02-07 12:10:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c169495a2c4bfdcbc82e94e9ca1ee0cc050daf9 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled Reviewed-by: dfuchs ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java Changeset: 76677716 Author: Albert Mingkun Yang Date: 2022-02-07 12:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76677716abf1124992c8f5d4d5b159b1ec0f3cab 8281114: G1: Remove PreservedMarks::init_forwarded_mark Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/shared/preservedMarks.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp Changeset: 22a1a32c Author: Stephanie Crater Committer: Thomas Schatzl Date: 2022-02-07 12:43:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22a1a32c7e5ceb7be6725f5369dcfc2a11fecc2f 8268387: Rename maximum compaction to maximal compaction in G1 Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullCollector.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.cpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: a0f6f240 Author: Sean Mullan Date: 2022-02-07 14:06:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0f6f2409ea61ff9ed9dc2e2b46e309c751d456d 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR Reviewed-by: weijun, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + test/jdk/java/security/SignedJar/CustomClassLoader.java + test/jdk/java/security/SignedJar/SignedJarWithCustomClassLoader.java Changeset: 2ed1f4cf Author: Weijun Wang Date: 2022-02-07 15:05:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ed1f4cf32b1cef4ccb129d622f9368c3469d1d4 8281175: Add a -providerPath option to jarsigner Reviewed-by: xuelei, hchao ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java ! test/jdk/sun/security/tools/jarsigner/AltProvider.java Changeset: 1dfc94dd Author: Kevin Walls Date: 2022-02-07 17:36:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1dfc94dd561f6a91ef3784fe28c83f839f8188c4 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. Reviewed-by: sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 8a662105 Author: Kevin Walls Date: 2022-02-07 18:16:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a662105c2da1f0fb9b7ecc5058fc85858439ed9 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java Reviewed-by: cjplummer, dfuchs ! test/jdk/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java Changeset: 2f71a6b3 Author: Erik Gahlin Date: 2022-02-07 19:54:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff 8279613: JFR: Snippify Javadoc Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/AnnotationElement.java ! src/jdk.jfr/share/classes/jdk/jfr/Event.java ! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java ! src/jdk.jfr/share/classes/jdk/jfr/EventSettings.java ! src/jdk.jfr/share/classes/jdk/jfr/FlightRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/MetadataDefinition.java ! src/jdk.jfr/share/classes/jdk/jfr/Recording.java ! src/jdk.jfr/share/classes/jdk/jfr/SettingControl.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/EventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/package-info.java + src/jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files/Snippets.java + src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 4eacacb5 Author: Aleksey Shipilev Date: 2022-02-08 07:19:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eacacb5ad61020c11a521111c40af9fa72e2ff5 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages multipliers Reviewed-by: stuefe, coleenp, xliu ! src/hotspot/share/runtime/stackOverflow.cpp Changeset: f2a9627c Author: Masanori Yano Committer: Alan Bateman Date: 2022-02-08 08:31:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2a9627c05f9ef82eb83d8c1b9d4209bf42e7d8d 8279329: Remove hardcoded IPv4 available policy on Windows Reviewed-by: djelinski, alanb, dfuchs, aefimov ! src/java.base/windows/native/libnet/net_util_md.c Changeset: 861f2797 Author: Kim Barrett Date: 2022-02-08 09:02:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/861f2797f7d56ab185117f27dae2660af9250f6a 8280917: Simplify G1ConcurrentRefineThread activation Reviewed-by: iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp Changeset: f5d8cebb Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-08 12:39:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5d8cebbb6f1b38247c3b30ba8859874a0e98115 8281296: Create a regression test for JDK-4515999 Reviewed-by: aivanov + test/jdk/javax/swing/JSpinner/4515999/JSpinnerMouseAndKeyPressTest.java Changeset: 83d67452 Author: Thomas Stuefe Date: 2022-02-08 14:43:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83d67452da248db17bc72de80247a670d6813cf5 8281450: Remove unnecessary operator new and delete from ObjectMonitor Reviewed-by: dholmes ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 380378c5 Author: Harold Seigel Date: 2022-02-08 16:00:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/380378c551b4243ef72d868571f725b390e12124 8281400: Remove unused wcslen() function Reviewed-by: dcubed, coleenp, lfoltan ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: 7f19c700 Author: Martin Doerr Date: 2022-02-08 17:48:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f19c700707573000a37910dd6d2f2bb6e8439ad 8281061: [s390] JFR runs into assertions while validating interpreter frames Reviewed-by: lucy, rrich ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: 92f4f40d Author: Christian Stein Committer: Lance Andersen Date: 2022-02-08 17:53:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92f4f40da6c4ff55c7ed334007c9c6ca0dc15d99 8281104: jar --create should create missing parent directories Reviewed-by: lancea ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties + test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: 5fb56dbb Author: Daniel D. Daugherty Date: 2022-02-08 20:16:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5fb56dbb0b4e3345ca6f48ba9c01bd467f04aa6f 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java Reviewed-by: azvegint, bpb, lancea ! test/jdk/ProblemList.txt Changeset: d658d945 Author: Kim Barrett Date: 2022-02-08 20:29:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d658d945cf57bab8e61302841dcb56b36e48eff3 8280828: Improve invariants in NonblockingQueue::append Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: fb17a8ec Author: Quan Anh Mai Committer: Jie Fu Date: 2022-02-08 23:38:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb17a8ece0a3593c51a8be60533916bf70778a93 8278947: Support for array constants in constant table Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/opto/constantTable.cpp ! src/hotspot/share/opto/constantTable.hpp Changeset: 2f46af05 Author: Sergey Bylokhov Date: 2022-02-09 01:26:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f46af05ce2d43e19e0095680eb3a52fd904c774 8280132: Incorrect comparator com.sun.beans.introspect.MethodInfo.MethodOrder Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/beans/introspect/MethodInfo.java ! test/jdk/java/beans/Introspector/MethodOrderException.java Changeset: 13f739d3 Author: Kim Barrett Date: 2022-02-09 04:10:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13f739d330e393f840d134f5327a025957e1f795 8280830: Change NonblockingQueue::try_pop variable named "result" Reviewed-by: dholmes ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: bce5dd17 Author: Kim Barrett Date: 2022-02-09 04:38:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bce5dd17665d1cdf2901690ca54f84ec200560af 8280438: Improve BufferNode::Allocator::release to avoid walking pending list Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp Changeset: fc772178 Author: Aleksey Shipilev Date: 2022-02-09 06:28:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc77217814eb1a346d7380299abdc2b01a69b4de 8281168: Micro-optimize VarForm.getMemberName for interpreter Reviewed-by: redestad, vlivanov, mchung ! src/java.base/share/classes/java/lang/invoke/VarForm.java Changeset: cb2f8cae Author: Artem Semenov Date: 2022-02-09 06:50:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb2f8caed2de1bf0a85a7ebfd232c36371e06c98 8281338: NSAccessibilityPressAction action for tree node and NSAccessibilityShowMenuAcgtion action not working Reviewed-by: ant, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m + test/jdk/java/awt/a11y/AccessibleActionsTest.java Changeset: 072e7b4d Author: Kim Barrett Date: 2022-02-09 06:53:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c 8272807: Permit use of memory concurrent with pretouch Reviewed-by: shade, stuefe ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: f924e50c Author: Daniel Jeli?ski Committer: Alexey Ivanov Date: 2022-02-09 08:34:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f924e50c42c2f9548d2983449a98c45af40b0d35 8281440: AWT: Conversion from string literal loses const qualifier Reviewed-by: prr, aivanov ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DesktopProperties.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DrawingSurface.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Font.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp Changeset: f092baba Author: Alexey Pavlyutkin Committer: Aleksey Shipilev Date: 2022-02-09 09:33:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f092babafb58563a4044463e157e02c397d8c9bc 8281195: Mistakenly used logging causes significant overhead in interpreter Reviewed-by: shade, dholmes ! src/hotspot/share/interpreter/oopMapCache.cpp Changeset: 69e390a0 Author: Roland Westrelin Date: 2022-02-09 10:18:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69e390a0e86f82eaa7bcdbc3ef509734dbe3b22f 8262721: Add Tests to verify single iteration loops are properly optimized Reviewed-by: neliasso, chagedorn, kvn + test/hotspot/jtreg/compiler/c2/irTests/TestFewIterationsCountedLoop.java Changeset: bb2e10cc Author: Matthias Baesken Date: 2022-02-09 11:33:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb2e10ccea0c0b89b06ace034c99253e9999ec47 8281274: deal with ActiveProcessorCount in os::Linux::print_container_info Reviewed-by: stuefe, sgehwolf, dholmes, iklam ! src/hotspot/os/linux/os_linux.cpp ! test/hotspot/jtreg/containers/docker/TestMisc.java Changeset: 8b384b98 Author: Christian Stein Committer: Lance Andersen Date: 2022-02-09 11:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b384b986a0a6a972c29a2f7a4d9fd40dc479b48 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" Reviewed-by: lancea ! test/jdk/ProblemList.txt ! test/jdk/tools/jar/CreateMissingParentDirectories.java Changeset: f823bed0 Author: Bhavana Kilambi Committer: Paul Hohensee Date: 2022-02-09 13:18:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f823bed043dc38d838baaf8c2024ef24b8a50e9b 8280007: Enable Neoverse N1 optimizations for Arm Neoverse V1 & N2 Reviewed-by: phh ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp Changeset: c5c8c064 Author: Vladimir Ivanov Date: 2022-02-09 13:56:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5c8c0644d9442846de15422285fffeb91c3e0a1 8279822: CI: Constant pool entries in error state are not supported Reviewed-by: kvn, thartmann ! src/hotspot/share/ci/bcEscapeAnalyzer.cpp ! src/hotspot/share/ci/ciConstant.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciStreams.hpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/utilities/constantTag.hpp + test/hotspot/jtreg/compiler/runtime/TestConstantsInError.java Changeset: 178b962e Author: Hai-May Chao Date: 2022-02-09 16:53:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/178b962e01cc6c150442bf41dc6bd199caff0042 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty Reviewed-by: weijun ! src/java.base/share/classes/sun/security/provider/DomainKeyStore.java + test/jdk/sun/security/provider/KeyStore/DksWithEmptyKeystore.java Changeset: fd8a3dcc Author: Alexey Ivanov Date: 2022-02-09 19:12:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd8a3dcc52dc5d6b62edd83eacef5934f6294e80 8280820: Clean up bug8033699 and bug8075609.java tests: regtesthelpers aren't used Reviewed-by: prr ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java ! test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java Changeset: 7218d844 Author: John Jiang Date: 2022-02-10 08:11:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7218d8449bfaa3f121b66088a88a194f77f06753 8281567: Remove @throws IOException from X509CRLImpl::getExtension docs Reviewed-by: xuelei, jiefu ! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java Changeset: fa0a72c0 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-10 09:29:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa0a72c030432f9ea4ad9913a2bb4096324410aa 8252496: C2: Useless code in MergeMemNode::Ideal Reviewed-by: thartmann, chagedorn, vlivanov ! src/hotspot/share/opto/memnode.cpp Changeset: c820d1ac Author: Leo Korinth Date: 2022-02-10 10:34:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c820d1acb7c6e600a890e4205eef0be8a4c7a791 8281379: Assign package declarations to all jtreg test cases under gc Reviewed-by: kbarrett, tschatzl ! test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java ! test/hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java ! test/hotspot/jtreg/gc/z/TestGarbageCollectorMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryMXBean.java ! test/hotspot/jtreg/gc/z/TestMemoryManagerMXBean.java Changeset: d442328b Author: Maxim Kartashev Committer: Magnus Ihse Bursie Date: 2022-02-10 10:46:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d442328bc2f2f4bc35dd054487a78552e3d9a759 8281262: Windows builds in different directories are not fully reproducible Co-authored-by: Erik Joelsson Reviewed-by: erikj, ihse ! make/TestImage.gmk ! make/autoconf/flags-cflags.m4 ! test/jdk/build/AbsPathsInImage.java Changeset: 3ce1c5b6 Author: Kim Barrett Date: 2022-02-10 11:28:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3ce1c5b6ce02749ef8f9d35409b7bcbf27f47203 8280832: Update usage docs for NonblockingQueue Reviewed-by: iwalulya, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 039313d6 Author: Prasanta Sadhukhan Date: 2022-02-10 12:02:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/039313d65d47dc85cb8c91d3e1d2752d365f70f9 8054449: Incompatible type in example code in TreePath Reviewed-by: aivanov, dmarkov ! src/java.desktop/share/classes/javax/swing/tree/TreePath.java Changeset: 83b6e4bc Author: Paul Sandoz Date: 2022-02-10 18:37:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83b6e4bc04db89a846a1b6c2d0666efe139f8f61 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors Reviewed-by: jrose ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Max-op.template - test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Min-op.template + test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-op-func.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Max-op.template - test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Min-op.template + test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-op-func.template = test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template Changeset: 58c2bd31 Author: Erik Gahlin Date: 2022-02-10 22:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58c2bd315836b9c4fbffa212497fd84c8f589c17 8281536: JFR: Improve jdk.jfr.ContentType documentation Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/ContentType.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: 84868e39 Author: David Holmes Date: 2022-02-10 23:23:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/84868e39be4522ba87e603beea0f8da9efa43b6d 8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath separator in gc paths Reviewed-by: shade, dcubed ! src/hotspot/share/logging/logConfiguration.cpp ! test/hotspot/gtest/logging/test_logConfiguration.cpp Changeset: eee6a562 Author: Thomas Stuefe Date: 2022-02-11 05:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eee6a5622dca683d4d6a701daa48e09e8d17b54e 8281522: Rename ADLC classes which have the same name as hotspot variants Reviewed-by: neliasso, kvn + src/hotspot/share/adlc/adlArena.cpp + src/hotspot/share/adlc/adlArena.hpp ! src/hotspot/share/adlc/adlc.hpp ! src/hotspot/share/adlc/adlparse.cpp - src/hotspot/share/adlc/arena.cpp - src/hotspot/share/adlc/arena.hpp ! src/hotspot/share/adlc/dfa.cpp ! src/hotspot/share/adlc/dict2.cpp ! src/hotspot/share/adlc/dict2.hpp ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/forms.hpp ! src/hotspot/share/adlc/formsopt.cpp ! src/hotspot/share/adlc/formssel.cpp Changeset: 65831eb2 Author: Aleksey Shipilev Date: 2022-02-11 06:45:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65831eb294b6f1f5f99988836c00005d41c27fd3 8281318: Improve jfr/event/allocation tests reliability Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationInNewTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationOutsideTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventThrottling.java Changeset: a037b3c3 Author: Thomas Stuefe Date: 2022-02-11 07:21:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a037b3c35831f029d23a88bdd49e7f2c2d951631 8281460: Let ObjectMonitor have its own NMT category Reviewed-by: dholmes, dcubed, shade ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 8441d51e Author: Sergey Bylokhov Date: 2022-02-11 07:41:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8441d51e71e143250b44eea74114a624cf00cc3e 8281419: The source data for the color conversion can be discarded Reviewed-by: prr, aivanov ! src/java.desktop/share/native/liblcms/LCMS.c Changeset: 3a13425b Author: Aleksey Shipilev Date: 2022-02-11 08:46:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3a13425bc9088cbb6d95e1a46248d7eba27fb1a6 8072070: Improve interpreter stack banging Reviewed-by: xliu, coleenp, mdoerr ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/stackOverflow.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 90939cb8 Author: Kim Barrett Date: 2022-02-11 09:05:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90939cb80193c671cae635b7a4e41bd2e6bcdbd5 8281626: NonblockingQueue should use nullptr Reviewed-by: shade, dholmes ! src/hotspot/share/utilities/nonblockingQueue.hpp ! src/hotspot/share/utilities/nonblockingQueue.inline.hpp Changeset: 4d640760 Author: Prasanta Sadhukhan Date: 2022-02-11 09:39:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d64076058a4ec5df101b06572195ed5fdee6f64 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect Reviewed-by: aivanov ! src/java.desktop/share/classes/javax/swing/plaf/TreeUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: 2d985cd7 Author: duke Date: 2022-02-11 11:00:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d985cd71ed870ed87329888fa389860153694d7 Automatic merge of jdk:master into master Changeset: 5d7925fb Author: duke Date: 2022-02-11 11:01:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5d7925fbf1cf27c2fb74ce659c8f51e244e14581 Automatic merge of master into foreign-preview ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/ci/ciEnv.cpp From maurizio.cimadamore at oracle.com Fri Feb 11 15:02:41 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Feb 2022 15:02:41 +0000 Subject: on scope accessors (Was Re: changes to the foreign preview API) In-Reply-To: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> References: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> Message-ID: On 01/02/2022 12:48, Maurizio Cimadamore wrote: > The other change we'd like to make is to remove the scope() > accessors from all the resources (MemorySegment, NativeSymbol, > VaList). This comes from a desire to make the API more principled: > only the owner of a scope/session should have the "right" to close > it. In fact, we have spent significant API estate (e.g. > ResourceScope::whileAlive) just from preventing random clients to > shut down scopes. We now believe a better approach would be to simply > make the scope associated e.g. with a memory segment inaccessible. In > other words, a resource scope/memory session becomes a _capability_: > it is up to the owner of the scope/session to decide who to share > that capability with. Once a client has a scope, it can close that > scope, but also affect the scope by registering cleanup actions, or > allocating on that scope. Conversely, if a client only has a segment, > there's no way for that client to affect the owning scope/session in > a meaninful (and possibly, harmful) way. Thinking some more on this, removing scope() accessor from segments can indeed be problematic (at least if not counterbalanced by any other API move), in at least three different ways: 1. it makes creating "dependent" segments harder (this is the issue reported by Michael in [1]); that is (morally) nested segments that should have same lifetime as some enclosing segment. 2. it makes it hard to reason about scope invariants: for instance, when setting an inner segment into an outer segment you might want to check that the scopes are compatible. 3. aside from "dependent" segment, it is sometimes helpful to create "copies" of existing segments, with same lifetime properties (this is something we encountered in VaList::copy). Without a scope accessor, none of the above operations is possible, unless the code performing the operation has a scope handy. While some ad-hoc solution could be possible for (1), I think the other problems are harder to address - and I find (2) particularly problematic. As previously discussed, one possible solution is to always pass a scope to abstractions that need to perform any of the above operations. But I fear this might be error prone, as it will likely result in code that looks like this: ``` StructFoo.create(MemorySegment.ofAddress(addr, 10, scope), scope); // note duplication of "scope" ``` Or we could, of course, leave everything as is - just rename the abstraction (from ResourceScope to MemorySession) and then keep a session accessor on MemorySegment, NativeSymbol and VaList, and give up on the desire to restrict access to the ResourceScope::close method. But, after exploring some alternatives, I think there is a simple solution which gives us what we want (e.g. defend against calls to close methods from "unprivileged" clients) w/o changing the API too much; the solution consists exposing an extra flag on MemorySession/ResourceScope which says whether the scope/session can be closed explicitly. If we have that, we are in a position to have MemorySegment::session (and other similar methods) just return a non-closeable _view_ of the session they are associated with. Of course this also means giving up to identity comparison and use equals() instead, but I think that's pretty straightforward. In addition to address our original problem, the new flag can also be used to denote sessions that cannot be closed, such as the global session, or implicit, GC-backed sessions. With this change, existing code should basically still compile and work as expected; the only thing disallowed being: ``` segment.session().close() ``` Here's a javadoc of the proposed changes: http://cr.openjdk.java.net/~mcimadamore/panama/session_preview/javadoc/java.base/java/lang/foreign/package-summary.html And here's a branch, should you want to look at code changes: https://github.com/mcimadamore/panama-foreign/commits/session_preview I plan to start a PR for this soon. Maurizio [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016164.html From maurizio.cimadamore at oracle.com Fri Feb 11 15:09:38 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Feb 2022 15:09:38 +0000 Subject: on scope accessors (Was Re: changes to the foreign preview API) In-Reply-To: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> References: <6141d0da-a27b-7541-210a-de9a8c22ca1d@oracle.com> Message-ID: <050fb2d7-9e08-7a60-4ce9-02aeb8060050@oracle.com> Resending with correct formatting/indentation. On 01/02/2022 12:48, Maurizio Cimadamore wrote: > The other change we'd like to make is to remove the scope() > > accessors from all the resources (MemorySegment, NativeSymbol, > > VaList). This comes from a desire to make the API more principled: > > only the owner of a scope/session should have the "right" to close > > it. In fact, we have spent significant API estate (e.g. > > ResourceScope::whileAlive) just from preventing random clients to > > shut down scopes. We now believe a better approach would be to simply > > make the scope associated e.g. with a memory segment inaccessible. > In > other words, a resource scope/memory session becomes a > _capability_: > it is up to the owner of the scope/session to decide > who to share > that capability with. Once a client has a scope, it can > close that > scope, but also affect the scope by registering cleanup > actions, or > allocating on that scope. Conversely, if a client only > has a segment, > there's no way for that client to affect the owning > scope/session in > a meaninful (and possibly, harmful) way. Thinking some more on this, removing scope() accessor from segments can indeed be problematic (at least if not counterbalanced by any other API move), in at least three different ways: 1. it makes creating "dependent" segments harder (this is the issue reported by Michael in [1]); that is (morally) nested segments that should have same lifetime as some enclosing segment. 2. it makes it hard to reason about scope invariants: for instance, when setting an inner segment into an outer segment you might want to check that the scopes are compatible. 3. aside from "dependent" segment, it is sometimes helpful to create "copies" of existing segments, with same lifetime properties (this is something we encountered in VaList::copy). Without a scope accessor, none of the above operations is possible, unless the code performing the operation has a scope handy. While some ad-hoc solution could be possible for (1), I think the other problems are harder to address - and I find (2) particularly problematic. As previously discussed, one possible solution is to always pass a scope to abstractions that need to perform any of the above operations. But I fear this might be error prone, as it will likely result in code that looks like this: ``` StructFoo.create(MemorySegment.ofAddress(addr, 10, scope), scope); // note duplication of "scope" ``` Or we could, of course, leave everything as is - just rename the abstraction (from ResourceScope to MemorySession) and then keep a session accessor on MemorySegment, NativeSymbol and VaList, and give up on the desire to restrict access to the ResourceScope::close method. But, after exploring some alternatives, I think there is a simple solution which gives us what we want (e.g. defend against calls to close methods from "unprivileged" clients) w/o changing the API too much; the solution consists exposing an extra flag on MemorySession/ResourceScope which says whether the scope/session can be closed explicitly. If we have that, we are in a position to have MemorySegment::session (and other similar methods) just return a non-closeable _view_ of the session they are associated with. Of course this also means giving up to identity comparison and use equals() instead, but I think that's pretty straightforward. In addition to address our original problem, the new flag can also be used to denote sessions that cannot be closed, such as the global session, or implicit, GC-backed sessions. With this change, existing code should basically still compile and work as expected; the only thing disallowed being: ``` segment.session().close() ``` Here's a javadoc of the proposed changes: http://cr.openjdk.java.net/~mcimadamore/panama/session_preview/javadoc/java.base/java/lang/foreign/package-summary.html And here's a branch, should you want to look at code changes: https://github.com/mcimadamore/panama-foreign/commits/session_preview I plan to start a PR for this soon. Maurizio [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016164.html From jvernee at openjdk.java.net Fri Feb 11 19:15:01 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 11 Feb 2022 19:15:01 GMT Subject: [foreign-preview] RFR: 8281595: ASM-ify scope acquire/release for down call parameters Message-ID: Hi, This patch rewrites the scope acquire/release logic that we do for downcalls inside ASM, in the generated specialized binding class. This also drops the fallback path we had for more than 5 scopes. The new code now always checks to see if every scope is unique. (I think that should be okay, but please let me know if otherwise). I've also added a benchmark by Maurizio to this patch, which was showing a failure to scalar replace some scoped arguments with the old MH logic (reason discussed in [JDK-8281387](https://bugs.openjdk.java.net/browse/JDK-8281387)). With the new ASM-based logic, there is no sign of allocations (other than some noise): Benchmark Mode Cnt Score Error Units PointerInvoke.panama_call_as_address avgt 30 13.181 ? 0.320 ns/op PointerInvoke.panama_call_as_address:?gc.alloc.rate avgt 30 0.043 ? 0.049 MB/sec PointerInvoke.panama_call_as_address:?gc.alloc.rate.norm avgt 30 0.001 ? 0.001 B/op PointerInvoke.panama_call_as_address:?gc.count avgt 30 ? 0 counts PointerInvoke.panama_call_as_long avgt 30 12.943 ? 0.287 ns/op PointerInvoke.panama_call_as_long:?gc.alloc.rate avgt 30 0.065 ? 0.054 MB/sec PointerInvoke.panama_call_as_long:?gc.alloc.rate.norm avgt 30 0.002 ? 0.001 B/op PointerInvoke.panama_call_as_long:?gc.count avgt 30 ? 0 counts PointerInvoke.panama_call_as_new_segment avgt 30 14.309 ? 0.177 ns/op PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate avgt 30 0.173 ? 0.144 MB/sec PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate.norm avgt 30 0.005 ? 0.004 B/op PointerInvoke.panama_call_as_new_segment:?gc.count avgt 30 ? 0 counts PointerInvoke.panama_call_as_segment avgt 30 13.273 ? 0.191 ns/op PointerInvoke.panama_call_as_segment:?gc.alloc.rate avgt 30 ? 10?? MB/sec PointerInvoke.panama_call_as_segment:?gc.alloc.rate.norm avgt 30 ? 10?? B/op PointerInvoke.panama_call_as_segment:?gc.count avgt 30 ? 0 counts Thanks, Jorn ------------- Commit messages: - Fix copyright year - Add PointerInvoke benchmark - ASM-ify downcall scope acquire/release Changes: https://git.openjdk.java.net/panama-foreign/pull/640/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=640&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281595 Stats: 420 lines in 5 files changed: 237 ins; 178 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/640.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/640/head:pull/640 PR: https://git.openjdk.java.net/panama-foreign/pull/640 From jbhateja at openjdk.java.net Tue Feb 15 10:13:44 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 15 Feb 2022 10:13:44 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 22:41:36 GMT, Smita Kamath wrote: > 8281562:[vectorapi] Add support for popcount operation src/hotspot/share/prims/vectorSupport.cpp line 487: > 485: case T_SHORT: // fall-through > 486: case T_INT: return Op_PopCountI; > 487: case T_LONG: return Op_PopCountL; default case missing, will cause compilation failure. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From sebastian.stenzel at gmail.com Tue Feb 15 11:41:47 2022 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 15 Feb 2022 12:41:47 +0100 Subject: jextract overwrites constants$0.java Message-ID: When running jextract multiple times for functions from different header files (but using the same --target-package), `constants$0` gets overwritten. Is there any way to change the name of the file? Or is it intended to extract each header to a different package, as jextract can not avoid namespace conflicts? From sundararajan.athijegannathan at oracle.com Tue Feb 15 11:59:13 2022 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 15 Feb 2022 11:59:13 +0000 Subject: jextract overwrites constants$0.java In-Reply-To: References: Message-ID: jextract was not designed to be used in that fashion. Either you can use different packages for different header files (each extracted by separate jextract session). Or you can introduce a new header that includes your original two headers and jextract your newly created header file. -Sundar ________________________________ From: panama-dev on behalf of Sebastian Stenzel Sent: 15 February 2022 17:11 To: panama-dev at openjdk.java.net Subject: jextract overwrites constants$0.java When running jextract multiple times for functions from different header files (but using the same --target-package), `constants$0` gets overwritten. Is there any way to change the name of the file? Or is it intended to extract each header to a different package, as jextract can not avoid namespace conflicts? From mcimadamore at openjdk.java.net Tue Feb 15 14:08:30 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Feb 2022 14:08:30 GMT Subject: [foreign-preview] RFR: 8281595: ASM-ify scope acquire/release for down call parameters In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 19:05:19 GMT, Jorn Vernee wrote: > Hi, > > This patch rewrites the scope acquire/release logic that we do for downcalls inside ASM, in the generated specialized binding class. This also drops the fallback path we had for more than 5 scopes. The new code now always checks to see if every scope is unique. (I think that should be okay, but please let me know if otherwise). > > I've also added a benchmark by Maurizio to this patch, which was showing a failure to scalar replace some scoped arguments with the old MH logic (reason discussed in [JDK-8281387](https://bugs.openjdk.java.net/browse/JDK-8281387)). With the new ASM-based logic, there is no sign of allocations (other than some noise): > > > Benchmark Mode Cnt Score Error Units > PointerInvoke.panama_call_as_address avgt 30 13.181 ? 0.320 ns/op > PointerInvoke.panama_call_as_address:?gc.alloc.rate avgt 30 0.043 ? 0.049 MB/sec > PointerInvoke.panama_call_as_address:?gc.alloc.rate.norm avgt 30 0.001 ? 0.001 B/op > PointerInvoke.panama_call_as_address:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_long avgt 30 12.943 ? 0.287 ns/op > PointerInvoke.panama_call_as_long:?gc.alloc.rate avgt 30 0.065 ? 0.054 MB/sec > PointerInvoke.panama_call_as_long:?gc.alloc.rate.norm avgt 30 0.002 ? 0.001 B/op > PointerInvoke.panama_call_as_long:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_new_segment avgt 30 14.309 ? 0.177 ns/op > PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate avgt 30 0.173 ? 0.144 MB/sec > PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate.norm avgt 30 0.005 ? 0.004 B/op > PointerInvoke.panama_call_as_new_segment:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_segment avgt 30 13.273 ? 0.191 ns/op > PointerInvoke.panama_call_as_segment:?gc.alloc.rate avgt 30 ? 10?? MB/sec > PointerInvoke.panama_call_as_segment:?gc.alloc.rate.norm avgt 30 ? 10?? B/op > PointerInvoke.panama_call_as_segment:?gc.count avgt 30 ? 0 counts > > > Thanks, > Jorn Looks good - one minor comment on the handling of the local variables associated with scopes. src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 486: > 484: > 485: private void emitReleaseScopes() { > 486: for (int scopeLocal : scopeSlots) { Isn't this emitting more code than required? E.g. if we pass 10 primitives, we will emit 10 scope checks at the end of the adapter? Granted, since all these locals contain "null", there's no correctness issue here - but it is odd to (i) have a local for a scope corresponding to a primitive type (even though we know we never need it) and have extra logic in the preamble/postamble because of it. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/640 From jvernee at openjdk.java.net Tue Feb 15 14:42:32 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Feb 2022 14:42:32 GMT Subject: [foreign-preview] RFR: 8281595: ASM-ify scope acquire/release for down call parameters In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 14:04:30 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> This patch rewrites the scope acquire/release logic that we do for downcalls inside ASM, in the generated specialized binding class. This also drops the fallback path we had for more than 5 scopes. The new code now always checks to see if every scope is unique. (I think that should be okay, but please let me know if otherwise). >> >> I've also added a benchmark by Maurizio to this patch, which was showing a failure to scalar replace some scoped arguments with the old MH logic (reason discussed in [JDK-8281387](https://bugs.openjdk.java.net/browse/JDK-8281387)). With the new ASM-based logic, there is no sign of allocations (other than some noise): >> >> >> Benchmark Mode Cnt Score Error Units >> PointerInvoke.panama_call_as_address avgt 30 13.181 ? 0.320 ns/op >> PointerInvoke.panama_call_as_address:?gc.alloc.rate avgt 30 0.043 ? 0.049 MB/sec >> PointerInvoke.panama_call_as_address:?gc.alloc.rate.norm avgt 30 0.001 ? 0.001 B/op >> PointerInvoke.panama_call_as_address:?gc.count avgt 30 ? 0 counts >> PointerInvoke.panama_call_as_long avgt 30 12.943 ? 0.287 ns/op >> PointerInvoke.panama_call_as_long:?gc.alloc.rate avgt 30 0.065 ? 0.054 MB/sec >> PointerInvoke.panama_call_as_long:?gc.alloc.rate.norm avgt 30 0.002 ? 0.001 B/op >> PointerInvoke.panama_call_as_long:?gc.count avgt 30 ? 0 counts >> PointerInvoke.panama_call_as_new_segment avgt 30 14.309 ? 0.177 ns/op >> PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate avgt 30 0.173 ? 0.144 MB/sec >> PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate.norm avgt 30 0.005 ? 0.004 B/op >> PointerInvoke.panama_call_as_new_segment:?gc.count avgt 30 ? 0 counts >> PointerInvoke.panama_call_as_segment avgt 30 13.273 ? 0.191 ns/op >> PointerInvoke.panama_call_as_segment:?gc.alloc.rate avgt 30 ? 10?? MB/sec >> PointerInvoke.panama_call_as_segment:?gc.alloc.rate.norm avgt 30 ? 10?? B/op >> PointerInvoke.panama_call_as_segment:?gc.count avgt 30 ? 0 counts >> >> >> Thanks, >> Jorn > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 486: > >> 484: >> 485: private void emitReleaseScopes() { >> 486: for (int scopeLocal : scopeSlots) { > > Isn't this emitting more code than required? E.g. if we pass 10 primitives, we will emit 10 scope checks at the end of the adapter? Granted, since all these locals contain "null", there's no correctness issue here - but it is odd to (i) have a local for a scope corresponding to a primitive type (even though we know we never need it) and have extra logic in the preamble/postamble because of it. There is only a scope slot local for Addressable and NativeSymbol parameters. See the logic that initializes `scopeSlots`: scopeSlots = Arrays.copyOf(scopeSlots, numScopes); // fit to size (the array is the size of the parameter list initially, but is adjusted downwards. Maybe that should be made clearer...) ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/640 From jvernee at openjdk.java.net Tue Feb 15 15:01:18 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Feb 2022 15:01:18 GMT Subject: [foreign-preview] RFR: 8281595: ASM-ify scope acquire/release for down call parameters [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch rewrites the scope acquire/release logic that we do for downcalls inside ASM, in the generated specialized binding class. This also drops the fallback path we had for more than 5 scopes. The new code now always checks to see if every scope is unique. (I think that should be okay, but please let me know if otherwise). > > I've also added a benchmark by Maurizio to this patch, which was showing a failure to scalar replace some scoped arguments with the old MH logic (reason discussed in [JDK-8281387](https://bugs.openjdk.java.net/browse/JDK-8281387)). With the new ASM-based logic, there is no sign of allocations (other than some noise): > > > Benchmark Mode Cnt Score Error Units > PointerInvoke.panama_call_as_address avgt 30 13.181 ? 0.320 ns/op > PointerInvoke.panama_call_as_address:?gc.alloc.rate avgt 30 0.043 ? 0.049 MB/sec > PointerInvoke.panama_call_as_address:?gc.alloc.rate.norm avgt 30 0.001 ? 0.001 B/op > PointerInvoke.panama_call_as_address:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_long avgt 30 12.943 ? 0.287 ns/op > PointerInvoke.panama_call_as_long:?gc.alloc.rate avgt 30 0.065 ? 0.054 MB/sec > PointerInvoke.panama_call_as_long:?gc.alloc.rate.norm avgt 30 0.002 ? 0.001 B/op > PointerInvoke.panama_call_as_long:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_new_segment avgt 30 14.309 ? 0.177 ns/op > PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate avgt 30 0.173 ? 0.144 MB/sec > PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate.norm avgt 30 0.005 ? 0.004 B/op > PointerInvoke.panama_call_as_new_segment:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_segment avgt 30 13.273 ? 0.191 ns/op > PointerInvoke.panama_call_as_segment:?gc.alloc.rate avgt 30 ? 10?? MB/sec > PointerInvoke.panama_call_as_segment:?gc.alloc.rate.norm avgt 30 ? 10?? B/op > PointerInvoke.panama_call_as_segment:?gc.count avgt 30 ? 0 counts > > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Use local variable for inital scope slots array (instead of storing it in the scopeSlots field) ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/640/files - new: https://git.openjdk.java.net/panama-foreign/pull/640/files/1ec239ea..078e77e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=640&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=640&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/640.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/640/head:pull/640 PR: https://git.openjdk.java.net/panama-foreign/pull/640 From mcimadamore at openjdk.java.net Tue Feb 15 15:01:18 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Feb 2022 15:01:18 GMT Subject: [foreign-preview] RFR: 8281595: ASM-ify scope acquire/release for down call parameters [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 14:57:29 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch rewrites the scope acquire/release logic that we do for downcalls inside ASM, in the generated specialized binding class. This also drops the fallback path we had for more than 5 scopes. The new code now always checks to see if every scope is unique. (I think that should be okay, but please let me know if otherwise). >> >> I've also added a benchmark by Maurizio to this patch, which was showing a failure to scalar replace some scoped arguments with the old MH logic (reason discussed in [JDK-8281387](https://bugs.openjdk.java.net/browse/JDK-8281387)). With the new ASM-based logic, there is no sign of allocations (other than some noise): >> >> >> Benchmark Mode Cnt Score Error Units >> PointerInvoke.panama_call_as_address avgt 30 13.181 ? 0.320 ns/op >> PointerInvoke.panama_call_as_address:?gc.alloc.rate avgt 30 0.043 ? 0.049 MB/sec >> PointerInvoke.panama_call_as_address:?gc.alloc.rate.norm avgt 30 0.001 ? 0.001 B/op >> PointerInvoke.panama_call_as_address:?gc.count avgt 30 ? 0 counts >> PointerInvoke.panama_call_as_long avgt 30 12.943 ? 0.287 ns/op >> PointerInvoke.panama_call_as_long:?gc.alloc.rate avgt 30 0.065 ? 0.054 MB/sec >> PointerInvoke.panama_call_as_long:?gc.alloc.rate.norm avgt 30 0.002 ? 0.001 B/op >> PointerInvoke.panama_call_as_long:?gc.count avgt 30 ? 0 counts >> PointerInvoke.panama_call_as_new_segment avgt 30 14.309 ? 0.177 ns/op >> PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate avgt 30 0.173 ? 0.144 MB/sec >> PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate.norm avgt 30 0.005 ? 0.004 B/op >> PointerInvoke.panama_call_as_new_segment:?gc.count avgt 30 ? 0 counts >> PointerInvoke.panama_call_as_segment avgt 30 13.273 ? 0.191 ns/op >> PointerInvoke.panama_call_as_segment:?gc.alloc.rate avgt 30 ? 10?? MB/sec >> PointerInvoke.panama_call_as_segment:?gc.alloc.rate.norm avgt 30 ? 10?? B/op >> PointerInvoke.panama_call_as_segment:?gc.count avgt 30 ? 0 counts >> >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Use local variable for inital scope slots array (instead of storing it in the scopeSlots field) Marked as reviewed by mcimadamore (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/640 From jvernee at openjdk.java.net Tue Feb 15 15:01:18 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Feb 2022 15:01:18 GMT Subject: [foreign-preview] RFR: 8281595: ASM-ify scope acquire/release for down call parameters [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 14:39:22 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 486: >> >>> 484: >>> 485: private void emitReleaseScopes() { >>> 486: for (int scopeLocal : scopeSlots) { >> >> Isn't this emitting more code than required? E.g. if we pass 10 primitives, we will emit 10 scope checks at the end of the adapter? Granted, since all these locals contain "null", there's no correctness issue here - but it is odd to (i) have a local for a scope corresponding to a primitive type (even though we know we never need it) and have extra logic in the preamble/postamble because of it. > > There is only a scope slot local for Addressable and NativeSymbol parameters. Not for primitives. See the logic that initializes `scopeSlots`: > > > scopeSlots = Arrays.copyOf(scopeSlots, numScopes); // fit to size > > > (the array is the size of the parameter list initially, but is adjusted downwards. Maybe that should be made clearer...) I've tried to clarify the code that creates `scopeSlots` a bit by using a local variable for the intermediate array, instead of storing it in the field. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/640 From mcimadamore at openjdk.java.net Tue Feb 15 15:01:19 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Feb 2022 15:01:19 GMT Subject: [foreign-preview] RFR: 8281595: ASM-ify scope acquire/release for down call parameters [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 14:53:55 GMT, Jorn Vernee wrote: >> There is only a scope slot local for Addressable and NativeSymbol parameters. Not for primitives. See the logic that initializes `scopeSlots`: >> >> >> scopeSlots = Arrays.copyOf(scopeSlots, numScopes); // fit to size >> >> >> (the array is the size of the parameter list initially, but is adjusted downwards. Maybe that should be made clearer...) > > I've tried to clarify the code that creates `scopeSlots` a bit by using a local variable for the intermediate array, instead of storing it in the field. Thanks - I've missed that ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/640 From jvernee at openjdk.java.net Tue Feb 15 15:37:43 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Feb 2022 15:37:43 GMT Subject: [foreign-preview] Integrated: 8281595: ASM-ify scope acquire/release for down call parameters In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 19:05:19 GMT, Jorn Vernee wrote: > Hi, > > This patch rewrites the scope acquire/release logic that we do for downcalls inside ASM, in the generated specialized binding class. This also drops the fallback path we had for more than 5 scopes. The new code now always checks to see if every scope is unique. (I think that should be okay, but please let me know if otherwise). > > I've also added a benchmark by Maurizio to this patch, which was showing a failure to scalar replace some scoped arguments with the old MH logic (reason discussed in [JDK-8281387](https://bugs.openjdk.java.net/browse/JDK-8281387)). With the new ASM-based logic, there is no sign of allocations (other than some noise): > > > Benchmark Mode Cnt Score Error Units > PointerInvoke.panama_call_as_address avgt 30 13.181 ? 0.320 ns/op > PointerInvoke.panama_call_as_address:?gc.alloc.rate avgt 30 0.043 ? 0.049 MB/sec > PointerInvoke.panama_call_as_address:?gc.alloc.rate.norm avgt 30 0.001 ? 0.001 B/op > PointerInvoke.panama_call_as_address:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_long avgt 30 12.943 ? 0.287 ns/op > PointerInvoke.panama_call_as_long:?gc.alloc.rate avgt 30 0.065 ? 0.054 MB/sec > PointerInvoke.panama_call_as_long:?gc.alloc.rate.norm avgt 30 0.002 ? 0.001 B/op > PointerInvoke.panama_call_as_long:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_new_segment avgt 30 14.309 ? 0.177 ns/op > PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate avgt 30 0.173 ? 0.144 MB/sec > PointerInvoke.panama_call_as_new_segment:?gc.alloc.rate.norm avgt 30 0.005 ? 0.004 B/op > PointerInvoke.panama_call_as_new_segment:?gc.count avgt 30 ? 0 counts > PointerInvoke.panama_call_as_segment avgt 30 13.273 ? 0.191 ns/op > PointerInvoke.panama_call_as_segment:?gc.alloc.rate avgt 30 ? 10?? MB/sec > PointerInvoke.panama_call_as_segment:?gc.alloc.rate.norm avgt 30 ? 10?? B/op > PointerInvoke.panama_call_as_segment:?gc.count avgt 30 ? 0 counts > > > Thanks, > Jorn This pull request has now been integrated. Changeset: 4c7b0da2 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/4c7b0da2a31e1de6a93c6df93a730db056670c37 Stats: 420 lines in 5 files changed: 237 ins; 178 del; 5 mod 8281595: ASM-ify scope acquire/release for down call parameters 8281387: Some downcall shapes show unexpected allocations Co-authored-by: Maurizio Cimadamore Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/640 From mcimadamore at openjdk.java.net Tue Feb 15 17:51:44 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Feb 2022 17:51:44 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession Message-ID: This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. ------------- Commit messages: - Fix whitespaces - Merge branch 'foreign-preview' into session_preview - Fix reference to ResourceScope in javadoc - Fix MemorySession javadoc - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/641/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281855 Stats: 4685 lines in 136 files changed: 1501 ins; 1333 del; 1851 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Tue Feb 15 17:51:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Feb 2022 17:51:46 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 17:32:50 GMT, Maurizio Cimadamore wrote: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. I've fixed javadoc references to "scopes" and improved the javadoc text in several places. A link to a javadoc corresponding to these changes can be found here: http://cr.openjdk.java.net/~mcimadamore/panama/session_preview/javadoc/java.base/java/lang/foreign/package-summary.html src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 330: > 328: * "root" session implementation, and throws {@link UnsupportedOperationException} on close. > 329: */ > 330: public final static class NonCloseableView implements MemorySession, Scoped { This is a simple wrapper class around a session which delegates everything to the session from which it is built - and overrides `close` to throw an exception. I believe the cost for creating these little instances will be negligible - if problems show up, we can always move to more complex approaches (e.g. where `MemorySegment` implements `MemorySession`, or where we use `@Stable` fields to cache a non-closeable view inside the root memory session). src/java.base/share/classes/jdk/internal/foreign/Scoped.java line 31: > 29: > 30: public interface Scoped { > 31: MemorySessionImpl sessionImpl(); This method is used to retrieve the "root" session associated with either a resource, or a session view. This means that, to simplify the implementation, `MemorySessionImpl` has to implement `Scoped` as well (and return itself). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From svkamath at openjdk.java.net Wed Feb 16 07:14:59 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Wed, 16 Feb 2022 07:14:59 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v2] In-Reply-To: References: Message-ID: <7hVB0c-DcZ5rEsG-B-twvpBdWHjl25p2iYZS7IF0HIg=.03236479-ee9c-48bc-b153-d12c853759d2@github.com> > 8281562:[vectorapi] Add support for popcount operation Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Fixed review comments. Added test case to the test framework ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/173/files - new: https://git.openjdk.java.net/panama-vector/pull/173/files/5161759a..f594bea9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=00-01 Stats: 1120 lines in 73 files changed: 972 ins; 78 del; 70 mod Patch: https://git.openjdk.java.net/panama-vector/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/173/head:pull/173 PR: https://git.openjdk.java.net/panama-vector/pull/173 From themode at outlook.fr Wed Feb 16 11:34:37 2022 From: themode at outlook.fr (Felix Cravic) Date: Wed, 16 Feb 2022 11:34:37 +0000 Subject: Stack allocation API Message-ID: Hello, I was wondering if there is any plan to expose an API to do stack allocation, similarly to graal [1] but with the advantage of not depending on graal native (and the fact that project Leyden may come). I am mostly seeking it for its potential performance aspect, which has already been discussed [2] but I do not think that the "very promising direction" has been communicated. Have any benchmark/study been done to define the usefulness of such low-level API? [1] - https://www.graalvm.org/sdk/javadoc/index.html?org/graalvm/nativeimage/StackValue.html [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006745.html From maurizio.cimadamore at oracle.com Wed Feb 16 13:02:08 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Feb 2022 13:02:08 +0000 Subject: Stack allocation API In-Reply-To: References: Message-ID: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> Hi Felix, the API has changed quite a bit since the email you are referring to. We now have a SegmentAllocator API which can be used to define custom allocation strategies. Out of the box, the API gives you ability to do arena allocation (but in the heap, not in the stack), or to obtain a SegmentAllocator which will keep allocating over the same segment over and over (e.g. will return slices). Note that a SegmentAllocator is accepted by all the downcall method handle targeting native functions which return structs by value (and also by other API methods returning structs), so you can significantly alter the performance of the entire API by using a custom allocator, such as the one defined in [1]. We have plans, when Loom arrives, it might be possible to add another kind of ResourceScope - that is neither confined, nor shared: a "structured" scope. The way this scope works is that it creates a Loom scope locals, and then it allow access from all the threads that inherit that scope local. Since such a scope will only be usable in a lambda expression (try-with-resources will not be supported there), it will be effectively be a stack-bounded scope. This would open up the possiblity of enabling stack allocation for all memory segments created within that scope. But even w/o going that far, I'd say there are plenty of things in the existing API to try and make memory allocation more performant. Maurizio [1] - https://github.com/openjdk/panama-foreign/pull/509 On 16/02/2022 11:34, Felix Cravic wrote: > Hello, > I was wondering if there is any plan to expose an API to do stack allocation, similarly to graal [1] but with the advantage of not depending on graal native (and the fact that project Leyden may come). > I am mostly seeking it for its potential performance aspect, which has already been discussed [2] but I do not think that the "very promising direction" has been communicated. Have any benchmark/study been done to define the usefulness of such low-level API? > > [1] - > https://www.graalvm.org/sdk/javadoc/index.html?org/graalvm/nativeimage/StackValue.html > [2] - > https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006745.html From iotsakp at gmail.com Wed Feb 16 20:56:43 2022 From: iotsakp at gmail.com (Ioannis Tsakpinis) Date: Wed, 16 Feb 2022 22:56:43 +0200 Subject: Stack allocation API In-Reply-To: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> Message-ID: Hey Felix, Maurizio has asked me to share our approach to stack allocation in LWJGL. It is based on a simple class called MemoryStack, which wraps a thread- local fixed-sized direct ByteBuffer, that serves as the "stack" memory. The size is configurable, there's both a static and an instance API, you can allocate arbitrary MemoryStack instances and use them without the thread-local access, you can push & pop frames at will and there are various other utilities, but the most common usage pattern looks like this: try (MemoryStack stack = stackPush()) { // allocates 10 bytes on the stack ByteBuffer bytes = stack.malloc(10); // allocates 10 ints on the stack IntBuffer ints = stack.mallocInt(10); // allocates & zero-initializes 10 floats on the stack FloatBuffer floats = stack.callocFloat(10); // allocates 10 pointers on the stack. PointerBuffer has the API of // LongBuffer, but functions as an IntBuffer on 32-bit JVMs. PointerBuffer pointers = stack.mallocPointer(10); // allocates a buffer that contains the string & null-terminator in // UTF-8 encoding. ByteBuffer string = stack.UTF8("hello"); // allocates enough storage for an VkApplicationInfo struct and // initializes it. VkApplicationInfo app = VkApplicationInfo.malloc(stack) .sType(VK_STRUCTURE_TYPE_APPLICATION_INFO) .pNext(NULL) .pApplicationName("My App") .applicationVersion(1) .pEngineName("My Engine") .engineVersion(1) .apiVersion(VK_API_VERSION_1_3); // allocates an array of 3 VkLayerProperties structs. // VkLayerProperties.Buffer has the API of a NIO buffer, except each // element is a VkLayerProperties struct instance. VkLayerProperties.Buffer availableLayers = VkLayerProperties.malloc(3, stack); } MemoryStack implements AutoCloseable and its close() delegates to pop(), so all memory "stack-allocated" within the try-with-resources block will effectively be "freed" after the block ends. Subsequent allocations on the same thread will reuse the same memory. The implementation of MemoryStack is nothing sophisticated and can easily be adapted to the Panama API. In fact, I have done so in my Panama tests, e.g. imagine the malloc method returning a MemorySegment instead of a ByteBuffer. In this sense, I don't think it's critical for Panama to provide a stack allocation API. The current API with MemoryAddress, MemorySegment and SegmentAllocator is flexible enough for users to write their own memory management utilities, including zero-overhead stack allocation. An issue with LWJGL's approach is the thread-local access to grab the current thread's MemoryStack. The thread-local lookup itself is not terribly expensive (but not free either), however it does become a problem in hot code. Hotspot cannot hoist it out of loops and this has unfortunate consequences for the surrounding code. For this reason, LWJGL applications use the following pattern: void outerMethod() { try (MemoryStack stack = stackPush()) { // thread-local lookup for (int i = 0; i < 1000; i++) { innerMethod(stack); } } } void innerMethod(MemoryStack stack) { try (MemoryStack frame = stack.push()) { // super-cheap // allocate & do work here } } That is, when performance is a priority, the MemoryStack instance is looked-up once at a higher level, then passed manually to lower level code. Maurizio mentioned Scope Locals from Project Loom, which provide a great solution to exactly this problem. We can have both clean code and zero overhead, since scope local access can be hoisted into a register and will be as fast as accessing a local variable. Another issue that is of great importance to LWJGL users is making sure Hotspot is able to perform scalar replacement via Escape Analysis. An API like MemoryStack does provide a solution for avoiding excessive malloc & free calls, but the Java instances that wrap the "stack-allocated" memory can become a problem, especially since such allocations will be done in great numbers (e.g. thousands per frame in a game, or dozens per request in a server application). EA works great in LWJGL applications, however we've had to very carefully tune the internals and, of course, resort to Unsafe for some critical functionality. My initial port of MemoryStack to Panama didn't do so well, however this turned out to be an issue with downcalls in general and has recently been fixed by JDK-8281595. When Valhalla becomes available it should be trivially simple to implement high-performance stack allocation, with whatever API you see fit and without such trouble. - Ioannis On Wed, 16 Feb 2022 at 15:02, Maurizio Cimadamore wrote: > > Hi Felix, > the API has changed quite a bit since the email you are referring to. We > now have a SegmentAllocator API which can be used to define custom > allocation strategies. Out of the box, the API gives you ability to do > arena allocation (but in the heap, not in the stack), or to obtain a > SegmentAllocator which will keep allocating over the same segment over > and over (e.g. will return slices). Note that a SegmentAllocator is > accepted by all the downcall method handle targeting native functions > which return structs by value (and also by other API methods returning > structs), so you can significantly alter the performance of the entire > API by using a custom allocator, such as the one defined in [1]. > > We have plans, when Loom arrives, it might be possible to add another > kind of ResourceScope - that is neither confined, nor shared: a > "structured" scope. The way this scope works is that it creates a Loom > scope locals, and then it allow access from all the threads that inherit > that scope local. Since such a scope will only be usable in a lambda > expression (try-with-resources will not be supported there), it will be > effectively be a stack-bounded scope. This would open up the possiblity > of enabling stack allocation for all memory segments created within that > scope. > > But even w/o going that far, I'd say there are plenty of things in the > existing API to try and make memory allocation more performant. > > Maurizio > > [1] - https://github.com/openjdk/panama-foreign/pull/509 > > > On 16/02/2022 11:34, Felix Cravic wrote: > > Hello, > > I was wondering if there is any plan to expose an API to do stack allocation, similarly to graal [1] but with the advantage of not depending on graal native (and the fact that project Leyden may come). > > I am mostly seeking it for its potential performance aspect, which has already been discussed [2] but I do not think that the "very promising direction" has been communicated. Have any benchmark/study been done to define the usefulness of such low-level API? > > > > [1] - > > https://www.graalvm.org/sdk/javadoc/index.html?org/graalvm/nativeimage/StackValue.html > > [2] - > > https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006745.html From jvernee at openjdk.java.net Wed Feb 16 21:24:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Feb 2022 21:24:31 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 17:32:50 GMT, Maurizio Cimadamore wrote: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 306: > 304: if (scope != null) { > 305: if (scope.ownerThread() == null && scope.isCloseable()) { > 306: throw new UnsupportedOperationException("ByteBuffer derived from closeable shared segments not supported"); Reviewer note: does user have the power to create non-closeable shared segments now? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From forax at univ-mlv.fr Wed Feb 16 21:38:55 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Feb 2022 22:38:55 +0100 (CET) Subject: Stack allocation API In-Reply-To: References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> Message-ID: <1763924590.4591282.1645047535394.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ioannis Tsakpinis" > To: "Maurizio Cimadamore" > Cc: "Felix Cravic" , "panama-dev at openjdk.java.net'" > Sent: Wednesday, February 16, 2022 9:56:43 PM > Subject: Re: Stack allocation API ... > An issue with LWJGL's approach is the thread-local access to grab the > current thread's MemoryStack. The thread-local lookup itself is not > terribly expensive (but not free either), however it does become a problem > in hot code. Hotspot cannot hoist it out of loops and this has unfortunate > consequences for the surrounding code. I wonder how the ScopeLocal of loom behave compared to ThreadLocal. https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.concurrent/jdk/incubator/concurrent/ScopeLocal.html > > - Ioannis R?mi From maurizio.cimadamore at oracle.com Wed Feb 16 22:07:11 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Feb 2022 22:07:11 +0000 Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: Message-ID: That would be an implicit session. Implicit sessions are back to being non-closeable, and shared, in this patch. Maurizio > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 306: > >> 304: if (scope != null) { >> 305: if (scope.ownerThread() == null && scope.isCloseable()) { >> 306: throw new UnsupportedOperationException("ByteBuffer derived from closeable shared segments not supported"); > Reviewer note: does user have the power to create non-closeable shared segments now? > > ------------- > > PR: https://git.openjdk.java.net/panama-foreign/pull/641 From samuel.audet at gmail.com Wed Feb 16 23:30:07 2022 From: samuel.audet at gmail.com (Samuel Audet) Date: Thu, 17 Feb 2022 08:30:07 +0900 Subject: Stack allocation API In-Reply-To: References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> Message-ID: <3f6fe7fa-f2eb-775e-114a-13fbb9065d78@gmail.com> Hi, I remember Maurizio explaining in great details that such an approach cannot be thread-safe, so would never be something that would make its way into the JDK. Did anything change in that respect? Is OpenJDK actually now considering such inherently "unsafe" approaches? Samuel On 2/17/22 05:56, Ioannis Tsakpinis wrote: > Hey Felix, > > Maurizio has asked me to share our approach to stack allocation in LWJGL. > > It is based on a simple class called MemoryStack, which wraps a thread- > local fixed-sized direct ByteBuffer, that serves as the "stack" memory. > The size is configurable, there's both a static and an instance API, > you can allocate arbitrary MemoryStack instances and use them without the > thread-local access, you can push & pop frames at will and there are > various other utilities, but the most common usage pattern looks like > this: > > try (MemoryStack stack = stackPush()) { > // allocates 10 bytes on the stack > ByteBuffer bytes = stack.malloc(10); > > // allocates 10 ints on the stack > IntBuffer ints = stack.mallocInt(10); > > // allocates & zero-initializes 10 floats on the stack > FloatBuffer floats = stack.callocFloat(10); > > // allocates 10 pointers on the stack. PointerBuffer has the API of > // LongBuffer, but functions as an IntBuffer on 32-bit JVMs. > PointerBuffer pointers = stack.mallocPointer(10); > > // allocates a buffer that contains the string & null-terminator in > // UTF-8 encoding. > ByteBuffer string = stack.UTF8("hello"); > > // allocates enough storage for an VkApplicationInfo struct and > // initializes it. > VkApplicationInfo app = VkApplicationInfo.malloc(stack) > .sType(VK_STRUCTURE_TYPE_APPLICATION_INFO) > .pNext(NULL) > .pApplicationName("My App") > .applicationVersion(1) > .pEngineName("My Engine") > .engineVersion(1) > .apiVersion(VK_API_VERSION_1_3); > > // allocates an array of 3 VkLayerProperties structs. > // VkLayerProperties.Buffer has the API of a NIO buffer, except each > // element is a VkLayerProperties struct instance. > VkLayerProperties.Buffer availableLayers = > VkLayerProperties.malloc(3, stack); > } > > MemoryStack implements AutoCloseable and its close() delegates to pop(), > so all memory "stack-allocated" within the try-with-resources block will > effectively be "freed" after the block ends. Subsequent allocations on > the same thread will reuse the same memory. > > The implementation of MemoryStack is nothing sophisticated and can easily > be adapted to the Panama API. In fact, I have done so in my Panama tests, > e.g. imagine the malloc method returning a MemorySegment instead of a > ByteBuffer. In this sense, I don't think it's critical for Panama to > provide a stack allocation API. The current API with MemoryAddress, > MemorySegment and SegmentAllocator is flexible enough for users to write > their own memory management utilities, including zero-overhead stack > allocation. > > An issue with LWJGL's approach is the thread-local access to grab the > current thread's MemoryStack. The thread-local lookup itself is not > terribly expensive (but not free either), however it does become a problem > in hot code. Hotspot cannot hoist it out of loops and this has unfortunate > consequences for the surrounding code. For this reason, LWJGL applications > use the following pattern: > > void outerMethod() { > try (MemoryStack stack = stackPush()) { // thread-local lookup > for (int i = 0; i < 1000; i++) { > innerMethod(stack); > } > } > } > > void innerMethod(MemoryStack stack) { > try (MemoryStack frame = stack.push()) { // super-cheap > // allocate & do work here > } > } > > That is, when performance is a priority, the MemoryStack instance is > looked-up once at a higher level, then passed manually to lower level > code. Maurizio mentioned Scope Locals from Project Loom, which provide a > great solution to exactly this problem. We can have both clean code and > zero overhead, since scope local access can be hoisted into a register > and will be as fast as accessing a local variable. > > Another issue that is of great importance to LWJGL users is making sure > Hotspot is able to perform scalar replacement via Escape Analysis. An API > like MemoryStack does provide a solution for avoiding excessive malloc & > free calls, but the Java instances that wrap the "stack-allocated" memory > can become a problem, especially since such allocations will be done in > great numbers (e.g. thousands per frame in a game, or dozens per request > in a server application). EA works great in LWJGL applications, however > we've had to very carefully tune the internals and, of course, resort to > Unsafe for some critical functionality. My initial port of MemoryStack to > Panama didn't do so well, however this turned out to be an issue with > downcalls in general and has recently been fixed by JDK-8281595. When > Valhalla becomes available it should be trivially simple to implement > high-performance stack allocation, with whatever API you see fit and > without such trouble. > > - Ioannis > > On Wed, 16 Feb 2022 at 15:02, Maurizio Cimadamore > wrote: >> >> Hi Felix, >> the API has changed quite a bit since the email you are referring to. We >> now have a SegmentAllocator API which can be used to define custom >> allocation strategies. Out of the box, the API gives you ability to do >> arena allocation (but in the heap, not in the stack), or to obtain a >> SegmentAllocator which will keep allocating over the same segment over >> and over (e.g. will return slices). Note that a SegmentAllocator is >> accepted by all the downcall method handle targeting native functions >> which return structs by value (and also by other API methods returning >> structs), so you can significantly alter the performance of the entire >> API by using a custom allocator, such as the one defined in [1]. >> >> We have plans, when Loom arrives, it might be possible to add another >> kind of ResourceScope - that is neither confined, nor shared: a >> "structured" scope. The way this scope works is that it creates a Loom >> scope locals, and then it allow access from all the threads that inherit >> that scope local. Since such a scope will only be usable in a lambda >> expression (try-with-resources will not be supported there), it will be >> effectively be a stack-bounded scope. This would open up the possiblity >> of enabling stack allocation for all memory segments created within that >> scope. >> >> But even w/o going that far, I'd say there are plenty of things in the >> existing API to try and make memory allocation more performant. >> >> Maurizio >> >> [1] - https://github.com/openjdk/panama-foreign/pull/509 >> >> >> On 16/02/2022 11:34, Felix Cravic wrote: >>> Hello, >>> I was wondering if there is any plan to expose an API to do stack allocation, similarly to graal [1] but with the advantage of not depending on graal native (and the fact that project Leyden may come). >>> I am mostly seeking it for its potential performance aspect, which has already been discussed [2] but I do not think that the "very promising direction" has been communicated. Have any benchmark/study been done to define the usefulness of such low-level API? >>> >>> [1] - >>> https://www.graalvm.org/sdk/javadoc/index.html?org/graalvm/nativeimage/StackValue.html >>> [2] - >>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006745.html From mail at smogura.eu Wed Feb 16 23:33:32 2022 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Wed, 16 Feb 2022 23:33:32 +0000 Subject: Stack allocation API In-Reply-To: <1763924590.4591282.1645047535394.JavaMail.zimbra@u-pem.fr> References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> <1763924590.4591282.1645047535394.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, My understanding is that scope local is like parameter you can pass to function (but it?s passed like a global reference), and enforces closure (Autoclosable can?t enforce value to be put in try-with-resources, so stack can be incorrect if exceptions are not properly handled). However I think that everyone (or at least me) think about something like this: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc Kind regards, Rado On Feb 16, 2022, at 10:40 PM, Remi Forax wrote: ?----- Original Message ----- From: "Ioannis Tsakpinis" To: "Maurizio Cimadamore" Cc: "Felix Cravic" , "panama-dev at openjdk.java.net'" Sent: Wednesday, February 16, 2022 9:56:43 PM Subject: Re: Stack allocation API ... An issue with LWJGL's approach is the thread-local access to grab the current thread's MemoryStack. The thread-local lookup itself is not terribly expensive (but not free either), however it does become a problem in hot code. Hotspot cannot hoist it out of loops and this has unfortunate consequences for the surrounding code. I wonder how the ScopeLocal of loom behave compared to ThreadLocal. https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.concurrent/jdk/incubator/concurrent/ScopeLocal.html - Ioannis R?mi From xgong at openjdk.java.net Thu Feb 17 08:00:35 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 17 Feb 2022 08:00:35 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v2] In-Reply-To: <7hVB0c-DcZ5rEsG-B-twvpBdWHjl25p2iYZS7IF0HIg=.03236479-ee9c-48bc-b153-d12c853759d2@github.com> References: <7hVB0c-DcZ5rEsG-B-twvpBdWHjl25p2iYZS7IF0HIg=.03236479-ee9c-48bc-b153-d12c853759d2@github.com> Message-ID: On Wed, 16 Feb 2022 07:14:59 GMT, Smita Kamath wrote: >> 8281562:[vectorapi] Add support for popcount operation > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comments. Added test case to the test framework Is there a followed-up PR to intrinsify the new added opcodes in hotspot? Thanks! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From maurizio.cimadamore at oracle.com Thu Feb 17 09:44:18 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Feb 2022 09:44:18 +0000 Subject: Stack allocation API In-Reply-To: <3f6fe7fa-f2eb-775e-114a-13fbb9065d78@gmail.com> References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> <3f6fe7fa-f2eb-775e-114a-13fbb9065d78@gmail.com> Message-ID: <72216eec-2e90-2a05-4820-d1fd5c4f27d3@oracle.com> On 16/02/2022 23:30, Samuel Audet wrote: > Hi, > > I remember Maurizio explaining in great details that such an approach > cannot be thread-safe, so would never be something that would make its > way into the JDK. Did anything change in that respect? Is OpenJDK > actually now considering such inherently "unsafe" approaches? Not 100% what you are referring to. Ioannis API is using thread-locals, so I would assume that access occurs within a single thread. If access occurs from multiple threads then you need additional guarantees that all threads created inside the TWR block have terminated by the time the TWR is closed, otherwise, yes, access is in general unsafe. The scope-local based solution I referred to in my initial reply features this latter guarantee: a "structural" scope cannot be closed if there are threads created inside the bubble that are still running (this is a guarantee similar to that we get from structural concurrency). That said, I think the spirit of this email thread is that the Panama API has the building blocks (some of which are unsafe, such as ability of creating segments from raw addresses, and therefore require the --enable-native-access flag) to create custom (and efficient) allocators. The safety vs. performance tradeoff is one that the application will have to make. The Panama API does not, out of the box, provide unsafe allocation strategies. Cheers Maurizio > > Samuel > > On 2/17/22 05:56, Ioannis Tsakpinis wrote: >> Hey Felix, >> >> Maurizio has asked me to share our approach to stack allocation in >> LWJGL. >> >> It is based on a simple class called MemoryStack, which wraps a thread- >> local fixed-sized direct ByteBuffer, that serves as the "stack" memory. >> The size is configurable, there's both a static and an instance API, >> you can allocate arbitrary MemoryStack instances and use them without >> the >> thread-local access, you can push & pop frames at will and there are >> various other utilities, but the most common usage pattern looks like >> this: >> >> try (MemoryStack stack = stackPush()) { >> ???? // allocates 10 bytes on the stack >> ???? ByteBuffer bytes = stack.malloc(10); >> >> ???? // allocates 10 ints on the stack >> ???? IntBuffer ints = stack.mallocInt(10); >> >> ???? // allocates & zero-initializes 10 floats on the stack >> ???? FloatBuffer floats = stack.callocFloat(10); >> >> ???? // allocates 10 pointers on the stack. PointerBuffer has the API of >> ???? // LongBuffer, but functions as an IntBuffer on 32-bit JVMs. >> ???? PointerBuffer pointers = stack.mallocPointer(10); >> >> ???? // allocates a buffer that contains the string & null-terminator in >> ???? // UTF-8 encoding. >> ???? ByteBuffer string = stack.UTF8("hello"); >> >> ???? // allocates enough storage for an VkApplicationInfo struct and >> ???? // initializes it. >> ???? VkApplicationInfo app = VkApplicationInfo.malloc(stack) >> ???????? .sType(VK_STRUCTURE_TYPE_APPLICATION_INFO) >> ???????? .pNext(NULL) >> ???????? .pApplicationName("My App") >> ???????? .applicationVersion(1) >> ???????? .pEngineName("My Engine") >> ???????? .engineVersion(1) >> ???????? .apiVersion(VK_API_VERSION_1_3); >> >> ???? // allocates an array of 3 VkLayerProperties structs. >> ???? // VkLayerProperties.Buffer has the API of a NIO buffer, except >> each >> ???? // element is a VkLayerProperties struct instance. >> ???? VkLayerProperties.Buffer availableLayers = >> ???????? VkLayerProperties.malloc(3, stack); >> } >> >> MemoryStack implements AutoCloseable and its close() delegates to pop(), >> so all memory "stack-allocated" within the try-with-resources block will >> effectively be "freed" after the block ends. Subsequent allocations on >> the same thread will reuse the same memory. >> >> The implementation of MemoryStack is nothing sophisticated and can >> easily >> be adapted to the Panama API. In fact, I have done so in my Panama >> tests, >> e.g. imagine the malloc method returning a MemorySegment instead of a >> ByteBuffer. In this sense, I don't think it's critical for Panama to >> provide a stack allocation API. The current API with MemoryAddress, >> MemorySegment and SegmentAllocator is flexible enough for users to write >> their own memory management utilities, including zero-overhead stack >> allocation. >> >> An issue with LWJGL's approach is the thread-local access to grab the >> current thread's MemoryStack. The thread-local lookup itself is not >> terribly expensive (but not free either), however it does become a >> problem >> in hot code. Hotspot cannot hoist it out of loops and this has >> unfortunate >> consequences for the surrounding code. For this reason, LWJGL >> applications >> use the following pattern: >> >> void outerMethod() { >> ???? try (MemoryStack stack = stackPush()) { // thread-local lookup >> ???????? for (int i = 0; i < 1000; i++) { >> ???????????? innerMethod(stack); >> ???????? } >> ???? } >> } >> >> void innerMethod(MemoryStack stack) { >> ???? try (MemoryStack frame = stack.push()) { // super-cheap >> ???????? // allocate & do work here >> ???? } >> } >> >> That is, when performance is a priority, the MemoryStack instance is >> looked-up once at a higher level, then passed manually to lower level >> code. Maurizio mentioned Scope Locals from Project Loom, which provide a >> great solution to exactly this problem. We can have both clean code and >> zero overhead, since scope local access can be hoisted into a register >> and will be as fast as accessing a local variable. >> >> Another issue that is of great importance to LWJGL users is making sure >> Hotspot is able to perform scalar replacement via Escape Analysis. An >> API >> like MemoryStack does provide a solution for avoiding excessive malloc & >> free calls, but the Java instances that wrap the "stack-allocated" >> memory >> can become a problem, especially since such allocations will be done in >> great numbers (e.g. thousands per frame in a game, or dozens per request >> in a server application). EA works great in LWJGL applications, however >> we've had to very carefully tune the internals and, of course, resort to >> Unsafe for some critical functionality. My initial port of >> MemoryStack to >> Panama didn't do so well, however this turned out to be an issue with >> downcalls in general and has recently been fixed by JDK-8281595. When >> Valhalla becomes available it should be trivially simple to implement >> high-performance stack allocation, with whatever API you see fit and >> without such trouble. >> >> - Ioannis >> >> On Wed, 16 Feb 2022 at 15:02, Maurizio Cimadamore >> wrote: >>> >>> Hi Felix, >>> the API has changed quite a bit since the email you are referring >>> to. We >>> now have a SegmentAllocator API which can be used to define custom >>> allocation strategies. Out of the box, the API gives you ability to do >>> arena allocation (but in the heap, not in the stack), or to obtain a >>> SegmentAllocator which will keep allocating over the same segment over >>> and over (e.g. will return slices). Note that a SegmentAllocator is >>> accepted by all the downcall method handle targeting native functions >>> which return structs by value (and also by other API methods returning >>> structs), so you can significantly alter the performance of the entire >>> API by using a custom allocator, such as the one defined in [1]. >>> >>> We have plans, when Loom arrives, it might be possible to add another >>> kind of ResourceScope - that is neither confined, nor shared: a >>> "structured" scope. The way this scope works is that it creates a Loom >>> scope locals, and then it allow access from all the threads that >>> inherit >>> that scope local. Since such a scope will only be usable in a lambda >>> expression (try-with-resources will not be supported there), it will be >>> effectively be a stack-bounded scope. This would open up the possiblity >>> of enabling stack allocation for all memory segments created within >>> that >>> scope. >>> >>> But even w/o going that far, I'd say there are plenty of things in the >>> existing API to try and make memory allocation more performant. >>> >>> Maurizio >>> >>> [1] - >>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/509__;!!ACWV5N9M2RV99hQ!eA92VhRJZaQQtIoipsZ3xPQMRR4PMg20FoPUa4txRAEx-jWarCSTw6AfIcwb42QDbxyltuo$ >>> >>> >>> On 16/02/2022 11:34, Felix Cravic wrote: >>>> Hello, >>>> I was wondering if there is any plan to expose an API to do stack >>>> allocation, similarly to graal [1] but with the advantage of not >>>> depending on graal native (and the fact that project Leyden may come). >>>> I am mostly seeking it for its potential performance aspect, which >>>> has already been discussed [2] but I do not think that the "very >>>> promising direction" has been communicated. Have any >>>> benchmark/study been done to define the usefulness of such >>>> low-level API? >>>> >>>> [1] - >>>> https://urldefense.com/v3/__https://www.graalvm.org/sdk/javadoc/index.html?org*graalvm*nativeimage*StackValue.html__;Ly8v!!ACWV5N9M2RV99hQ!eA92VhRJZaQQtIoipsZ3xPQMRR4PMg20FoPUa4txRAEx-jWarCSTw6AfIcwb42QDu2lvrS8$ >>>> [2] - >>>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006745.html >>>> From jorn.vernee at oracle.com Thu Feb 17 13:21:11 2022 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 17 Feb 2022 14:21:11 +0100 Subject: Stack allocation API In-Reply-To: References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> <1763924590.4591282.1645047535394.JavaMail.zimbra@u-pem.fr> Message-ID: <50dc4776-1246-c897-b64b-ce68074d1a5d@oracle.com> > However I think that everyone (or at least me) think about something like this: > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc This seems to be using the underlying OS thread stack to allocate things? Note that we can not do the same in Java. We want Java thread stacks to be freely copyable for Loom, which means we can't have pointers into the thread's native stack. A solution to this problems would be for instance to have a dedicated thread-local side stack for the native allocations, which is not moved around. This is essentially what the LWJGL MemoryStack does. I believe Loom's ScopeLocals could help to make the thread-local access part faster in the future as well. Jorn On 17/02/2022 00:33, Rados?aw Smogura wrote: > Hi, > > My understanding is that scope local is like parameter you can pass to function (but it?s passed like a global reference), and enforces closure (Autoclosable can?t enforce value to be put in try-with-resources, so stack can be incorrect if exceptions are not properly handled). > > However I think that everyone (or at least me) think about something like this: > > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc > > Kind regards, > Rado > On Feb 16, 2022, at 10:40 PM, Remi Forax wrote: > > ?----- Original Message ----- > From: "Ioannis Tsakpinis" > To: "Maurizio Cimadamore" > Cc: "Felix Cravic" , "panama-dev at openjdk.java.net'" > Sent: Wednesday, February 16, 2022 9:56:43 PM > Subject: Re: Stack allocation API > > > ... > > An issue with LWJGL's approach is the thread-local access to grab the > current thread's MemoryStack. The thread-local lookup itself is not > terribly expensive (but not free either), however it does become a problem > in hot code. Hotspot cannot hoist it out of loops and this has unfortunate > consequences for the surrounding code. > > I wonder how the ScopeLocal of loom behave compared to ThreadLocal. > https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.concurrent/jdk/incubator/concurrent/ScopeLocal.html > > > - Ioannis > > R?mi From mail at smogura.eu Thu Feb 17 14:08:30 2022 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Thu, 17 Feb 2022 14:08:30 +0000 Subject: Stack allocation API In-Reply-To: <50dc4776-1246-c897-b64b-ce68074d1a5d@oracle.com> References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> <1763924590.4591282.1645047535394.JavaMail.zimbra@u-pem.fr> <50dc4776-1246-c897-b64b-ce68074d1a5d@oracle.com> Message-ID: Yes, This one uses (90% sure) native stack. However, in order to prevent leakage of pointer out of stack C# introduced special kind of structs (value objects) ?ref struct? to denote values which cannot escape to heap and / or through stack boundaries (the Span type in example is actually ref struct) I think, in Java, right now this can only be done via runtime checks. Kind regards, Rado > On Feb 17, 2022, at 2:21 PM, Jorn Vernee wrote: > > ? >> >> However I think that everyone (or at least me) think about something like this: >> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc > > This seems to be using the underlying OS thread stack to allocate things? Note that we can not do the same in Java. We want Java thread stacks to be freely copyable for Loom, which means we can't have pointers into the thread's native stack. > > A solution to this problems would be for instance to have a dedicated thread-local side stack for the native allocations, which is not moved around. This is essentially what the LWJGL MemoryStack does. I believe Loom's ScopeLocals could help to make the thread-local access part faster in the future as well. > > Jorn > >> On 17/02/2022 00:33, Rados?aw Smogura wrote: >> Hi, >> >> My understanding is that scope local is like parameter you can pass to function (but it?s passed like a global reference), and enforces closure (Autoclosable can?t enforce value to be put in try-with-resources, so stack can be incorrect if exceptions are not properly handled). >> >> However I think that everyone (or at least me) think about something like this: >> >> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc >> >> Kind regards, >> Rado >> On Feb 16, 2022, at 10:40 PM, Remi Forax wrote: >> >> ?----- Original Message ----- >> From: "Ioannis Tsakpinis" >> To: "Maurizio Cimadamore" >> Cc: "Felix Cravic" , "panama-dev at openjdk.java.net'" >> Sent: Wednesday, February 16, 2022 9:56:43 PM >> Subject: Re: Stack allocation API >> >> >> ... >> >> An issue with LWJGL's approach is the thread-local access to grab the >> current thread's MemoryStack. The thread-local lookup itself is not >> terribly expensive (but not free either), however it does become a problem >> in hot code. Hotspot cannot hoist it out of loops and this has unfortunate >> consequences for the surrounding code. >> >> I wonder how the ScopeLocal of loom behave compared to ThreadLocal. >> https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.concurrent/jdk/incubator/concurrent/ScopeLocal.html >> >> >> - Ioannis >> >> R?mi From vladimir.x.ivanov at oracle.com Thu Feb 17 14:45:23 2022 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 17 Feb 2022 17:45:23 +0300 Subject: Stack allocation API In-Reply-To: <50dc4776-1246-c897-b64b-ce68074d1a5d@oracle.com> References: <47d27a93-4f3e-2754-4e3d-8e9b27d8ca12@oracle.com> <1763924590.4591282.1645047535394.JavaMail.zimbra@u-pem.fr> <50dc4776-1246-c897-b64b-ce68074d1a5d@oracle.com> Message-ID: <36d4e375-9944-6bfd-19b0-5b5af7a4ad17@oracle.com> > This seems to be using the underlying OS thread stack to allocate > things? Note that we can not do the same in Java. We want Java thread > stacks to be freely copyable for Loom, which means we can't have > pointers into the thread's native stack. Strictly speaking, it is (and will be) allowed. Mixed thread stacks (single thread stack used for Java and native code) aren't going away any time soon. But native frames (and native resources/pointers) negatively affect Loom functionality and effectively pin virtual threads to OS threads (defeating the whole purpose of virtual threads). As was already pointed out, the topic was discussed multiple times and I still consider stack allocation overrated [1]. And Loom will make it even less attractive. FTR the referenced post [1] describes a way to implement stack allocation without any JVM assistance. It would be very helpful if somebody make such experiment and report their experience. Best regards, Vladimir Ivanov [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006752.html > A solution to this problems would be for instance to have a dedicated > thread-local side stack for the native allocations, which is not moved > around. This is essentially what the LWJGL MemoryStack does. I believe > Loom's ScopeLocals could help to make the thread-local access part > faster in the future as well. > > Jorn > > On 17/02/2022 00:33, Rados?aw Smogura wrote: >> Hi, >> >> My understanding is that scope local is like parameter you can pass to >> function (but it?s passed like a global reference), and enforces >> closure (Autoclosable can?t enforce value to be put in >> try-with-resources, so stack can be incorrect if exceptions are not >> properly handled). >> >> However I think that everyone (or at least me) think about something >> like this: >> >> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc >> >> >> Kind regards, >> Rado >> On Feb 16, 2022, at 10:40 PM, Remi Forax wrote: >> >> ?----- Original Message ----- >> From: "Ioannis Tsakpinis" >> To: "Maurizio Cimadamore" >> Cc: "Felix Cravic" , >> "panama-dev at openjdk.java.net'" >> Sent: Wednesday, February 16, 2022 9:56:43 PM >> Subject: Re: Stack allocation API >> >> >> ... >> >> An issue with LWJGL's approach is the thread-local access to grab the >> current thread's MemoryStack. The thread-local lookup itself is not >> terribly expensive (but not free either), however it does become a >> problem >> in hot code. Hotspot cannot hoist it out of loops and this has >> unfortunate >> consequences for the surrounding code. >> >> I wonder how the ScopeLocal of loom behave compared to ThreadLocal. >> https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.concurrent/jdk/incubator/concurrent/ScopeLocal.html >> >> >> >> - Ioannis >> >> R?mi From mcimadamore at openjdk.java.net Thu Feb 17 15:28:39 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 17 Feb 2022 15:28:39 GMT Subject: [foreign-preview] RFR: 8282026: Remove support for unbound sequence layouts Message-ID: When doing a pass over the memory layout API, I couldn't help noting that the API implementation and specification are made more complex by the fact that we have to specify what happens when a sequence layout *without a size* is found. Support for unbounded sequence layout was added many moons ago, with the understanding that it would have made life for jextract easier. This is not the case; all cases where jextract is using an unbounded sequence layout today can be replaced with using a simple zero-length sequence (which is allowed by the API, as are empty structs/unions). I also found that the only real use case for using unbounded sequence layout came from a quirk in the API to obtain var handles from layout. That is, if we want to obtain an indexed var handle into a JAVA_INT, we have to do the following: VarHandle intHandle = MemoryLayout.newSequenceLayout(JAVA_INT) .varHandle(PathElement.sequenceLayout()); In hindsight, this is just boilerplate: in this case the user only cares about the element layout (`JAVA_INT`), but the API wants the user to wrap that element layout in a new sequence layout, only to then provide a path inside the sequence layout (which will add a free dimension to the resulting var handle). It is not hard to see that all the above can be simplified, by adding an extra API method on memory layouts: VarHandle intHandle = JAVA_INT.arrayElementVarHandle(JAVA_INT); This more explicit, succint, and provdies less opportunities for bugs to hide. Therefore, this patch removes support for unbounded sequence element; the net effect is that now _all_ layouts have a size - which significantly simplifies the use sites where layout sizes are computed (no need to use optional there). All without losing much in terms of expressiveness: zero-length sequence layout can be used in basically the same way in which unbounded sequence layouts were used before. ------------- Commit messages: - Improve javadoc for arrayXYZHandle - Revert spurious changes to TestLayouts - Fix LayoutPath - Tweak javadoc - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/642/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=642&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282026 Stats: 315 lines in 36 files changed: 48 ins; 172 del; 95 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/642.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/642/head:pull/642 PR: https://git.openjdk.java.net/panama-foreign/pull/642 From mcimadamore at openjdk.java.net Thu Feb 17 16:32:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 17 Feb 2022 16:32:02 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes Message-ID: This patch improves the logic for closing shared resource scopes, by using the following algorithm: 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope 2. do an initial handshake, to collect all threads that are accessing the scope concurrently 3. if no thread is found, finish 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). ------------- Commit messages: - Fix whitespaces - Tweak ResourceScope javadoc - More cleanup: make close_scope return type be `void` - Add more code comments - Add comments, fix test - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/643/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282061 Stats: 90 lines in 5 files changed: 46 ins; 16 del; 28 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Thu Feb 17 19:12:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 17 Feb 2022 19:12:42 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation Message-ID: Following some preliminary experiments (see [1]) it is now finally time to drop the various workarounds we have in the memory segment implementation. This patch removes two workarounds: * special treatment for "small" segments (e.g. segments whose size fits in an int) - see `MemorySegment::isSmall`; these segments were special cased so that bound checks would only involve `int` comparisons. This has now been fixed in JDK-8276116, and special treatment is no longer required. * special shortcuts to avoid extra alignment checks. Since when generating var handles from a layout we check most of the alignment constraints (except those involving the base address), in the past we have added a fastpath for these var handles, as C2 had trouble hoisting alignment checks outside of the loops. This has now been fixed in JDK-8277850 and is no longer required. I have run benchmarks before and after and got identical results. Some benchmarkks in `ParallelSum` got a boost, but those always have noise, due to multi-threading. ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/644/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=644&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282070 Stats: 219 lines in 13 files changed: 12 ins; 107 del; 100 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/644.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/644/head:pull/644 PR: https://git.openjdk.java.net/panama-foreign/pull/644 From mcimadamore at openjdk.java.net Thu Feb 17 19:18:36 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 17 Feb 2022 19:18:36 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 19:07:12 GMT, Maurizio Cimadamore wrote: > Following some preliminary experiments (see [1]) it is now finally time to drop the various workarounds we have in the memory segment implementation. This patch removes two workarounds: > > * special treatment for "small" segments (e.g. segments whose size fits in an int) - see `MemorySegment::isSmall`; these segments were special cased so that bound checks would only involve `int` comparisons. This has now been fixed in JDK-8276116, and special treatment is no longer required. > > * special shortcuts to avoid extra alignment checks. Since when generating var handles from a layout we check most of the alignment constraints (except those involving the base address), in the past we have added a fastpath for these var handles, as C2 had trouble hoisting alignment checks outside of the loops. This has now been fixed in JDK-8277850 and is no longer required. > > I have run benchmarks before and after and got identical results. Some benchmarkks in `ParallelSum` got a boost, but those always have noise, due to multi-threading. src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 392: > 390: @ForceInline > 391: void checkBounds(long offset, long length) { > 392: if (length > 0) { This is the best I could do, given that `Objects.checkIndex` implements a <= semantics on the upper bound. That is, we need to protect the code from overflow, which can happen if `length == 0` (which can happen in slicing). When that happens, the upper bound in the second check `this.length - length + 1` ends up being `this.length + 1`, which is problematic. I've also tested to see if we could just use the old check bounds routine, but it seems that using `Objects.checkIndex` is required to properly apply BCE (I could see differences in the benchmark results). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From duke at openjdk.java.net Thu Feb 17 21:32:36 2022 From: duke at openjdk.java.net (Radoslaw Smogura) Date: Thu, 17 Feb 2022 21:32:36 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: Message-ID: <9YH0yd5e3j8fxmYL_h651tcxPnazPy3h5V4tI7Z6_Y8=.e170dc75-3ac8-4d00-af21-c06698965b82@github.com> On Thu, 17 Feb 2022 19:14:53 GMT, Maurizio Cimadamore wrote: >> Following some preliminary experiments (see [1]) it is now finally time to drop the various workarounds we have in the memory segment implementation. This patch removes two workarounds: >> >> * special treatment for "small" segments (e.g. segments whose size fits in an int) - see `MemorySegment::isSmall`; these segments were special cased so that bound checks would only involve `int` comparisons. This has now been fixed in JDK-8276116, and special treatment is no longer required. >> >> * special shortcuts to avoid extra alignment checks. Since when generating var handles from a layout we check most of the alignment constraints (except those involving the base address), in the past we have added a fastpath for these var handles, as C2 had trouble hoisting alignment checks outside of the loops. This has now been fixed in JDK-8277850 and is no longer required. >> >> I have run benchmarks before and after and got identical results. Some benchmarkks in `ParallelSum` got a boost, but those always have noise, due to multi-threading. > > src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 392: > >> 390: @ForceInline >> 391: void checkBounds(long offset, long length) { >> 392: if (length > 0) { > > This is the best I could do, given that `Objects.checkIndex` implements a <= semantics on the upper bound. That is, we need to protect the code from overflow, which can happen if `length == 0` (which can happen in slicing). When that happens, the upper bound in the second check `this.length - length + 1` ends up being `this.length + 1`, which is problematic. I've also tested to see if we could just use the old check bounds routine, but it seems that using `Objects.checkIndex` is required to properly apply BCE (I could see differences in the benchmark results). I think `Objects.checkIndex` checks if `length` && `offset` are negative, so there's no risk of overflow (actually it checks if `length` is negative, and then make unsigned compare), so maybe I miss here something. Just minor, I wonder if it will be better to use `Preconditions.checkIndex` - one method less to inline. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From mcimadamore at openjdk.java.net Thu Feb 17 21:52:37 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 17 Feb 2022 21:52:37 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: <9YH0yd5e3j8fxmYL_h651tcxPnazPy3h5V4tI7Z6_Y8=.e170dc75-3ac8-4d00-af21-c06698965b82@github.com> References: <9YH0yd5e3j8fxmYL_h651tcxPnazPy3h5V4tI7Z6_Y8=.e170dc75-3ac8-4d00-af21-c06698965b82@github.com> Message-ID: On Thu, 17 Feb 2022 21:26:02 GMT, Radoslaw Smogura wrote: >> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 392: >> >>> 390: @ForceInline >>> 391: void checkBounds(long offset, long length) { >>> 392: if (length > 0) { >> >> This is the best I could do, given that `Objects.checkIndex` implements a <= semantics on the upper bound. That is, we need to protect the code from overflow, which can happen if `length == 0` (which can happen in slicing). When that happens, the upper bound in the second check `this.length - length + 1` ends up being `this.length + 1`, which is problematic. I've also tested to see if we could just use the old check bounds routine, but it seems that using `Objects.checkIndex` is required to properly apply BCE (I could see differences in the benchmark results). > > I think `Objects.checkIndex` checks if `length` && `offset` are negative, so there's no risk of overflow (actually it checks if `length` is negative, and then make unsigned compare), so maybe I miss here something. > > Just minor, I wonder if it will be better to use `Preconditions.checkIndex` - one method less to inline. Consider a case of a segment whose length is Long.MAX_VALUE. Then you want to take a slice of size 0. This will throw an exception, as Long.MAX_VALUE + 1 will flip into negative territory. Another problem is when the segment has size zero, in which case the check: long checkedOffset = Objects.checkIndex(offset, this.length); Will also fail. To make that pass we'd need to tweak that check to use `this.length + 1` again, and risk overflow. So I figured it was better just just special case when the accessed length was zero (which should happen rarely). Another option would be to have different checks for slicing and for access (since for access length can never be zero) - but then it duplicates the implementation, and there are also methods like `copy` which are left a bit in the middle. As for inlining, I doubt that it would make a difference to call Preconditions directly, since it's all `@ForceInline`d. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From duke at openjdk.java.net Thu Feb 17 22:26:08 2022 From: duke at openjdk.java.net (Radoslaw Smogura) Date: Thu, 17 Feb 2022 22:26:08 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: <9YH0yd5e3j8fxmYL_h651tcxPnazPy3h5V4tI7Z6_Y8=.e170dc75-3ac8-4d00-af21-c06698965b82@github.com> Message-ID: On Thu, 17 Feb 2022 21:48:49 GMT, Maurizio Cimadamore wrote: >> I think `Objects.checkIndex` checks if `length` && `offset` are negative, so there's no risk of overflow (actually it checks if `length` is negative, and then make unsigned compare), so maybe I miss here something. >> >> Just minor, I wonder if it will be better to use `Preconditions.checkIndex` - one method less to inline. > > Consider a case of a segment whose length is Long.MAX_VALUE. Then you want to take a slice of size 0. This will throw an exception, as Long.MAX_VALUE + 1 will flip into negative territory. > > Another problem is when the segment has size zero, in which case the check: > > > long checkedOffset = Objects.checkIndex(offset, this.length); > > > Will also fail. To make that pass we'd need to tweak that check to use `this.length + 1` again, and risk overflow. So I figured it was better just just special case when the accessed length was zero (which should happen rarely). Another option would be to have different checks for slicing and for access (since for access length can never be zero) - but then it duplicates the implementation, and there are also methods like `copy` which are left a bit in the middle. > > As for inlining, I doubt that it would make a difference to call Preconditions directly, since it's all `@ForceInline`d. I get it, it's to allow creating 0-length chunks (I've thought in context of reading value). If we assume `length > 0`, then `this.length - length + 1 =< this.length`, (in case `this.len == 0 -> 0 <= 0`) ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From jvernee at openjdk.java.net Thu Feb 17 22:35:13 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 17 Feb 2022 22:35:13 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 19:07:12 GMT, Maurizio Cimadamore wrote: > Following some preliminary experiments (see [1]) it is now finally time to drop the various workarounds we have in the memory segment implementation. This patch removes two workarounds: > > * special treatment for "small" segments (e.g. segments whose size fits in an int) - see `MemorySegment::isSmall`; these segments were special cased so that bound checks would only involve `int` comparisons. This has now been fixed in JDK-8276116, and special treatment is no longer required. > > * special shortcuts to avoid extra alignment checks. Since when generating var handles from a layout we check most of the alignment constraints (except those involving the base address), in the past we have added a fastpath for these var handles, as C2 had trouble hoisting alignment checks outside of the loops. This has now been fixed in JDK-8277850 and is no longer required. > > I have run benchmarks before and after and got identical results. Some benchmarkks in `ParallelSum` got a boost, but those always have noise, due to multi-threading. Marked as reviewed by jvernee (Committer). src/java.base/share/classes/jdk/internal/foreign/Utils.java line 155: > 153: > 154: @ForceInline > 155: public static long scaleOffset(MemorySegment segment, long index, long size) { Seems like this method is pretty redundant now, and users can just do `index * size`? (at least I think the segment parameter could be dropped). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From duke at openjdk.java.net Thu Feb 17 22:46:13 2022 From: duke at openjdk.java.net (Radoslaw Smogura) Date: Thu, 17 Feb 2022 22:46:13 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: <9YH0yd5e3j8fxmYL_h651tcxPnazPy3h5V4tI7Z6_Y8=.e170dc75-3ac8-4d00-af21-c06698965b82@github.com> Message-ID: On Thu, 17 Feb 2022 22:05:24 GMT, Radoslaw Smogura wrote: >> Consider a case of a segment whose length is Long.MAX_VALUE. Then you want to take a slice of size 0. This will throw an exception, as Long.MAX_VALUE + 1 will flip into negative territory. >> >> Another problem is when the segment has size zero, in which case the check: >> >> >> long checkedOffset = Objects.checkIndex(offset, this.length); >> >> >> Will also fail. To make that pass we'd need to tweak that check to use `this.length + 1` again, and risk overflow. So I figured it was better just just special case when the accessed length was zero (which should happen rarely). Another option would be to have different checks for slicing and for access (since for access length can never be zero) - but then it duplicates the implementation, and there are also methods like `copy` which are left a bit in the middle. >> >> As for inlining, I doubt that it would make a difference to call Preconditions directly, since it's all `@ForceInline`d. > > I get it, it's to allow creating 0-length chunks (I've thought in context of reading value). > > If we assume `length > 0`, then `this.length - length + 1 =< this.length`, (in case `this.len == 0 -> 0 <= 0`) I'm not sure if I missed some case, but if it's in if (`length > 0`), then one `checkIndex` is redundant? Unless we want to disallow slicing 0 length indices? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From svkamath at openjdk.java.net Thu Feb 17 22:50:16 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Thu, 17 Feb 2022 22:50:16 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v3] In-Reply-To: References: Message-ID: > 8281562:[vectorapi] Add support for popcount operation Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Fixed operation name in vectorSupport.cpp and .hpp file ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/173/files - new: https://git.openjdk.java.net/panama-vector/pull/173/files/f594bea9..00c42cd4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-vector/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/173/head:pull/173 PR: https://git.openjdk.java.net/panama-vector/pull/173 From sviswanathan at openjdk.java.net Thu Feb 17 22:57:22 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 17 Feb 2022 22:57:22 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v3] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 22:50:16 GMT, Smita Kamath wrote: >> 8281562:[vectorapi] Add support for popcount operation > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Fixed operation name in vectorSupport.cpp and .hpp file Marked as reviewed by sviswanathan (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From duke at openjdk.java.net Thu Feb 17 23:43:13 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 17 Feb 2022 23:43:13 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 17:32:50 GMT, Maurizio Cimadamore wrote: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 305: > 303: * {@return a non-closeable view of the memory session associated with this memory segment} > 304: */ > 305: MemorySession session(); Hi, could we take advantage of the type system and return a MemorySessionView which does not have a close method on it. Thanks. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From svkamath at openjdk.java.net Fri Feb 18 02:52:06 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 18 Feb 2022 02:52:06 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v4] In-Reply-To: References: Message-ID: > 8281562:[vectorapi] Add support for popcount operation Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Adding bitCount support for byte and short types. Added test case in the test framework ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/173/files - new: https://git.openjdk.java.net/panama-vector/pull/173/files/00c42cd4..b97d4941 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=02-03 Stats: 1166 lines in 71 files changed: 1165 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/173/head:pull/173 PR: https://git.openjdk.java.net/panama-vector/pull/173 From duke at openjdk.java.net Fri Feb 18 05:54:04 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Fri, 18 Feb 2022 05:54:04 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: <9YH0yd5e3j8fxmYL_h651tcxPnazPy3h5V4tI7Z6_Y8=.e170dc75-3ac8-4d00-af21-c06698965b82@github.com> Message-ID: On Thu, 17 Feb 2022 22:42:46 GMT, Radoslaw Smogura wrote: >> I get it, it's to allow creating 0-length chunks (I've thought in context of reading value). >> >> If we assume `length > 0`, then `this.length - length + 1 =< this.length`, (in case `this.len == 0 -> 0 <= 0`) > > I'm not sure if I missed some case, but if it's in if (`length > 0`), then one `checkIndex` is redundant? Unless we want to disallow slicing 0 length indices? Is this similar to `Objects.checkFromIndexSize`? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From mcimadamore at openjdk.java.net Fri Feb 18 09:59:14 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 09:59:14 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: Message-ID: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> On Thu, 17 Feb 2022 23:39:55 GMT, Quan Anh Mai wrote: >> This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html >> [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 305: > >> 303: * {@return a non-closeable view of the memory session associated with this memory segment} >> 304: */ >> 305: MemorySession session(); > > Hi, could we take advantage of the type system and return a MemorySessionView which does not have a close method on it. Thanks. This is a possibility which we have explored. In the end we decided against it because we felt splitting session/scope in two would have had a negative effect on API discoverability. Note that non-closeable sessions are not just used for e.g. `MemorySegment::session`, but they are also returned by `MemorySession::global` and `MemorySession::openImplicit`. If we ever do *structured* sessions (e.g. session that give access to any threads that inherit a given Loom scope local), then it is likely that these sessions will be non-closeable too. Also, you would need to replace most API methods accepting MemorySession with MemorySessionView - and add a subtyping relationhip between MemorySessionView and MemorySession (so that you can pass a MemorySession where a view is expected). Ultimately that all felt a bit too much. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Fri Feb 18 10:06:59 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 10:06:59 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: <9YH0yd5e3j8fxmYL_h651tcxPnazPy3h5V4tI7Z6_Y8=.e170dc75-3ac8-4d00-af21-c06698965b82@github.com> Message-ID: <8HLlkxpCBtDnvnCVrvJbY-sEHLp85qiqn4YeZU0wyuE=.ac69e0a8-c436-4595-b070-85495e53afc8@github.com> On Thu, 17 Feb 2022 22:42:46 GMT, Radoslaw Smogura wrote: >> I get it, it's to allow creating 0-length chunks (I've thought in context of reading value). >> >> If we assume `length > 0`, then `this.length - length + 1 =< this.length`, (in case `this.len == 0 -> 0 <= 0`) > > I'm not sure if I missed some case, but if it's in if (`length > 0`), then one `checkIndex` is redundant? Unless we want to disallow slicing 0 length indices? @rsmogura you are correct, the extra check is redundant now - we only need the second. I probably added before I had the check for `length > 0` and then left that there. Effectively, the second check is enough, because that checks that `offset >= 0`, and `length > 0` by construction (and we now that segment size must be `>= 0`). So I believe we should be ok. @merykitty yes, this is implementing the same check in spirit as `checkFromIndexSize` - but unfortunately that is not a VM intrinsics, so we have to code around that. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From mcimadamore at openjdk.java.net Fri Feb 18 10:12:20 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 10:12:20 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> References: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> Message-ID: On Fri, 18 Feb 2022 09:56:05 GMT, Maurizio Cimadamore wrote: > Ultimately that all felt a bit too much. To be clear, it felt too much not because the refactoring was complex (it was not) but because this creates a problem of how do you name the non-closeable entity (`MemorySessionView` is fine when returned by `MemorySegment::session`, less fine when accepted by `MemorySegment::allocateNative`). And if you give it a more general name, then you end up with two abstractions fighting for API visibility. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Fri Feb 18 10:14:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 10:14:34 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation [v2] In-Reply-To: References: Message-ID: > Following some preliminary experiments (see [1]) it is now finally time to drop the various workarounds we have in the memory segment implementation. This patch removes two workarounds: > > * special treatment for "small" segments (e.g. segments whose size fits in an int) - see `MemorySegment::isSmall`; these segments were special cased so that bound checks would only involve `int` comparisons. This has now been fixed in JDK-8276116, and special treatment is no longer required. > > * special shortcuts to avoid extra alignment checks. Since when generating var handles from a layout we check most of the alignment constraints (except those involving the base address), in the past we have added a fastpath for these var handles, as C2 had trouble hoisting alignment checks outside of the loops. This has now been fixed in JDK-8277850 and is no longer required. > > I have run benchmarks before and after and got identical results. Some benchmarkks in `ParallelSum` got a boost, but those always have noise, due to multi-threading. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments: * inlined Utils::scaleOffset into callsites * drop redundant check from AbstractMemorySegment::checkBounds ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/644/files - new: https://git.openjdk.java.net/panama-foreign/pull/644/files/ea2d79ec..a5fbef94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=644&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=644&range=00-01 Stats: 36 lines in 3 files changed: 14 ins; 7 del; 15 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/644.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/644/head:pull/644 PR: https://git.openjdk.java.net/panama-foreign/pull/644 From duke at openjdk.java.net Fri Feb 18 10:40:01 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Fri, 18 Feb 2022 10:40:01 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> Message-ID: On Fri, 18 Feb 2022 10:08:18 GMT, Maurizio Cimadamore wrote: >> This is a possibility which we have explored. In the end we decided against it because we felt splitting session/scope in two would have had a negative effect on API discoverability. Note that non-closeable sessions are not just used for e.g. `MemorySegment::session`, but they are also returned by `MemorySession::global` and `MemorySession::openImplicit`. If we ever do *structured* sessions (e.g. session that give access to any threads that inherit a given Loom scope local), then it is likely that these sessions will be non-closeable too. >> >> Also, you would need to replace most API methods accepting MemorySession with MemorySessionView - and add a subtyping relationhip between MemorySessionView and MemorySession (so that you can pass a MemorySession where a view is expected). Ultimately that all felt a bit too much. > >> Ultimately that all felt a bit too much. > > To be clear, it felt too much not because the refactoring was complex (it was not) but because this creates a problem of how do you name the non-closeable entity (`MemorySessionView` is fine when returned by `MemorySegment::session`, less fine when accepted by `MemorySegment::allocateNative`). And if you give it a more general name, then you end up with two abstractions fighting for API visibility. I see, rethinking about it, the reason to add a `session` accessor to `MemorySegment` was to properly bind the lifetime of an **allocated** segment to an existing one and to correctly observe that lifetime. It sounds like the functionality of an allocator to me. Maybe we could instead return a `SegmentAllocator` instead (and change `MemorySession` to `SegmentDeallocator` probably) and extend the functionality of a `SegmentAllocator` to check the validity of its associating `MemorySession`. Even if it is not the case we would need to check the state of a `SegmentAllocator` anyway to ensure that we can allocate memory with it. Thanks. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Fri Feb 18 10:55:06 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 10:55:06 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> Message-ID: On Fri, 18 Feb 2022 10:36:52 GMT, Quan Anh Mai wrote: >>> Ultimately that all felt a bit too much. >> >> To be clear, it felt too much not because the refactoring was complex (it was not) but because this creates a problem of how do you name the non-closeable entity (`MemorySessionView` is fine when returned by `MemorySegment::session`, less fine when accepted by `MemorySegment::allocateNative`). And if you give it a more general name, then you end up with two abstractions fighting for API visibility. > > I see, rethinking about it, the reason to add a `session` accessor to `MemorySegment` was to properly bind the lifetime of an **allocated** segment to an existing one and to correctly observe that lifetime. It sounds like the functionality of an allocator to me. Maybe we could instead return a `SegmentAllocator` instead (and change `MemorySession` to `SegmentDeallocator` probably) and extend the functionality of a `SegmentAllocator` to check the validity of its associating `MemorySession`. Even if it is not the case we would need to check the state of a `SegmentAllocator` anyway to ensure that we can allocate memory with it. > Thanks. That option was also considered, but discarded because it would make `SegmentAllocator` stateful, e.g. more complex than just a functional interface. Right now it is pretty easy to define a new allocator - but if the allocator has to track lifetime, it becomes harder to define custom ones. Also, saying that, to create an upcall stub you need a `SegmentAllocator`, or that to create an unsafe segment view of a memory address (`MemorySegment::ofAddress`) you need an allocator, is a bit odd - in the sense that you don't really need allocation capabilities there - you just need some kind of lifetime abstraction. So, I think the "allocation" angle is valid in most cases, but I think that it only works well for native segments and doesn't really generalize to _all_ segments - unsafe views, memory mapped segments, heap segments, etc. I think separating lifecycle from allocation was a really powerful move, which paid off considerably. Having a single allocator abstraction perform double duty seems a step backwards IMHO. > I see, rethinking about it, the reason to add a `session` accessor to `MemorySegment` was to properly bind the lifetime of an **allocated** segment to an existing one and to correctly observe that lifetime. It sounds like the functionality of an allocator to me. Maybe we could instead return a `SegmentAllocator` instead (and change `MemorySession` to `SegmentDeallocator` probably) and extend the functionality of a `SegmentAllocator` to check the validity of its associating `MemorySession`. Even if it is not the case we would need to check the state of a `SegmentAllocator` anyway to ensure that we can allocate memory with it. Thanks. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Fri Feb 18 11:03:13 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 11:03:13 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> Message-ID: On Fri, 18 Feb 2022 10:51:49 GMT, Maurizio Cimadamore wrote: > hat option was also considered, but discarded because it would make `SegmentAllocator` stateful, e.g. more complex than just a functional interface. Note that today there is no contract which says that all segments returned by a `SegmentAllocator` must have the same session. While some allocators might behave like that, I think it would not be ok to force that behavior on _all_ allocators. And, we considered to add, perhaps in the future, some small subinterface, like `ScopedSegmentAllocator` which also has a `session` accessor - this would be a good return type for the arena allocator methods, for instance. But this is a move that is orthogonal to the changes described in this PR (and also not a binding one - we can add the sub-interface even at a later point w/o breaking compatibility). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From duke at openjdk.java.net Fri Feb 18 11:07:22 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 18 Feb 2022 11:07:22 GMT Subject: [foreign-preview] RFR: Merge master Message-ID: Hi all, this is an _automatically_ generated pull request to notify you that there are 91 commits from the branch `master`that can **not** be merged into the branch `foreign-preview`: The following file contains merge conflicts: - src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. # Ensure target branch is up to date $ git checkout foreign-preview $ git pull https://github.com/openjdk/panama-foreign.git foreign-preview # Fetch and checkout the branch for this pull request $ git fetch https://github.com/openjdk-bot/panama-foreign.git +114:openjdk-bot-114 $ git checkout openjdk-bot-114 # Merge the target branch $ git merge foreign-preview When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: $ git add paths/to/files/with/conflicts $ git commit -m 'Merge master' When you have created the merge commit, run the following command to push the merge commit to this pull request: $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-114:114 _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. Thanks, J. Duke ------------- Commit messages: - Automatic merge of jdk:master into master - 8282089: [BACKOUT] Parallel: Refactor PSCardTable::scavenge_contents_parallel - 8277300: Issues with javadoc support for preview features - 8281267: VM HeapDumper dumps array classes several times - 8279068: IGV: Update to work with JDK 16 and 17 - 8281936: compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines - 8037573: Typo in DefaultTreeModel docs: askAllowsChildren instead of asksAllowsChildren - 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732 - 8188073: Add Capstone as backend for hsdis - 8282075: ProblemList 3 compiler/whitebox tests on macosx-x64 - ... and 81 more: https://git.openjdk.java.net/panama-foreign/compare/2d985cd7...cd3b60d5 The webrev contains the conflicts with foreign-preview: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=645&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/645/files Stats: 12148 lines in 384 files changed: 8665 ins; 1981 del; 1502 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/645.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/645/head:pull/645 PR: https://git.openjdk.java.net/panama-foreign/pull/645 From duke at openjdk.java.net Fri Feb 18 11:07:43 2022 From: duke at openjdk.java.net (duke) Date: Fri, 18 Feb 2022 11:07:43 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 93 new changesets Message-ID: Changeset: d254cf28 Author: Jie Fu Date: 2022-02-11 11:39:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d254cf28c5e72bd9b8de863b831015237640ca25 8281638: jfr/event/allocation tests fail with release VMs after JDK-8281318 due to lack of -XX:+UnlockDiagnosticVMOptions Reviewed-by: shade ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationInNewTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationOutsideTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventThrottling.java Changeset: 4ff5824f Author: Jan Lahoda Date: 2022-02-11 12:11:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ff5824f5bc13826d2eae1c83094acfcccdb7b8f 8281100: Spurious "variable might not have been initialized" with sealed class switch Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: f399ae55 Author: lawrence.andrews Committer: Alexey Ivanov Date: 2022-02-11 15:33:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f399ae558eabdce8960d339ef0758c023aeb89cc 8202836: [macosx] test java/awt/Graphics/TextAAHintsTest.java fails Reviewed-by: prr, aivanov ! test/jdk/java/awt/Graphics/TextAAHintsTest.java Changeset: e73ee0ca Author: Daniel Jeli?ski Committer: Brian Burkhalter Date: 2022-02-11 16:24:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e73ee0ca10b644600ee3747b901e5f69104d03df 8281259: MutableBigInteger subtraction could be simplified Reviewed-by: bpb ! src/java.base/share/classes/java/math/MutableBigInteger.java ! test/micro/org/openjdk/bench/java/math/BigIntegers.java Changeset: e75e8cd7 Author: Yumin Qi Date: 2022-02-11 16:42:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e75e8cd708ed478eda08c4a5c724e7e82f57d36e 8279997: check_for_dynamic_dump should not exit vm Reviewed-by: ccheung, iklam ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java Changeset: 88868397 Author: Erik Gahlin Date: 2022-02-11 17:15:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8886839779094f8a13c16be79f88052b2c79eeea 8281622: JFR: Improve documentation of jdk.jfr.Relational Reviewed-by: jbachorik ! src/jdk.jfr/share/classes/jdk/jfr/Relational.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: c5ff6e45 Author: Calvin Cheung Date: 2022-02-11 17:39:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ff6e45dee41b5703138d323a04c2c7973a08b9 8223077: module path support for dynamic CDS archive Reviewed-by: iklam, minqi ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/runtime/arguments.hpp ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ModulePath.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/UnsupportedBaseArchive.java Changeset: 0786ddb4 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-11 17:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0786ddb4712296c90df2c9e97c76c203a4de4612 8281535: Create a regression test for JDK-4670051 Reviewed-by: aivanov + test/jdk/javax/swing/JSpinner/4670051/DateFieldUnderCursorTest.java Changeset: 83ffbd2e Author: Dr Heinz M. Kabutz Committer: Paul Sandoz Date: 2022-02-11 18:49:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83ffbd2e7aed8a9c788395ccbe920ddff221ae16 8277175: Add a parallel multiply method to BigInteger Reviewed-by: psandoz ! src/java.base/share/classes/java/math/BigInteger.java + test/jdk/java/math/BigInteger/BigIntegerParallelMultiplyTest.java + test/micro/org/openjdk/bench/java/math/BigIntegerMersennePrimeMultiply.java + test/micro/org/openjdk/bench/java/math/BigIntegerParallelMultiply.java Changeset: 4032fe76 Author: Joe Darcy Date: 2022-02-11 21:52:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4032fe76dccb6da85927361aee7ceedcdb758e89 8281238: TYPE_USE annotations not printed in correct position in toString output Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! test/langtools/tools/javac/patterns/Annotations.java ! test/langtools/tools/javac/tree/ArrayTypeToString.java ! test/langtools/tools/javac/tree/ArrayTypeToString.out Changeset: c3179a87 Author: Joe Darcy Date: 2022-02-11 23:24:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3179a8760019b5954e344bf0d2775e1e1968f32 8281462: Annotation toString output for enum not reusable for source input Reviewed-by: mchung ! src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! test/jdk/java/lang/annotation/AnnotationToStringTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/EnumTypeMismatchTest.java ! test/jdk/java/lang/annotation/TestConstructorParameterAnnotations.java ! test/jdk/java/lang/annotation/typeAnnotations/GetAnnotatedNestedSuperclass.java ! test/jdk/java/lang/annotation/typeAnnotations/TestConstructorParameterTypeAnnotations.java ! test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java ! test/jdk/java/lang/reflect/records/RecordReflectionTest.java Changeset: 6fdfe045 Author: Joe Darcy Date: 2022-02-12 01:33:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6fdfe0458df989a7946b4f52a3023e8a39fb3bbb 8281674: tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java fails with AssertionError Reviewed-by: vromero ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java Changeset: aa918a6e Author: Alexander Zuev Date: 2022-02-12 09:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa918a6ec4cd1356efd481c6f6fa94959f94f7b3 8281033: Improve ImageCheckboxTest to test all available LaF Reviewed-by: serb ! test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java Changeset: 58dae60d Author: Alexey Bakhtin Date: 2022-02-12 11:54:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58dae60da0711c4ae0cb23f8ce2328e051d603b2 8274524: SSLSocket.close() hangs if it is called during the ssl handshake Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java + test/jdk/sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java Changeset: 67077a04 Author: Emanuel Peter Committer: David Holmes Date: 2022-02-12 13:08:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67077a04307b512219a46b6c4c274ce308ee46de 8278423: ExtendedDTraceProbes should be deprecated Reviewed-by: dholmes, hseigel, kvn, thartmann ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/man/java.1 ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java Changeset: 8acfbc2e Author: David Holmes Date: 2022-02-12 14:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8acfbc2e21063c3dc088c25c1574bcefa94e5a24 8281675: VMDeprecatedOptions test fails after JDK-8278423 Reviewed-by: dcubed ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: eff5dafb Author: Sergey Bylokhov Date: 2022-02-12 22:10:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eff5dafba9f72bd0612357712ffa472ce1c9166a 8274939: Incorrect size of the pixel storage is used by the robot on macOS Reviewed-by: aivanov, prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! test/jdk/java/awt/Robot/CheckCommonColors/CheckCommonColors.java Changeset: adbe0661 Author: Bhavana Kilambi Committer: Ningsheng Jian Date: 2022-02-14 01:33:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/adbe0661029f12a36a44af52b83b189384d33a27 8239927: Product variable PrefetchFieldsAhead is unused and should be removed Reviewed-by: njian, dholmes ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 483d4b97 Author: Nils Eliasson Date: 2022-02-14 08:27:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/483d4b97e0ae4ab7b0d87058901f57688a0f0811 8281505: Add CompileCommand PrintIdealPhase Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/compiler/directivesParser.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/phasetype.hpp + test/hotspot/jtreg/compiler/oracle/PrintIdealPhaseTest.java Changeset: 1ef45c5b Author: Roland Westrelin Date: 2022-02-14 08:35:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ef45c5bbdeb4e1ca65c6d8f3ac1568a6951f3a7 8280799: ?2: assert(false) failed: cyclic dependency prevents range check elimination Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/loopopts/TestPredicateInputBelowLoopPredicate.java Changeset: 46f52296 Author: Roberto Casta?eda Lozano Date: 2022-02-14 08:37:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46f522962f1b2bbb2513823821e332db1093994b 8281539: IGV: schedule approximation computes immediate dominators wrongly Replace custom dominator computation with one from the WALA libraries. Reviewed-by: neliasso, chagedorn ! src/utils/IdealGraphVisualizer/ServerCompiler/pom.xml ! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java ! src/utils/IdealGraphVisualizer/pom.xml Changeset: 2632d40d Author: Stefan Johansson Date: 2022-02-14 09:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2632d40dfc9f681e53fe04d32b6380ffb4eeb88c 8281637: Remove unused VerifyOption_G1UseNextMarking Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/shared/verifyOption.hpp Changeset: 25972062 Author: Albert Mingkun Yang Date: 2022-02-14 09:15:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2597206242356d42ca5d08be809cfdff79df924d 8280783: Parallel: Refactor PSCardTable::scavenge_contents_parallel Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/parallel/psCardTable.cpp ! src/hotspot/share/gc/parallel/psCardTable.hpp Changeset: c61d629a Author: Emanuel Peter Committer: Christian Hagedorn Date: 2022-02-14 09:52:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 8281553: Ensure we only require liveness from mach-nodes with barriers Reviewed-by: neliasso, chagedorn ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp Changeset: 95f198b2 Author: Magnus Ihse Bursie Date: 2022-02-14 10:31:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95f198b2b1b2d5437515dc837cc160e4224c0ff3 8274980: Improve adhoc build version strings Reviewed-by: shade, erikj ! .github/workflows/submit.yml ! make/Docs.gmk ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/hotspot/lib/CompileJvm.gmk ! test/jdk/java/lang/RuntimeTests/Version/Basic.java ! test/langtools/tools/javac/options/modes/InfoOptsTest.java Changeset: 534e5578 Author: Vladimir Ivanov Date: 2022-02-14 11:57:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/534e557874274255c55086b4f6128063cbd9cc58 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers Reviewed-by: dlong, kvn ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/interpreter/bootstrapInfo.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! test/jdk/ProblemList-Xcomp.txt Changeset: 2604a88f Author: Leo Korinth Date: 2022-02-14 12:05:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2604a88fbb6d0f9aec51c7d607ea275bc34a672c 8281585: Remove unused imports under test/lib and jtreg/gc Reviewed-by: dholmes, sspitsyn ! test/hotspot/jtreg/gc/TestAllocateHeapAt.java ! test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java ! test/hotspot/jtreg/gc/TestCardTablePageCommits.java ! test/hotspot/jtreg/gc/TestSmallHeap.java ! test/hotspot/jtreg/gc/arguments/TestAggressiveHeap.java ! test/hotspot/jtreg/gc/arguments/TestArrayAllocatorMallocLimit.java ! test/hotspot/jtreg/gc/arguments/TestCompressedClassFlags.java ! test/hotspot/jtreg/gc/arguments/TestG1ConcMarkStepDurationMillis.java ! test/hotspot/jtreg/gc/arguments/TestG1ConcRefinementThreads.java ! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java ! test/hotspot/jtreg/gc/arguments/TestG1PercentageOptions.java ! test/hotspot/jtreg/gc/arguments/TestG1RemSetFlags.java ! test/hotspot/jtreg/gc/arguments/TestHeapFreeRatio.java ! test/hotspot/jtreg/gc/arguments/TestInitialTenuringThreshold.java ! test/hotspot/jtreg/gc/arguments/TestMaxHeapSizeTools.java ! test/hotspot/jtreg/gc/arguments/TestMaxMinHeapFreeRatioFlags.java ! test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java ! test/hotspot/jtreg/gc/arguments/TestMaxRAMFlags.java ! test/hotspot/jtreg/gc/arguments/TestMinAndInitialSurvivorRatioFlags.java ! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestNewSizeFlags.java ! test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java ! test/hotspot/jtreg/gc/arguments/TestObjectTenuringFlags.java ! test/hotspot/jtreg/gc/arguments/TestParallelGCThreads.java ! test/hotspot/jtreg/gc/arguments/TestSelectDefaultGC.java ! test/hotspot/jtreg/gc/arguments/TestSmallInitialHeapWithLargePageAndNUMA.java ! test/hotspot/jtreg/gc/arguments/TestSurvivorRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestUnrecognizedVMOptionsHandling.java ! test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsErgoTools.java ! test/hotspot/jtreg/gc/arguments/TestUseNUMAInterleaving.java ! test/hotspot/jtreg/gc/arguments/TestVerifyBeforeAndAfterGCFlags.java ! test/hotspot/jtreg/gc/epsilon/TestClasses.java ! test/hotspot/jtreg/gc/g1/TestEvacuationFailure.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData.java ! test/hotspot/jtreg/gc/g1/TestSkipRebuildRemsetPhase.java ! test/hotspot/jtreg/gc/stress/gclocker/TestExcessGCLockerCollections.java ! test/lib/RedefineClassHelper.java ! test/lib/jdk/test/lib/OSVersion.java ! test/lib/jdk/test/lib/Utils.java ! test/lib/jdk/test/lib/apps/LingeredApp.java ! test/lib/jdk/test/lib/artifacts/ArtifactManager.java ! test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java ! test/lib/jdk/test/lib/containers/docker/Common.java ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java ! test/lib/jdk/test/lib/format/ArrayCodec.java ! test/lib/jdk/test/lib/format/ArrayDiff.java ! test/lib/jdk/test/lib/helpers/ClassFileInstaller.java ! test/lib/jdk/test/lib/hexdump/ObjectStreamPrinter.java ! test/lib/jdk/test/lib/hprof/model/JavaObjectArray.java ! test/lib/jdk/test/lib/hprof/model/JavaThing.java ! test/lib/jdk/test/lib/hprof/model/JavaValueArray.java ! test/lib/jdk/test/lib/hprof/model/ReachableExcludesImpl.java ! test/lib/jdk/test/lib/hprof/model/ReachableObjects.java ! test/lib/jdk/test/lib/hprof/util/ArraySorter.java ! test/lib/jdk/test/lib/hprof/util/Misc.java ! test/lib/jdk/test/lib/security/KeyStoreUtils.java ! test/lib/jdk/test/lib/security/timestamp/DefaultRespInterceptor.java ! test/lib/jdk/test/lib/security/timestamp/TsaHandler.java ! test/lib/jdk/test/lib/security/timestamp/TsaServer.java ! test/lib/jdk/test/lib/util/JavaAgentBuilder.java Changeset: 9d0a4c3f Author: Brian J. Stafford Committer: Thomas Schatzl Date: 2022-02-14 12:20:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d0a4c3f2e347c30ff56ba1416c08cc662f7f23c 8274238: Inconsistent type for young_list_target_length() Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1Policy.hpp Changeset: f07b8165 Author: Thomas Stuefe Date: 2022-02-14 16:41:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f07b8165231799383303e5c0755d07afd2feb7fd 8280940: gtest os.release_multi_mappings_vm is racy Reviewed-by: dcubed, sjohanss ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 88fc3bfd Author: Vladimir Ivanov Date: 2022-02-14 18:46:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/88fc3bfdff7f89a02fcfb16909df144e6173c658 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant pool entries Reviewed-by: dlong, redestad, neliasso ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_InstructionPrinter.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/opto/parse2.cpp + test/hotspot/jtreg/compiler/runtime/TestConstantDynamic.java ! test/hotspot/jtreg/compiler/runtime/TestConstantsInError.java Changeset: 16f649b9 Author: Ioi Lam Date: 2022-02-14 18:53:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16f649b9c5b480d2a8499b1a92939cdf53ecc8dc 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails after JDK-8279997 Reviewed-by: shade, dcubed ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java Changeset: 1a7b70a8 Author: Phil Race Date: 2022-02-14 23:31:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1a7b70a8be0a236b98925a8320d25d88a405d595 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4 Reviewed-by: serb ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java ! test/jdk/javax/sound/sampled/Clip/SetPositionHang.java Changeset: d4cd8dfe Author: Jaikiran Pai Date: 2022-02-15 03:53:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4cd8dfedbe220fb3b9a68650aba90536e9b12ee 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters Reviewed-by: dfuchs, naoto, mchung ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! test/langtools/tools/jdeps/Options.java Changeset: f33329eb Author: Harshitha Onkar Committer: Prasanta Sadhukhan Date: 2022-02-15 05:03:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f33329eb7f7a1a541d8f30ba8952b0b922ac5257 8016524: [macosx] Bottom line is not visible for JTableHeader Reviewed-by: psadhukhan, prr ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java + test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java Changeset: b1564624 Author: Aleksey Shipilev Date: 2022-02-15 06:19:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b1564624ce454d0df9b2464424b7b5e449481ee6 8281467: Allow larger OptoLoopAlignment and CodeEntryAlignment Reviewed-by: kvn, dlong ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/globals.hpp + test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java + test/hotspot/jtreg/compiler/arguments/TestOptoLoopAlignment.java Changeset: 11f943d1 Author: Kim Barrett Date: 2022-02-15 06:51:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11f943d148e7bc8d931c382ff019b3e65a87432e 8280916: Simplify HotSpot Style Guide editorial changes Reviewed-by: dcubed, dholmes, stuefe, stefank, kvn, tschatzl ! doc/hotspot-style.html ! doc/hotspot-style.md Changeset: 622970e4 Author: Andrey Turbanov Date: 2022-02-15 07:10:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/622970e47cedd6e0b94b74235aa984ad79281389 8281728: Redundant null check in LineNumberInputStream.read Reviewed-by: redestad ! src/java.base/share/classes/java/io/LineNumberInputStream.java Changeset: 8819f453 Author: Nils Eliasson Date: 2022-02-15 08:20:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8819f4535743f6504b4aaa62c7d87926dd1b0013 8281722: Removal of PrintIdealLevel Reviewed-by: chagedorn, thartmann ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: f82866bc Author: Dmitry Markov Date: 2022-02-15 09:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f82866bc79cbeeac23716fa6fadd4877f5d0a462 8281555: [macos] Get rid of deprecated Style Masks constants Reviewed-by: serb, aivanov ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m ! test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java Changeset: 1c12b159 Author: Nils Eliasson Date: 2022-02-15 09:49:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c12b159ffcbb3528a20ac585d8460bf730e303d 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp Reviewed-by: kvn, chagedorn, thartmann ! test/hotspot/jtreg/compiler/oracle/PrintIdealPhaseTest.java Changeset: 2112a9dc Author: Magnus Ihse Bursie Date: 2022-02-15 11:11:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2112a9dc49a41e11433f19d258d72806b321106c 8246033: bin/print_config.js script uses nashorn jjs tool Reviewed-by: erikj - bin/print-config.js Changeset: bc614840 Author: Albert Mingkun Yang Date: 2022-02-15 12:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc6148407e629bd99fa5a8577ebd90320610f349 8280136: Serial: Remove unnecessary use of ExpandHeap_lock Reviewed-by: iwalulya, kbarrett, sjohanss ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 2fe0bf66 Author: Stefan Johansson Date: 2022-02-15 16:22:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2fe0bf66b7cbbae3dc65249be4b04f4075a98efa 8281748: runtime/logging/RedefineClasses.java failed "assert(addr != __null) failed: invariant" Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp Changeset: 18704653 Author: Aleksey Shipilev Date: 2022-02-15 16:42:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18704653dcc76b6360b746a6a9c20d614633da0e 8281744: x86: Use short jumps in TIG::set_vtos_entry_points Reviewed-by: rehn, coleenp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Changeset: 745f7e7d Author: Calvin Cheung Date: 2022-02-15 17:18:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/745f7e7d921afcf45a2fa87824841e4545054d21 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails Reviewed-by: minqi, iklam, stuefe ! test/hotspot/jtreg/runtime/cds/appcds/DumpingWithNoCoops.java Changeset: 394ce5f9 Author: Christian Stein Committer: Lance Andersen Date: 2022-02-15 17:55:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/394ce5f948c21b3861d76dd8db57957efa1df979 8280825: Modules that "provide" ToolProvider should document the name that can be used Reviewed-by: jjg, lancea, alanb ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jpackage/share/classes/module-info.java Changeset: 1aff44b2 Author: Leonid Mesnik Date: 2022-02-15 17:59:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1aff44b2cfcf5d2253161985b902894ee69365fc 8279949: JavaThread::_free_handle_block leaks native memory Reviewed-by: dholmes, coleenp ! src/hotspot/share/runtime/jniHandles.cpp Changeset: a24498b7 Author: Leonid Mesnik Date: 2022-02-15 18:01:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a24498b777b76c04d7e6da0a8b5fb501f2fb4944 8281771: Crash in java_lang_invoke_MethodType::print_signature Reviewed-by: dholmes, shade ! src/hotspot/share/classfile/javaClasses.cpp Changeset: 0af356bb Author: Quan Anh Mai Committer: Sandhya Viswanathan Date: 2022-02-15 18:57:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0af356bb4bfee99223d4bd4f8b0001c5f362c150 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts Reviewed-by: psandoz, sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/tests/TestVectorCast.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/TestCastMethods.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/VectorReshapeHelper.java Changeset: a86cab8d Author: TheShermanTanker Committer: Tobias Hartmann Date: 2022-02-16 07:50:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a86cab8d4259f29af86aa6063b721e47827fb949 8236136: tests which use CompilationMode shouldn't be run w/ TieredStopAtLevel Reviewed-by: neliasso, kvn, thartmann ! test/hotspot/jtreg/compiler/compilercontrol/CompilationModeHighOnlyTest.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass/Launcher.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: fef5d74d Author: Aleksey Shipilev Date: 2022-02-16 09:42:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fef5d74d0e7fb32e3f63e9fbc34c5370e683e451 8281812: x86: Use short jumps in TemplateTable::condy_helper Reviewed-by: redestad, neliasso ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: d5b46665 Author: Jie Fu Date: 2022-02-16 13:46:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5b466657e29a5338b84fa9acfc1b76bf8c39d61 8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467 Reviewed-by: kvn, thartmann ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp Changeset: 7428b376 Author: Erik Gahlin Date: 2022-02-16 15:35:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7428b37696f1093094e69410f36dbb74098c9d4d 8281948: JFR: Parser skips too many bytes for fractional types Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ParserFactory.java Changeset: d8f44aa3 Author: Michael McMahon Date: 2022-02-16 16:01:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8f44aa39e921594505864e6270f42b745265293 8278067: Make HttpURLConnection default keep alive timeout configurable Reviewed-by: dfuchs ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java + test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java Changeset: 395bc141 Author: Emanuel Peter Committer: Christian Hagedorn Date: 2022-02-16 16:19:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 8281732: add assert for non-NULL assumption for return of unique_ctrl_out Reviewed-by: kvn, chagedorn, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/multnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp Changeset: 0f3d3ac3 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2022-02-16 16:43:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f3d3ac32c9d163a5d91c6839d313111c72f1ad4 8061729: Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs Reviewed-by: dfuchs ! test/jdk/sun/net/www/http/HttpClient/ProxyFromCache.java ! test/jdk/sun/net/www/http/HttpClient/RequestURI.java ! test/jdk/sun/net/www/protocol/http/CloseOptionHeader.java + test/jdk/sun/net/www/protocol/http/HttpHeaderParserTest.java ! test/jdk/sun/net/www/protocol/http/NTLMTest.java ! test/jdk/sun/net/www/protocol/http/NoNTLM.java ! test/jdk/sun/net/www/protocol/http/RetryUponTimeout.java ! test/jdk/sun/net/www/protocol/http/UserAgent.java ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java + test/lib/jdk/test/lib/net/HttpHeaderParser.java Changeset: 9b74c3f2 Author: Naoto Sato Date: 2022-02-16 16:54:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9b74c3f2e74a4efdec1c1488e96ab5939a408df0 8176706: Additional Date-Time Formats Reviewed-by: joehw, rriggs ! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java ! make/jdk/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java ! src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java + test/jdk/java/time/test/java/time/format/Skeletons_en_US.properties + test/jdk/java/time/test/java/time/format/Skeletons_ja.properties + test/jdk/java/time/test/java/time/format/TestLocalizedPattern.java Changeset: bb4dece2 Author: Alexey Semenyuk Date: 2022-02-16 17:30:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb4dece246a56f2b225089c331e9f3d092dfbfa1 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinInstallerIconTest.java Changeset: 81645521 Author: Alexey Semenyuk Date: 2022-02-16 17:31:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81645521c81c7363d199e5051d51043146058a91 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java Changeset: 980d1878 Author: Mandy Chung Date: 2022-02-16 18:31:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/980d18789139295c95ec6045539b68d1ae57bc31 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library Reviewed-by: sundar, mcimadamore ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java + src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! test/jdk/jdk/internal/loader/NativeLibraries/Main.java ! test/jdk/jdk/internal/loader/NativeLibraries/java.base/jdk/internal/loader/NativeLibrariesTest.java Changeset: 847a99b5 Author: Aleksey Shipilev Date: 2022-02-16 20:08:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/847a99b53da6b2c82f7cd5f8634aa7bbae8f445e 8281822: Test failures on non-DTrace builds due to incomplete DTrace* flags handling Reviewed-by: dholmes, kvn ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/compiler/runtime/Test8168712.java ! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java + test/hotspot/jtreg/serviceability/dtrace/DTraceOptionsTest.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 67763df4 Author: Tim Prinzing Committer: Mandy Chung Date: 2022-02-16 20:09:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67763df4dce387da33da6d93d0f5d80e54cf8e5b 8281003: MethodHandles::lookup throws NPE if caller is null Reviewed-by: ihse, mchung, jrose, alanb ! make/test/JtregNativeJdk.gmk ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/NullCallerLookupTest.java + test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/exeNullCallerLookupTest.c Changeset: 48f6e930 Author: Daniel Fuchs Date: 2022-02-16 21:38:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48f6e93079f377a621ca769b820fa221062ceab1 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed Reviewed-by: michaelm, naoto ! test/jdk/ProblemList.txt Changeset: 9ba0760c Author: Martin Desruisseaux Committer: Alexey Ivanov Date: 2022-02-16 22:01:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ba0760cf85f9e843f3383b725017c9ffac350df 8275345: RasterFormatException when drawing a tiled image made of non-writable rasters Reviewed-by: prr, aivanov ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java + test/jdk/java/awt/image/DrawImage/TiledImage.java Changeset: 5ec7898d Author: Joe Darcy Date: 2022-02-16 22:02:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ec7898dbf1ebe261e5e25939cad42134611ff12 8281671: Class.getCanonicalName spec should explicitly cover array classes Reviewed-by: mchung ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/NameTest.java Changeset: 0b00ce17 Author: Alexey Semenyuk Date: 2022-02-16 23:23:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b00ce17cd6b530d9394e79ac8b07208cd4b92f5 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinL10nTest.java Changeset: 2be2a298 Author: Tobias Hartmann Date: 2022-02-15 07:07:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2be2a298f13c3a38d9518ccfea11dfd8a736d56c 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp - test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java Changeset: 0f2113ce Author: Pavel Kharskii Committer: Jesper Wilhelmsson Date: 2022-02-15 09:24:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f2113cee79b9645105b4753c7d7eacb83b872c2 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022 Reviewed-by: erikj, iris ! make/conf/version-numbers.conf Changeset: b6e48e67 Author: Jesper Wilhelmsson Date: 2022-02-17 01:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6e48e678244481dd45d38bc3ddc325fccda2acc Merge ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: cd234f5d Author: Alexey Semenyuk Date: 2022-02-17 05:27:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd234f5dbebd18ebf0c78dfdf533318cdc627971 8282007: Assorted enhancements to jpackage testing framework Reviewed-by: almatvee ! test/jdk/tools/jpackage/apps/Hello.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/CfgFile.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/RunnablePackageTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java ! test/jdk/tools/jpackage/run_tests.sh ! test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java - test/jdk/tools/jpackage/test_jpackage.sh ! test/jdk/tools/jpackage/windows/WinUpgradeUUIDTest.java Changeset: 1eec16b4 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2022-02-17 05:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1eec16b47be300e1462528bddf5d0686df3f042c 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE Reviewed-by: aph, njian ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 1864481d Author: Ioi Lam Date: 2022-02-17 06:40:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1864481df10d2f616cbfdecebf3bebbae04de5e1 8279969: NULL return from map_bitmap_region() needs to be checked Reviewed-by: ccheung, coleenp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/heapShared.cpp ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java Changeset: c0275e18 Author: Tyler Steele Committer: Thomas Stuefe Date: 2022-02-17 08:49:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 8203290: [AIX] Check functionality of JDK-8199712 (Flight Recorder) Implements JFR for AIX Reviewed-by: erikj, mdoerr, mgronlun, stuefe, ihse ! make/autoconf/jvm-features.m4 ! src/hotspot/os/aix/libperfstat_aix.cpp ! src/hotspot/os/aix/libperfstat_aix.hpp ! src/hotspot/os/aix/loadlib_aix.cpp ! src/hotspot/os/aix/loadlib_aix.hpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_perf_aix.cpp ! src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp ! test/jdk/ProblemList.txt ! test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java Changeset: b4900b12 Author: Prasanta Sadhukhan Date: 2022-02-17 09:36:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4900b1298e536c0ceaa77bc0ac0e8e6ccba6400 8264743: Add forRemoval for deprecated classes and method in javax/swing/plaf/basic Reviewed-by: trebari, prr ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java Changeset: 9ca435b4 Author: Julia Boes Date: 2022-02-17 10:35:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ca435b4c03f9741709bbfab22fb006de8c8c9d3 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java + src/jdk.httpserver/unix/classes/sun/net/httpserver/simpleserver/URIPathSegment.java + src/jdk.httpserver/windows/classes/sun/net/httpserver/simpleserver/URIPathSegment.java ! test/jdk/com/sun/net/httpserver/simpleserver/MapToPathTest.java Changeset: 3b7a3cfc Author: Albert Mingkun Yang Date: 2022-02-17 11:40:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3b7a3cfce345cc900e042c5378d35d1237bdcd78 8281971: Remove unimplemented InstanceRefKlass::do_next Reviewed-by: dholmes ! src/hotspot/share/oops/instanceRefKlass.hpp Changeset: d0e11808 Author: Andrey Turbanov Date: 2022-02-17 12:31:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d0e11808fd688d96e5cfeb586d1de277f26da5ad 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath Reviewed-by: bpb, darcy ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 4c7f8b49 Author: Joe Darcy Date: 2022-02-17 17:12:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c7f8b49a4845acf58272c42327328d6d2837cea 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Reviewed-by: sundar, alanb ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/ArrayType.java Changeset: a6f8a386 Author: Tim Prinzing Committer: Mandy Chung Date: 2022-02-17 17:34:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6f8a386efa7af162f4b815951287f0a9bc1f396 8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null Reviewed-by: erikj, ihse, mchung, bchristi ! make/test/JtregNativeJdk.gmk ! src/java.base/share/classes/java/lang/ClassLoader.java + test/jdk/java/lang/ClassLoader/BadRegisterAsParallelCapableCaller.java + test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/NullCallerClassLoaderTest.java + test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/exeNullCallerClassLoaderTest.c Changeset: cd9a3cf0 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2022-02-17 17:45:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd9a3cf05b2c200709103e2e8596414a62a1c441 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" Reviewed-by: dfuchs ! test/jdk/ProblemList.txt ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java Changeset: 12927765 Author: Naoto Sato Date: 2022-02-17 19:03:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/129277653e51e9b1387ecee279a6ccee9199c8ff 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range Reviewed-by: joehw ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! test/jdk/java/text/Format/CompactNumberFormat/TestCompactPatternsValidity.java Changeset: 69fc273f Author: Daniel D. Daugherty Date: 2022-02-17 20:56:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69fc273f202352f74a313c37db0198be2be08616 8282075: ProblemList 3 compiler/whitebox tests on macosx-x64 Reviewed-by: mikael, bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: f830cbec Author: Magnus Ihse Bursie Date: 2022-02-17 21:18:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f830cbec909b91ad0f00f46a3496d83ecb5912ed 8188073: Add Capstone as backend for hsdis Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jorn Vernee Reviewed-by: erikj ! make/Hsdis.gmk ! make/autoconf/help.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in - src/utils/hsdis/README + src/utils/hsdis/README.md = src/utils/hsdis/binutils/hsdis-binutils.c + src/utils/hsdis/capstone/hsdis-capstone.c ! src/utils/hsdis/hsdis.h Changeset: fdce35f3 Author: Jie Fu Date: 2022-02-17 22:53:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdce35f3a1c12a64238d0c76c02451a25b0b4abb 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732 Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: a22f422b Author: Prasanta Sadhukhan Date: 2022-02-18 04:56:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a22f422b7f18dc134e48c6193bf690004635bf7d 8037573: Typo in DefaultTreeModel docs: askAllowsChildren instead of asksAllowsChildren Reviewed-by: prr, jdv, azvegint ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java Changeset: c9289583 Author: Jie Fu Date: 2022-02-18 05:02:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c9289583eb6919ced3b4115cf981180f6a957fbf 8281936: compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines Reviewed-by: shade, kvn ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Changeset: 7bcca769 Author: Roberto Casta?eda Lozano Date: 2022-02-18 08:35:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bcca7692b62a37f70c757694f6acff0295371cc 8279068: IGV: Update to work with JDK 16 and 17 Reviewed-by: kvn, neliasso, chagedorn ! src/utils/IdealGraphVisualizer/Bytecodes/pom.xml ! src/utils/IdealGraphVisualizer/ControlFlow/pom.xml ! src/utils/IdealGraphVisualizer/Coordinator/pom.xml ! src/utils/IdealGraphVisualizer/Data/pom.xml ! src/utils/IdealGraphVisualizer/Difference/pom.xml ! src/utils/IdealGraphVisualizer/Filter/pom.xml ! src/utils/IdealGraphVisualizer/FilterWindow/pom.xml ! src/utils/IdealGraphVisualizer/Graal/pom.xml ! src/utils/IdealGraphVisualizer/Graph/pom.xml ! src/utils/IdealGraphVisualizer/HierarchicalLayout/pom.xml ! src/utils/IdealGraphVisualizer/Layout/pom.xml ! src/utils/IdealGraphVisualizer/NetworkConnection/pom.xml ! src/utils/IdealGraphVisualizer/README.md ! src/utils/IdealGraphVisualizer/SelectionCoordinator/pom.xml ! src/utils/IdealGraphVisualizer/ServerCompiler/pom.xml ! src/utils/IdealGraphVisualizer/Settings/pom.xml ! src/utils/IdealGraphVisualizer/Util/pom.xml ! src/utils/IdealGraphVisualizer/View/pom.xml ! src/utils/IdealGraphVisualizer/application/pom.xml + src/utils/IdealGraphVisualizer/application/src/main/resources/idealgraphvisualizer.conf ! src/utils/IdealGraphVisualizer/branding/pom.xml ! src/utils/IdealGraphVisualizer/pom.xml Changeset: 138a1719 Author: Alex Menkov Date: 2022-02-18 09:21:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/138a17195d1695c6faaa156a43624c39c62b141b 8281267: VM HeapDumper dumps array classes several times Reviewed-by: cjplummer, coleenp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/services/heapDumper.cpp + test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java Changeset: 834d55c5 Author: Jan Lahoda Date: 2022-02-18 09:41:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/834d55c59f94674f521efda0b9801551a39c7c4d 8277300: Issues with javadoc support for preview features Reviewed-by: prappo, jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API2.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API3.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/module-info.java Changeset: e8224f7d Author: Albert Mingkun Yang Date: 2022-02-18 09:54:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e8224f7de9e4649105cfb0dd9e6a588505be4211 8282089: [BACKOUT] Parallel: Refactor PSCardTable::scavenge_contents_parallel Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psCardTable.cpp ! src/hotspot/share/gc/parallel/psCardTable.hpp Changeset: cd3b60d5 Author: duke Date: 2022-02-18 11:00:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd3b60d57a1cf27e556ad4a57acd678aaa319e62 Automatic merge of jdk:master into master Changeset: 6af29ab1 Author: duke Date: 2022-02-18 11:00:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6af29ab17c2896fc9c57825e74e06e2afb678c01 Automatic merge of master into foreign-memaccess+abi ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/globals.hpp ! test/jdk/ProblemList.txt ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/globals.hpp ! test/jdk/ProblemList.txt Changeset: 52ae44cd Author: duke Date: 2022-02-18 11:01:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52ae44cd0adf4dc845c59e0bcf27ccb6d74256fc Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/autoconf/spec.gmk.in ! make/autoconf/spec.gmk.in From duke at openjdk.java.net Fri Feb 18 11:13:05 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Fri, 18 Feb 2022 11:13:05 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> Message-ID: <0TcHY52s9k_K1TjtaeiMZ0pJ61KfjAGBHlzh12pup5I=.daf46a16-d50a-46d5-bc12-dc1b6f92a1e2@github.com> On Fri, 18 Feb 2022 10:59:59 GMT, Maurizio Cimadamore wrote: >> That option was also considered, but discarded because it would make `SegmentAllocator` stateful, e.g. more complex than just a functional interface. Right now it is pretty easy to define a new allocator - but if the allocator has to track lifetime, it becomes harder to define custom ones. Also, saying that, to create an upcall stub you need a `SegmentAllocator`, or that to create an unsafe segment view of a memory address (`MemorySegment::ofAddress`) you need an allocator, is a bit odd - in the sense that you don't really need allocation capabilities there - you just need some kind of lifetime abstraction. >> >> So, I think the "allocation" angle is valid in most cases, but I think that it only works well for native segments and doesn't really generalize to _all_ segments - unsafe views, memory mapped segments, heap segments, etc. >> >> I think separating lifecycle from allocation was a really powerful move, which paid off considerably. Having a single allocator abstraction perform double duty seems a step backwards IMHO. >> >>> I see, rethinking about it, the reason to add a `session` accessor to `MemorySegment` was to properly bind the lifetime of an **allocated** segment to an existing one and to correctly observe that lifetime. It sounds like the functionality of an allocator to me. Maybe we could instead return a `SegmentAllocator` instead (and change `MemorySession` to `SegmentDeallocator` probably) and extend the functionality of a `SegmentAllocator` to check the validity of its associating `MemorySession`. Even if it is not the case we would need to check the state of a `SegmentAllocator` anyway to ensure that we can allocate memory with it. Thanks. > >> hat option was also considered, but discarded because it would make `SegmentAllocator` stateful, e.g. more complex than just a functional interface. > > Note that today there is no contract which says that all segments returned by a `SegmentAllocator` must have the same session. While some allocators might behave like that, I think it would not be ok to force that behavior on _all_ allocators. And, we considered to add, perhaps in the future, some small subinterface, like `ScopedSegmentAllocator` which also has a `session` accessor - this would be a good return type for the arena allocator methods, for instance. But this is a move that is orthogonal to the changes described in this PR (and also not a binding one - we can add the sub-interface even at a later point w/o breaking compatibility). Thanks a lot for your clarification, I still think that having a scope that throw on `close()` sounds a lot like the problem with `UnmodifiableCollection` but it seems the alternatives have been considered already. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From duke at openjdk.java.net Fri Feb 18 11:13:18 2022 From: duke at openjdk.java.net (duke) Date: Fri, 18 Feb 2022 11:13:18 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 92 new changesets Message-ID: <2fb5e251-62de-4585-9235-a6496a235c2a@openjdk.org> Changeset: d254cf28 Author: Jie Fu Date: 2022-02-11 11:39:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d254cf28c5e72bd9b8de863b831015237640ca25 8281638: jfr/event/allocation tests fail with release VMs after JDK-8281318 due to lack of -XX:+UnlockDiagnosticVMOptions Reviewed-by: shade ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationInNewTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationOutsideTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventThrottling.java Changeset: 4ff5824f Author: Jan Lahoda Date: 2022-02-11 12:11:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ff5824f5bc13826d2eae1c83094acfcccdb7b8f 8281100: Spurious "variable might not have been initialized" with sealed class switch Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: f399ae55 Author: lawrence.andrews Committer: Alexey Ivanov Date: 2022-02-11 15:33:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f399ae558eabdce8960d339ef0758c023aeb89cc 8202836: [macosx] test java/awt/Graphics/TextAAHintsTest.java fails Reviewed-by: prr, aivanov ! test/jdk/java/awt/Graphics/TextAAHintsTest.java Changeset: e73ee0ca Author: Daniel Jeli?ski Committer: Brian Burkhalter Date: 2022-02-11 16:24:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e73ee0ca10b644600ee3747b901e5f69104d03df 8281259: MutableBigInteger subtraction could be simplified Reviewed-by: bpb ! src/java.base/share/classes/java/math/MutableBigInteger.java ! test/micro/org/openjdk/bench/java/math/BigIntegers.java Changeset: e75e8cd7 Author: Yumin Qi Date: 2022-02-11 16:42:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e75e8cd708ed478eda08c4a5c724e7e82f57d36e 8279997: check_for_dynamic_dump should not exit vm Reviewed-by: ccheung, iklam ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java Changeset: 88868397 Author: Erik Gahlin Date: 2022-02-11 17:15:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8886839779094f8a13c16be79f88052b2c79eeea 8281622: JFR: Improve documentation of jdk.jfr.Relational Reviewed-by: jbachorik ! src/jdk.jfr/share/classes/jdk/jfr/Relational.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: c5ff6e45 Author: Calvin Cheung Date: 2022-02-11 17:39:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ff6e45dee41b5703138d323a04c2c7973a08b9 8223077: module path support for dynamic CDS archive Reviewed-by: iklam, minqi ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/runtime/arguments.hpp ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ModulePath.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/UnsupportedBaseArchive.java Changeset: 0786ddb4 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-11 17:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0786ddb4712296c90df2c9e97c76c203a4de4612 8281535: Create a regression test for JDK-4670051 Reviewed-by: aivanov + test/jdk/javax/swing/JSpinner/4670051/DateFieldUnderCursorTest.java Changeset: 83ffbd2e Author: Dr Heinz M. Kabutz Committer: Paul Sandoz Date: 2022-02-11 18:49:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83ffbd2e7aed8a9c788395ccbe920ddff221ae16 8277175: Add a parallel multiply method to BigInteger Reviewed-by: psandoz ! src/java.base/share/classes/java/math/BigInteger.java + test/jdk/java/math/BigInteger/BigIntegerParallelMultiplyTest.java + test/micro/org/openjdk/bench/java/math/BigIntegerMersennePrimeMultiply.java + test/micro/org/openjdk/bench/java/math/BigIntegerParallelMultiply.java Changeset: 4032fe76 Author: Joe Darcy Date: 2022-02-11 21:52:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4032fe76dccb6da85927361aee7ceedcdb758e89 8281238: TYPE_USE annotations not printed in correct position in toString output Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! test/langtools/tools/javac/patterns/Annotations.java ! test/langtools/tools/javac/tree/ArrayTypeToString.java ! test/langtools/tools/javac/tree/ArrayTypeToString.out Changeset: c3179a87 Author: Joe Darcy Date: 2022-02-11 23:24:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3179a8760019b5954e344bf0d2775e1e1968f32 8281462: Annotation toString output for enum not reusable for source input Reviewed-by: mchung ! src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! test/jdk/java/lang/annotation/AnnotationToStringTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/EnumTypeMismatchTest.java ! test/jdk/java/lang/annotation/TestConstructorParameterAnnotations.java ! test/jdk/java/lang/annotation/typeAnnotations/GetAnnotatedNestedSuperclass.java ! test/jdk/java/lang/annotation/typeAnnotations/TestConstructorParameterTypeAnnotations.java ! test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java ! test/jdk/java/lang/reflect/records/RecordReflectionTest.java Changeset: 6fdfe045 Author: Joe Darcy Date: 2022-02-12 01:33:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6fdfe0458df989a7946b4f52a3023e8a39fb3bbb 8281674: tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java fails with AssertionError Reviewed-by: vromero ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java Changeset: aa918a6e Author: Alexander Zuev Date: 2022-02-12 09:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa918a6ec4cd1356efd481c6f6fa94959f94f7b3 8281033: Improve ImageCheckboxTest to test all available LaF Reviewed-by: serb ! test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java Changeset: 58dae60d Author: Alexey Bakhtin Date: 2022-02-12 11:54:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58dae60da0711c4ae0cb23f8ce2328e051d603b2 8274524: SSLSocket.close() hangs if it is called during the ssl handshake Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java + test/jdk/sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java Changeset: 67077a04 Author: Emanuel Peter Committer: David Holmes Date: 2022-02-12 13:08:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67077a04307b512219a46b6c4c274ce308ee46de 8278423: ExtendedDTraceProbes should be deprecated Reviewed-by: dholmes, hseigel, kvn, thartmann ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/man/java.1 ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java Changeset: 8acfbc2e Author: David Holmes Date: 2022-02-12 14:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8acfbc2e21063c3dc088c25c1574bcefa94e5a24 8281675: VMDeprecatedOptions test fails after JDK-8278423 Reviewed-by: dcubed ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: eff5dafb Author: Sergey Bylokhov Date: 2022-02-12 22:10:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eff5dafba9f72bd0612357712ffa472ce1c9166a 8274939: Incorrect size of the pixel storage is used by the robot on macOS Reviewed-by: aivanov, prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! test/jdk/java/awt/Robot/CheckCommonColors/CheckCommonColors.java Changeset: adbe0661 Author: Bhavana Kilambi Committer: Ningsheng Jian Date: 2022-02-14 01:33:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/adbe0661029f12a36a44af52b83b189384d33a27 8239927: Product variable PrefetchFieldsAhead is unused and should be removed Reviewed-by: njian, dholmes ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 483d4b97 Author: Nils Eliasson Date: 2022-02-14 08:27:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/483d4b97e0ae4ab7b0d87058901f57688a0f0811 8281505: Add CompileCommand PrintIdealPhase Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/compiler/directivesParser.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/phasetype.hpp + test/hotspot/jtreg/compiler/oracle/PrintIdealPhaseTest.java Changeset: 1ef45c5b Author: Roland Westrelin Date: 2022-02-14 08:35:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ef45c5bbdeb4e1ca65c6d8f3ac1568a6951f3a7 8280799: ?2: assert(false) failed: cyclic dependency prevents range check elimination Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/loopopts/TestPredicateInputBelowLoopPredicate.java Changeset: 46f52296 Author: Roberto Casta?eda Lozano Date: 2022-02-14 08:37:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46f522962f1b2bbb2513823821e332db1093994b 8281539: IGV: schedule approximation computes immediate dominators wrongly Replace custom dominator computation with one from the WALA libraries. Reviewed-by: neliasso, chagedorn ! src/utils/IdealGraphVisualizer/ServerCompiler/pom.xml ! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java ! src/utils/IdealGraphVisualizer/pom.xml Changeset: 2632d40d Author: Stefan Johansson Date: 2022-02-14 09:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2632d40dfc9f681e53fe04d32b6380ffb4eeb88c 8281637: Remove unused VerifyOption_G1UseNextMarking Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/shared/verifyOption.hpp Changeset: 25972062 Author: Albert Mingkun Yang Date: 2022-02-14 09:15:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2597206242356d42ca5d08be809cfdff79df924d 8280783: Parallel: Refactor PSCardTable::scavenge_contents_parallel Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/parallel/psCardTable.cpp ! src/hotspot/share/gc/parallel/psCardTable.hpp Changeset: c61d629a Author: Emanuel Peter Committer: Christian Hagedorn Date: 2022-02-14 09:52:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 8281553: Ensure we only require liveness from mach-nodes with barriers Reviewed-by: neliasso, chagedorn ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp Changeset: 95f198b2 Author: Magnus Ihse Bursie Date: 2022-02-14 10:31:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95f198b2b1b2d5437515dc837cc160e4224c0ff3 8274980: Improve adhoc build version strings Reviewed-by: shade, erikj ! .github/workflows/submit.yml ! make/Docs.gmk ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/hotspot/lib/CompileJvm.gmk ! test/jdk/java/lang/RuntimeTests/Version/Basic.java ! test/langtools/tools/javac/options/modes/InfoOptsTest.java Changeset: 534e5578 Author: Vladimir Ivanov Date: 2022-02-14 11:57:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/534e557874274255c55086b4f6128063cbd9cc58 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers Reviewed-by: dlong, kvn ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/interpreter/bootstrapInfo.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! test/jdk/ProblemList-Xcomp.txt Changeset: 2604a88f Author: Leo Korinth Date: 2022-02-14 12:05:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2604a88fbb6d0f9aec51c7d607ea275bc34a672c 8281585: Remove unused imports under test/lib and jtreg/gc Reviewed-by: dholmes, sspitsyn ! test/hotspot/jtreg/gc/TestAllocateHeapAt.java ! test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java ! test/hotspot/jtreg/gc/TestCardTablePageCommits.java ! test/hotspot/jtreg/gc/TestSmallHeap.java ! test/hotspot/jtreg/gc/arguments/TestAggressiveHeap.java ! test/hotspot/jtreg/gc/arguments/TestArrayAllocatorMallocLimit.java ! test/hotspot/jtreg/gc/arguments/TestCompressedClassFlags.java ! test/hotspot/jtreg/gc/arguments/TestG1ConcMarkStepDurationMillis.java ! test/hotspot/jtreg/gc/arguments/TestG1ConcRefinementThreads.java ! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java ! test/hotspot/jtreg/gc/arguments/TestG1PercentageOptions.java ! test/hotspot/jtreg/gc/arguments/TestG1RemSetFlags.java ! test/hotspot/jtreg/gc/arguments/TestHeapFreeRatio.java ! test/hotspot/jtreg/gc/arguments/TestInitialTenuringThreshold.java ! test/hotspot/jtreg/gc/arguments/TestMaxHeapSizeTools.java ! test/hotspot/jtreg/gc/arguments/TestMaxMinHeapFreeRatioFlags.java ! test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java ! test/hotspot/jtreg/gc/arguments/TestMaxRAMFlags.java ! test/hotspot/jtreg/gc/arguments/TestMinAndInitialSurvivorRatioFlags.java ! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestNewSizeFlags.java ! test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java ! test/hotspot/jtreg/gc/arguments/TestObjectTenuringFlags.java ! test/hotspot/jtreg/gc/arguments/TestParallelGCThreads.java ! test/hotspot/jtreg/gc/arguments/TestSelectDefaultGC.java ! test/hotspot/jtreg/gc/arguments/TestSmallInitialHeapWithLargePageAndNUMA.java ! test/hotspot/jtreg/gc/arguments/TestSurvivorRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestUnrecognizedVMOptionsHandling.java ! test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsErgoTools.java ! test/hotspot/jtreg/gc/arguments/TestUseNUMAInterleaving.java ! test/hotspot/jtreg/gc/arguments/TestVerifyBeforeAndAfterGCFlags.java ! test/hotspot/jtreg/gc/epsilon/TestClasses.java ! test/hotspot/jtreg/gc/g1/TestEvacuationFailure.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData.java ! test/hotspot/jtreg/gc/g1/TestSkipRebuildRemsetPhase.java ! test/hotspot/jtreg/gc/stress/gclocker/TestExcessGCLockerCollections.java ! test/lib/RedefineClassHelper.java ! test/lib/jdk/test/lib/OSVersion.java ! test/lib/jdk/test/lib/Utils.java ! test/lib/jdk/test/lib/apps/LingeredApp.java ! test/lib/jdk/test/lib/artifacts/ArtifactManager.java ! test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java ! test/lib/jdk/test/lib/containers/docker/Common.java ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java ! test/lib/jdk/test/lib/format/ArrayCodec.java ! test/lib/jdk/test/lib/format/ArrayDiff.java ! test/lib/jdk/test/lib/helpers/ClassFileInstaller.java ! test/lib/jdk/test/lib/hexdump/ObjectStreamPrinter.java ! test/lib/jdk/test/lib/hprof/model/JavaObjectArray.java ! test/lib/jdk/test/lib/hprof/model/JavaThing.java ! test/lib/jdk/test/lib/hprof/model/JavaValueArray.java ! test/lib/jdk/test/lib/hprof/model/ReachableExcludesImpl.java ! test/lib/jdk/test/lib/hprof/model/ReachableObjects.java ! test/lib/jdk/test/lib/hprof/util/ArraySorter.java ! test/lib/jdk/test/lib/hprof/util/Misc.java ! test/lib/jdk/test/lib/security/KeyStoreUtils.java ! test/lib/jdk/test/lib/security/timestamp/DefaultRespInterceptor.java ! test/lib/jdk/test/lib/security/timestamp/TsaHandler.java ! test/lib/jdk/test/lib/security/timestamp/TsaServer.java ! test/lib/jdk/test/lib/util/JavaAgentBuilder.java Changeset: 9d0a4c3f Author: Brian J. Stafford Committer: Thomas Schatzl Date: 2022-02-14 12:20:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d0a4c3f2e347c30ff56ba1416c08cc662f7f23c 8274238: Inconsistent type for young_list_target_length() Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1Policy.hpp Changeset: f07b8165 Author: Thomas Stuefe Date: 2022-02-14 16:41:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f07b8165231799383303e5c0755d07afd2feb7fd 8280940: gtest os.release_multi_mappings_vm is racy Reviewed-by: dcubed, sjohanss ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 88fc3bfd Author: Vladimir Ivanov Date: 2022-02-14 18:46:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/88fc3bfdff7f89a02fcfb16909df144e6173c658 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant pool entries Reviewed-by: dlong, redestad, neliasso ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_InstructionPrinter.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/opto/parse2.cpp + test/hotspot/jtreg/compiler/runtime/TestConstantDynamic.java ! test/hotspot/jtreg/compiler/runtime/TestConstantsInError.java Changeset: 16f649b9 Author: Ioi Lam Date: 2022-02-14 18:53:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16f649b9c5b480d2a8499b1a92939cdf53ecc8dc 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails after JDK-8279997 Reviewed-by: shade, dcubed ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java Changeset: 1a7b70a8 Author: Phil Race Date: 2022-02-14 23:31:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1a7b70a8be0a236b98925a8320d25d88a405d595 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4 Reviewed-by: serb ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java ! test/jdk/javax/sound/sampled/Clip/SetPositionHang.java Changeset: d4cd8dfe Author: Jaikiran Pai Date: 2022-02-15 03:53:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4cd8dfedbe220fb3b9a68650aba90536e9b12ee 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters Reviewed-by: dfuchs, naoto, mchung ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! test/langtools/tools/jdeps/Options.java Changeset: f33329eb Author: Harshitha Onkar Committer: Prasanta Sadhukhan Date: 2022-02-15 05:03:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f33329eb7f7a1a541d8f30ba8952b0b922ac5257 8016524: [macosx] Bottom line is not visible for JTableHeader Reviewed-by: psadhukhan, prr ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java + test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java Changeset: b1564624 Author: Aleksey Shipilev Date: 2022-02-15 06:19:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b1564624ce454d0df9b2464424b7b5e449481ee6 8281467: Allow larger OptoLoopAlignment and CodeEntryAlignment Reviewed-by: kvn, dlong ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/globals.hpp + test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java + test/hotspot/jtreg/compiler/arguments/TestOptoLoopAlignment.java Changeset: 11f943d1 Author: Kim Barrett Date: 2022-02-15 06:51:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11f943d148e7bc8d931c382ff019b3e65a87432e 8280916: Simplify HotSpot Style Guide editorial changes Reviewed-by: dcubed, dholmes, stuefe, stefank, kvn, tschatzl ! doc/hotspot-style.html ! doc/hotspot-style.md Changeset: 622970e4 Author: Andrey Turbanov Date: 2022-02-15 07:10:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/622970e47cedd6e0b94b74235aa984ad79281389 8281728: Redundant null check in LineNumberInputStream.read Reviewed-by: redestad ! src/java.base/share/classes/java/io/LineNumberInputStream.java Changeset: 8819f453 Author: Nils Eliasson Date: 2022-02-15 08:20:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8819f4535743f6504b4aaa62c7d87926dd1b0013 8281722: Removal of PrintIdealLevel Reviewed-by: chagedorn, thartmann ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: f82866bc Author: Dmitry Markov Date: 2022-02-15 09:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f82866bc79cbeeac23716fa6fadd4877f5d0a462 8281555: [macos] Get rid of deprecated Style Masks constants Reviewed-by: serb, aivanov ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m ! test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java Changeset: 1c12b159 Author: Nils Eliasson Date: 2022-02-15 09:49:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c12b159ffcbb3528a20ac585d8460bf730e303d 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp Reviewed-by: kvn, chagedorn, thartmann ! test/hotspot/jtreg/compiler/oracle/PrintIdealPhaseTest.java Changeset: 2112a9dc Author: Magnus Ihse Bursie Date: 2022-02-15 11:11:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2112a9dc49a41e11433f19d258d72806b321106c 8246033: bin/print_config.js script uses nashorn jjs tool Reviewed-by: erikj - bin/print-config.js Changeset: bc614840 Author: Albert Mingkun Yang Date: 2022-02-15 12:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc6148407e629bd99fa5a8577ebd90320610f349 8280136: Serial: Remove unnecessary use of ExpandHeap_lock Reviewed-by: iwalulya, kbarrett, sjohanss ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 2fe0bf66 Author: Stefan Johansson Date: 2022-02-15 16:22:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2fe0bf66b7cbbae3dc65249be4b04f4075a98efa 8281748: runtime/logging/RedefineClasses.java failed "assert(addr != __null) failed: invariant" Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp Changeset: 18704653 Author: Aleksey Shipilev Date: 2022-02-15 16:42:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18704653dcc76b6360b746a6a9c20d614633da0e 8281744: x86: Use short jumps in TIG::set_vtos_entry_points Reviewed-by: rehn, coleenp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Changeset: 745f7e7d Author: Calvin Cheung Date: 2022-02-15 17:18:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/745f7e7d921afcf45a2fa87824841e4545054d21 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails Reviewed-by: minqi, iklam, stuefe ! test/hotspot/jtreg/runtime/cds/appcds/DumpingWithNoCoops.java Changeset: 394ce5f9 Author: Christian Stein Committer: Lance Andersen Date: 2022-02-15 17:55:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/394ce5f948c21b3861d76dd8db57957efa1df979 8280825: Modules that "provide" ToolProvider should document the name that can be used Reviewed-by: jjg, lancea, alanb ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jpackage/share/classes/module-info.java Changeset: 1aff44b2 Author: Leonid Mesnik Date: 2022-02-15 17:59:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1aff44b2cfcf5d2253161985b902894ee69365fc 8279949: JavaThread::_free_handle_block leaks native memory Reviewed-by: dholmes, coleenp ! src/hotspot/share/runtime/jniHandles.cpp Changeset: a24498b7 Author: Leonid Mesnik Date: 2022-02-15 18:01:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a24498b777b76c04d7e6da0a8b5fb501f2fb4944 8281771: Crash in java_lang_invoke_MethodType::print_signature Reviewed-by: dholmes, shade ! src/hotspot/share/classfile/javaClasses.cpp Changeset: 0af356bb Author: Quan Anh Mai Committer: Sandhya Viswanathan Date: 2022-02-15 18:57:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0af356bb4bfee99223d4bd4f8b0001c5f362c150 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts Reviewed-by: psandoz, sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/tests/TestVectorCast.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/TestCastMethods.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/VectorReshapeHelper.java Changeset: a86cab8d Author: TheShermanTanker Committer: Tobias Hartmann Date: 2022-02-16 07:50:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a86cab8d4259f29af86aa6063b721e47827fb949 8236136: tests which use CompilationMode shouldn't be run w/ TieredStopAtLevel Reviewed-by: neliasso, kvn, thartmann ! test/hotspot/jtreg/compiler/compilercontrol/CompilationModeHighOnlyTest.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass/Launcher.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: fef5d74d Author: Aleksey Shipilev Date: 2022-02-16 09:42:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fef5d74d0e7fb32e3f63e9fbc34c5370e683e451 8281812: x86: Use short jumps in TemplateTable::condy_helper Reviewed-by: redestad, neliasso ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: d5b46665 Author: Jie Fu Date: 2022-02-16 13:46:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5b466657e29a5338b84fa9acfc1b76bf8c39d61 8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467 Reviewed-by: kvn, thartmann ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp Changeset: 7428b376 Author: Erik Gahlin Date: 2022-02-16 15:35:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7428b37696f1093094e69410f36dbb74098c9d4d 8281948: JFR: Parser skips too many bytes for fractional types Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ParserFactory.java Changeset: d8f44aa3 Author: Michael McMahon Date: 2022-02-16 16:01:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8f44aa39e921594505864e6270f42b745265293 8278067: Make HttpURLConnection default keep alive timeout configurable Reviewed-by: dfuchs ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java + test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java Changeset: 395bc141 Author: Emanuel Peter Committer: Christian Hagedorn Date: 2022-02-16 16:19:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 8281732: add assert for non-NULL assumption for return of unique_ctrl_out Reviewed-by: kvn, chagedorn, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/multnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp Changeset: 0f3d3ac3 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2022-02-16 16:43:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f3d3ac32c9d163a5d91c6839d313111c72f1ad4 8061729: Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs Reviewed-by: dfuchs ! test/jdk/sun/net/www/http/HttpClient/ProxyFromCache.java ! test/jdk/sun/net/www/http/HttpClient/RequestURI.java ! test/jdk/sun/net/www/protocol/http/CloseOptionHeader.java + test/jdk/sun/net/www/protocol/http/HttpHeaderParserTest.java ! test/jdk/sun/net/www/protocol/http/NTLMTest.java ! test/jdk/sun/net/www/protocol/http/NoNTLM.java ! test/jdk/sun/net/www/protocol/http/RetryUponTimeout.java ! test/jdk/sun/net/www/protocol/http/UserAgent.java ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java + test/lib/jdk/test/lib/net/HttpHeaderParser.java Changeset: 9b74c3f2 Author: Naoto Sato Date: 2022-02-16 16:54:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9b74c3f2e74a4efdec1c1488e96ab5939a408df0 8176706: Additional Date-Time Formats Reviewed-by: joehw, rriggs ! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java ! make/jdk/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java ! src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java + test/jdk/java/time/test/java/time/format/Skeletons_en_US.properties + test/jdk/java/time/test/java/time/format/Skeletons_ja.properties + test/jdk/java/time/test/java/time/format/TestLocalizedPattern.java Changeset: bb4dece2 Author: Alexey Semenyuk Date: 2022-02-16 17:30:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb4dece246a56f2b225089c331e9f3d092dfbfa1 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinInstallerIconTest.java Changeset: 81645521 Author: Alexey Semenyuk Date: 2022-02-16 17:31:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81645521c81c7363d199e5051d51043146058a91 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java Changeset: 980d1878 Author: Mandy Chung Date: 2022-02-16 18:31:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/980d18789139295c95ec6045539b68d1ae57bc31 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library Reviewed-by: sundar, mcimadamore ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java + src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! test/jdk/jdk/internal/loader/NativeLibraries/Main.java ! test/jdk/jdk/internal/loader/NativeLibraries/java.base/jdk/internal/loader/NativeLibrariesTest.java Changeset: 847a99b5 Author: Aleksey Shipilev Date: 2022-02-16 20:08:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/847a99b53da6b2c82f7cd5f8634aa7bbae8f445e 8281822: Test failures on non-DTrace builds due to incomplete DTrace* flags handling Reviewed-by: dholmes, kvn ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/compiler/runtime/Test8168712.java ! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java + test/hotspot/jtreg/serviceability/dtrace/DTraceOptionsTest.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 67763df4 Author: Tim Prinzing Committer: Mandy Chung Date: 2022-02-16 20:09:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67763df4dce387da33da6d93d0f5d80e54cf8e5b 8281003: MethodHandles::lookup throws NPE if caller is null Reviewed-by: ihse, mchung, jrose, alanb ! make/test/JtregNativeJdk.gmk ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/NullCallerLookupTest.java + test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/exeNullCallerLookupTest.c Changeset: 48f6e930 Author: Daniel Fuchs Date: 2022-02-16 21:38:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48f6e93079f377a621ca769b820fa221062ceab1 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed Reviewed-by: michaelm, naoto ! test/jdk/ProblemList.txt Changeset: 9ba0760c Author: Martin Desruisseaux Committer: Alexey Ivanov Date: 2022-02-16 22:01:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ba0760cf85f9e843f3383b725017c9ffac350df 8275345: RasterFormatException when drawing a tiled image made of non-writable rasters Reviewed-by: prr, aivanov ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java + test/jdk/java/awt/image/DrawImage/TiledImage.java Changeset: 5ec7898d Author: Joe Darcy Date: 2022-02-16 22:02:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ec7898dbf1ebe261e5e25939cad42134611ff12 8281671: Class.getCanonicalName spec should explicitly cover array classes Reviewed-by: mchung ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/NameTest.java Changeset: 0b00ce17 Author: Alexey Semenyuk Date: 2022-02-16 23:23:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b00ce17cd6b530d9394e79ac8b07208cd4b92f5 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinL10nTest.java Changeset: 2be2a298 Author: Tobias Hartmann Date: 2022-02-15 07:07:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2be2a298f13c3a38d9518ccfea11dfd8a736d56c 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp - test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java Changeset: 0f2113ce Author: Pavel Kharskii Committer: Jesper Wilhelmsson Date: 2022-02-15 09:24:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f2113cee79b9645105b4753c7d7eacb83b872c2 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022 Reviewed-by: erikj, iris ! make/conf/version-numbers.conf Changeset: b6e48e67 Author: Jesper Wilhelmsson Date: 2022-02-17 01:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6e48e678244481dd45d38bc3ddc325fccda2acc Merge ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: cd234f5d Author: Alexey Semenyuk Date: 2022-02-17 05:27:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd234f5dbebd18ebf0c78dfdf533318cdc627971 8282007: Assorted enhancements to jpackage testing framework Reviewed-by: almatvee ! test/jdk/tools/jpackage/apps/Hello.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/CfgFile.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/RunnablePackageTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java ! test/jdk/tools/jpackage/run_tests.sh ! test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java - test/jdk/tools/jpackage/test_jpackage.sh ! test/jdk/tools/jpackage/windows/WinUpgradeUUIDTest.java Changeset: 1eec16b4 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2022-02-17 05:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1eec16b47be300e1462528bddf5d0686df3f042c 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE Reviewed-by: aph, njian ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 1864481d Author: Ioi Lam Date: 2022-02-17 06:40:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1864481df10d2f616cbfdecebf3bebbae04de5e1 8279969: NULL return from map_bitmap_region() needs to be checked Reviewed-by: ccheung, coleenp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/heapShared.cpp ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java Changeset: c0275e18 Author: Tyler Steele Committer: Thomas Stuefe Date: 2022-02-17 08:49:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 8203290: [AIX] Check functionality of JDK-8199712 (Flight Recorder) Implements JFR for AIX Reviewed-by: erikj, mdoerr, mgronlun, stuefe, ihse ! make/autoconf/jvm-features.m4 ! src/hotspot/os/aix/libperfstat_aix.cpp ! src/hotspot/os/aix/libperfstat_aix.hpp ! src/hotspot/os/aix/loadlib_aix.cpp ! src/hotspot/os/aix/loadlib_aix.hpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_perf_aix.cpp ! src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp ! test/jdk/ProblemList.txt ! test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java Changeset: b4900b12 Author: Prasanta Sadhukhan Date: 2022-02-17 09:36:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4900b1298e536c0ceaa77bc0ac0e8e6ccba6400 8264743: Add forRemoval for deprecated classes and method in javax/swing/plaf/basic Reviewed-by: trebari, prr ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java Changeset: 9ca435b4 Author: Julia Boes Date: 2022-02-17 10:35:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ca435b4c03f9741709bbfab22fb006de8c8c9d3 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java + src/jdk.httpserver/unix/classes/sun/net/httpserver/simpleserver/URIPathSegment.java + src/jdk.httpserver/windows/classes/sun/net/httpserver/simpleserver/URIPathSegment.java ! test/jdk/com/sun/net/httpserver/simpleserver/MapToPathTest.java Changeset: 3b7a3cfc Author: Albert Mingkun Yang Date: 2022-02-17 11:40:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3b7a3cfce345cc900e042c5378d35d1237bdcd78 8281971: Remove unimplemented InstanceRefKlass::do_next Reviewed-by: dholmes ! src/hotspot/share/oops/instanceRefKlass.hpp Changeset: d0e11808 Author: Andrey Turbanov Date: 2022-02-17 12:31:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d0e11808fd688d96e5cfeb586d1de277f26da5ad 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath Reviewed-by: bpb, darcy ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 4c7f8b49 Author: Joe Darcy Date: 2022-02-17 17:12:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c7f8b49a4845acf58272c42327328d6d2837cea 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Reviewed-by: sundar, alanb ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/ArrayType.java Changeset: a6f8a386 Author: Tim Prinzing Committer: Mandy Chung Date: 2022-02-17 17:34:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6f8a386efa7af162f4b815951287f0a9bc1f396 8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null Reviewed-by: erikj, ihse, mchung, bchristi ! make/test/JtregNativeJdk.gmk ! src/java.base/share/classes/java/lang/ClassLoader.java + test/jdk/java/lang/ClassLoader/BadRegisterAsParallelCapableCaller.java + test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/NullCallerClassLoaderTest.java + test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/exeNullCallerClassLoaderTest.c Changeset: cd9a3cf0 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2022-02-17 17:45:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd9a3cf05b2c200709103e2e8596414a62a1c441 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" Reviewed-by: dfuchs ! test/jdk/ProblemList.txt ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java Changeset: 12927765 Author: Naoto Sato Date: 2022-02-17 19:03:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/129277653e51e9b1387ecee279a6ccee9199c8ff 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range Reviewed-by: joehw ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! test/jdk/java/text/Format/CompactNumberFormat/TestCompactPatternsValidity.java Changeset: 69fc273f Author: Daniel D. Daugherty Date: 2022-02-17 20:56:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69fc273f202352f74a313c37db0198be2be08616 8282075: ProblemList 3 compiler/whitebox tests on macosx-x64 Reviewed-by: mikael, bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: f830cbec Author: Magnus Ihse Bursie Date: 2022-02-17 21:18:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f830cbec909b91ad0f00f46a3496d83ecb5912ed 8188073: Add Capstone as backend for hsdis Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jorn Vernee Reviewed-by: erikj ! make/Hsdis.gmk ! make/autoconf/help.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in - src/utils/hsdis/README + src/utils/hsdis/README.md = src/utils/hsdis/binutils/hsdis-binutils.c + src/utils/hsdis/capstone/hsdis-capstone.c ! src/utils/hsdis/hsdis.h Changeset: fdce35f3 Author: Jie Fu Date: 2022-02-17 22:53:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdce35f3a1c12a64238d0c76c02451a25b0b4abb 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732 Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: a22f422b Author: Prasanta Sadhukhan Date: 2022-02-18 04:56:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a22f422b7f18dc134e48c6193bf690004635bf7d 8037573: Typo in DefaultTreeModel docs: askAllowsChildren instead of asksAllowsChildren Reviewed-by: prr, jdv, azvegint ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java Changeset: c9289583 Author: Jie Fu Date: 2022-02-18 05:02:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c9289583eb6919ced3b4115cf981180f6a957fbf 8281936: compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines Reviewed-by: shade, kvn ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Changeset: 7bcca769 Author: Roberto Casta?eda Lozano Date: 2022-02-18 08:35:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bcca7692b62a37f70c757694f6acff0295371cc 8279068: IGV: Update to work with JDK 16 and 17 Reviewed-by: kvn, neliasso, chagedorn ! src/utils/IdealGraphVisualizer/Bytecodes/pom.xml ! src/utils/IdealGraphVisualizer/ControlFlow/pom.xml ! src/utils/IdealGraphVisualizer/Coordinator/pom.xml ! src/utils/IdealGraphVisualizer/Data/pom.xml ! src/utils/IdealGraphVisualizer/Difference/pom.xml ! src/utils/IdealGraphVisualizer/Filter/pom.xml ! src/utils/IdealGraphVisualizer/FilterWindow/pom.xml ! src/utils/IdealGraphVisualizer/Graal/pom.xml ! src/utils/IdealGraphVisualizer/Graph/pom.xml ! src/utils/IdealGraphVisualizer/HierarchicalLayout/pom.xml ! src/utils/IdealGraphVisualizer/Layout/pom.xml ! src/utils/IdealGraphVisualizer/NetworkConnection/pom.xml ! src/utils/IdealGraphVisualizer/README.md ! src/utils/IdealGraphVisualizer/SelectionCoordinator/pom.xml ! src/utils/IdealGraphVisualizer/ServerCompiler/pom.xml ! src/utils/IdealGraphVisualizer/Settings/pom.xml ! src/utils/IdealGraphVisualizer/Util/pom.xml ! src/utils/IdealGraphVisualizer/View/pom.xml ! src/utils/IdealGraphVisualizer/application/pom.xml + src/utils/IdealGraphVisualizer/application/src/main/resources/idealgraphvisualizer.conf ! src/utils/IdealGraphVisualizer/branding/pom.xml ! src/utils/IdealGraphVisualizer/pom.xml Changeset: 138a1719 Author: Alex Menkov Date: 2022-02-18 09:21:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/138a17195d1695c6faaa156a43624c39c62b141b 8281267: VM HeapDumper dumps array classes several times Reviewed-by: cjplummer, coleenp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/services/heapDumper.cpp + test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java Changeset: 834d55c5 Author: Jan Lahoda Date: 2022-02-18 09:41:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/834d55c59f94674f521efda0b9801551a39c7c4d 8277300: Issues with javadoc support for preview features Reviewed-by: prappo, jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API2.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API3.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/module-info.java Changeset: e8224f7d Author: Albert Mingkun Yang Date: 2022-02-18 09:54:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e8224f7de9e4649105cfb0dd9e6a588505be4211 8282089: [BACKOUT] Parallel: Refactor PSCardTable::scavenge_contents_parallel Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psCardTable.cpp ! src/hotspot/share/gc/parallel/psCardTable.hpp Changeset: cd3b60d5 Author: duke Date: 2022-02-18 11:00:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd3b60d57a1cf27e556ad4a57acd678aaa319e62 Automatic merge of jdk:master into master Changeset: 6af29ab1 Author: duke Date: 2022-02-18 11:00:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6af29ab17c2896fc9c57825e74e06e2afb678c01 Automatic merge of master into foreign-memaccess+abi ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/globals.hpp ! test/jdk/ProblemList.txt ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/globals.hpp ! test/jdk/ProblemList.txt From duke at openjdk.java.net Fri Feb 18 11:18:48 2022 From: duke at openjdk.java.net (duke) Date: Fri, 18 Feb 2022 11:18:48 GMT Subject: git: openjdk/panama-foreign: master: 91 new changesets Message-ID: <7188c16f-ca6e-4f79-9f66-8c4bfcc6ca19@openjdk.org> Changeset: d254cf28 Author: Jie Fu Date: 2022-02-11 11:39:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d254cf28c5e72bd9b8de863b831015237640ca25 8281638: jfr/event/allocation tests fail with release VMs after JDK-8281318 due to lack of -XX:+UnlockDiagnosticVMOptions Reviewed-by: shade ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationInNewTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationOutsideTLABEvent.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventThrottling.java Changeset: 4ff5824f Author: Jan Lahoda Date: 2022-02-11 12:11:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ff5824f5bc13826d2eae1c83094acfcccdb7b8f 8281100: Spurious "variable might not have been initialized" with sealed class switch Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: f399ae55 Author: lawrence.andrews Committer: Alexey Ivanov Date: 2022-02-11 15:33:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f399ae558eabdce8960d339ef0758c023aeb89cc 8202836: [macosx] test java/awt/Graphics/TextAAHintsTest.java fails Reviewed-by: prr, aivanov ! test/jdk/java/awt/Graphics/TextAAHintsTest.java Changeset: e73ee0ca Author: Daniel Jeli?ski Committer: Brian Burkhalter Date: 2022-02-11 16:24:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e73ee0ca10b644600ee3747b901e5f69104d03df 8281259: MutableBigInteger subtraction could be simplified Reviewed-by: bpb ! src/java.base/share/classes/java/math/MutableBigInteger.java ! test/micro/org/openjdk/bench/java/math/BigIntegers.java Changeset: e75e8cd7 Author: Yumin Qi Date: 2022-02-11 16:42:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e75e8cd708ed478eda08c4a5c724e7e82f57d36e 8279997: check_for_dynamic_dump should not exit vm Reviewed-by: ccheung, iklam ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java Changeset: 88868397 Author: Erik Gahlin Date: 2022-02-11 17:15:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8886839779094f8a13c16be79f88052b2c79eeea 8281622: JFR: Improve documentation of jdk.jfr.Relational Reviewed-by: jbachorik ! src/jdk.jfr/share/classes/jdk/jfr/Relational.java ! src/jdk.jfr/share/classes/jdk/jfr/snippet-files/Snippets.java Changeset: c5ff6e45 Author: Calvin Cheung Date: 2022-02-11 17:39:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ff6e45dee41b5703138d323a04c2c7973a08b9 8223077: module path support for dynamic CDS archive Reviewed-by: iklam, minqi ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/runtime/arguments.hpp ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ModulePath.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/UnsupportedBaseArchive.java Changeset: 0786ddb4 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-11 17:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0786ddb4712296c90df2c9e97c76c203a4de4612 8281535: Create a regression test for JDK-4670051 Reviewed-by: aivanov + test/jdk/javax/swing/JSpinner/4670051/DateFieldUnderCursorTest.java Changeset: 83ffbd2e Author: Dr Heinz M. Kabutz Committer: Paul Sandoz Date: 2022-02-11 18:49:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/83ffbd2e7aed8a9c788395ccbe920ddff221ae16 8277175: Add a parallel multiply method to BigInteger Reviewed-by: psandoz ! src/java.base/share/classes/java/math/BigInteger.java + test/jdk/java/math/BigInteger/BigIntegerParallelMultiplyTest.java + test/micro/org/openjdk/bench/java/math/BigIntegerMersennePrimeMultiply.java + test/micro/org/openjdk/bench/java/math/BigIntegerParallelMultiply.java Changeset: 4032fe76 Author: Joe Darcy Date: 2022-02-11 21:52:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4032fe76dccb6da85927361aee7ceedcdb758e89 8281238: TYPE_USE annotations not printed in correct position in toString output Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! test/langtools/tools/javac/patterns/Annotations.java ! test/langtools/tools/javac/tree/ArrayTypeToString.java ! test/langtools/tools/javac/tree/ArrayTypeToString.out Changeset: c3179a87 Author: Joe Darcy Date: 2022-02-11 23:24:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3179a8760019b5954e344bf0d2775e1e1968f32 8281462: Annotation toString output for enum not reusable for source input Reviewed-by: mchung ! src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! test/jdk/java/lang/annotation/AnnotationToStringTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/EnumTypeMismatchTest.java ! test/jdk/java/lang/annotation/TestConstructorParameterAnnotations.java ! test/jdk/java/lang/annotation/typeAnnotations/GetAnnotatedNestedSuperclass.java ! test/jdk/java/lang/annotation/typeAnnotations/TestConstructorParameterTypeAnnotations.java ! test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java ! test/jdk/java/lang/reflect/records/RecordReflectionTest.java Changeset: 6fdfe045 Author: Joe Darcy Date: 2022-02-12 01:33:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6fdfe0458df989a7946b4f52a3023e8a39fb3bbb 8281674: tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java fails with AssertionError Reviewed-by: vromero ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java Changeset: aa918a6e Author: Alexander Zuev Date: 2022-02-12 09:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa918a6ec4cd1356efd481c6f6fa94959f94f7b3 8281033: Improve ImageCheckboxTest to test all available LaF Reviewed-by: serb ! test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java Changeset: 58dae60d Author: Alexey Bakhtin Date: 2022-02-12 11:54:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58dae60da0711c4ae0cb23f8ce2328e051d603b2 8274524: SSLSocket.close() hangs if it is called during the ssl handshake Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java + test/jdk/sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java Changeset: 67077a04 Author: Emanuel Peter Committer: David Holmes Date: 2022-02-12 13:08:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67077a04307b512219a46b6c4c274ce308ee46de 8278423: ExtendedDTraceProbes should be deprecated Reviewed-by: dholmes, hseigel, kvn, thartmann ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/man/java.1 ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java Changeset: 8acfbc2e Author: David Holmes Date: 2022-02-12 14:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8acfbc2e21063c3dc088c25c1574bcefa94e5a24 8281675: VMDeprecatedOptions test fails after JDK-8278423 Reviewed-by: dcubed ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: eff5dafb Author: Sergey Bylokhov Date: 2022-02-12 22:10:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eff5dafba9f72bd0612357712ffa472ce1c9166a 8274939: Incorrect size of the pixel storage is used by the robot on macOS Reviewed-by: aivanov, prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! test/jdk/java/awt/Robot/CheckCommonColors/CheckCommonColors.java Changeset: adbe0661 Author: Bhavana Kilambi Committer: Ningsheng Jian Date: 2022-02-14 01:33:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/adbe0661029f12a36a44af52b83b189384d33a27 8239927: Product variable PrefetchFieldsAhead is unused and should be removed Reviewed-by: njian, dholmes ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 483d4b97 Author: Nils Eliasson Date: 2022-02-14 08:27:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/483d4b97e0ae4ab7b0d87058901f57688a0f0811 8281505: Add CompileCommand PrintIdealPhase Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/compiler/directivesParser.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/phasetype.hpp + test/hotspot/jtreg/compiler/oracle/PrintIdealPhaseTest.java Changeset: 1ef45c5b Author: Roland Westrelin Date: 2022-02-14 08:35:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ef45c5bbdeb4e1ca65c6d8f3ac1568a6951f3a7 8280799: ?2: assert(false) failed: cyclic dependency prevents range check elimination Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/loopopts/TestPredicateInputBelowLoopPredicate.java Changeset: 46f52296 Author: Roberto Casta?eda Lozano Date: 2022-02-14 08:37:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46f522962f1b2bbb2513823821e332db1093994b 8281539: IGV: schedule approximation computes immediate dominators wrongly Replace custom dominator computation with one from the WALA libraries. Reviewed-by: neliasso, chagedorn ! src/utils/IdealGraphVisualizer/ServerCompiler/pom.xml ! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java ! src/utils/IdealGraphVisualizer/pom.xml Changeset: 2632d40d Author: Stefan Johansson Date: 2022-02-14 09:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2632d40dfc9f681e53fe04d32b6380ffb4eeb88c 8281637: Remove unused VerifyOption_G1UseNextMarking Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/shared/verifyOption.hpp Changeset: 25972062 Author: Albert Mingkun Yang Date: 2022-02-14 09:15:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2597206242356d42ca5d08be809cfdff79df924d 8280783: Parallel: Refactor PSCardTable::scavenge_contents_parallel Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/parallel/psCardTable.cpp ! src/hotspot/share/gc/parallel/psCardTable.hpp Changeset: c61d629a Author: Emanuel Peter Committer: Christian Hagedorn Date: 2022-02-14 09:52:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c61d629add65f9c25f73c335f2a3c5095da5be52 8281553: Ensure we only require liveness from mach-nodes with barriers Reviewed-by: neliasso, chagedorn ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp Changeset: 95f198b2 Author: Magnus Ihse Bursie Date: 2022-02-14 10:31:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95f198b2b1b2d5437515dc837cc160e4224c0ff3 8274980: Improve adhoc build version strings Reviewed-by: shade, erikj ! .github/workflows/submit.yml ! make/Docs.gmk ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/hotspot/lib/CompileJvm.gmk ! test/jdk/java/lang/RuntimeTests/Version/Basic.java ! test/langtools/tools/javac/options/modes/InfoOptsTest.java Changeset: 534e5578 Author: Vladimir Ivanov Date: 2022-02-14 11:57:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/534e557874274255c55086b4f6128063cbd9cc58 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers Reviewed-by: dlong, kvn ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/interpreter/bootstrapInfo.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! test/jdk/ProblemList-Xcomp.txt Changeset: 2604a88f Author: Leo Korinth Date: 2022-02-14 12:05:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2604a88fbb6d0f9aec51c7d607ea275bc34a672c 8281585: Remove unused imports under test/lib and jtreg/gc Reviewed-by: dholmes, sspitsyn ! test/hotspot/jtreg/gc/TestAllocateHeapAt.java ! test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java ! test/hotspot/jtreg/gc/TestCardTablePageCommits.java ! test/hotspot/jtreg/gc/TestSmallHeap.java ! test/hotspot/jtreg/gc/arguments/TestAggressiveHeap.java ! test/hotspot/jtreg/gc/arguments/TestArrayAllocatorMallocLimit.java ! test/hotspot/jtreg/gc/arguments/TestCompressedClassFlags.java ! test/hotspot/jtreg/gc/arguments/TestG1ConcMarkStepDurationMillis.java ! test/hotspot/jtreg/gc/arguments/TestG1ConcRefinementThreads.java ! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java ! test/hotspot/jtreg/gc/arguments/TestG1PercentageOptions.java ! test/hotspot/jtreg/gc/arguments/TestG1RemSetFlags.java ! test/hotspot/jtreg/gc/arguments/TestHeapFreeRatio.java ! test/hotspot/jtreg/gc/arguments/TestInitialTenuringThreshold.java ! test/hotspot/jtreg/gc/arguments/TestMaxHeapSizeTools.java ! test/hotspot/jtreg/gc/arguments/TestMaxMinHeapFreeRatioFlags.java ! test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java ! test/hotspot/jtreg/gc/arguments/TestMaxRAMFlags.java ! test/hotspot/jtreg/gc/arguments/TestMinAndInitialSurvivorRatioFlags.java ! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestNewSizeFlags.java ! test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java ! test/hotspot/jtreg/gc/arguments/TestObjectTenuringFlags.java ! test/hotspot/jtreg/gc/arguments/TestParallelGCThreads.java ! test/hotspot/jtreg/gc/arguments/TestSelectDefaultGC.java ! test/hotspot/jtreg/gc/arguments/TestSmallInitialHeapWithLargePageAndNUMA.java ! test/hotspot/jtreg/gc/arguments/TestSurvivorRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestUnrecognizedVMOptionsHandling.java ! test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsErgoTools.java ! test/hotspot/jtreg/gc/arguments/TestUseNUMAInterleaving.java ! test/hotspot/jtreg/gc/arguments/TestVerifyBeforeAndAfterGCFlags.java ! test/hotspot/jtreg/gc/epsilon/TestClasses.java ! test/hotspot/jtreg/gc/g1/TestEvacuationFailure.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData.java ! test/hotspot/jtreg/gc/g1/TestSkipRebuildRemsetPhase.java ! test/hotspot/jtreg/gc/stress/gclocker/TestExcessGCLockerCollections.java ! test/lib/RedefineClassHelper.java ! test/lib/jdk/test/lib/OSVersion.java ! test/lib/jdk/test/lib/Utils.java ! test/lib/jdk/test/lib/apps/LingeredApp.java ! test/lib/jdk/test/lib/artifacts/ArtifactManager.java ! test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java ! test/lib/jdk/test/lib/containers/docker/Common.java ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java ! test/lib/jdk/test/lib/format/ArrayCodec.java ! test/lib/jdk/test/lib/format/ArrayDiff.java ! test/lib/jdk/test/lib/helpers/ClassFileInstaller.java ! test/lib/jdk/test/lib/hexdump/ObjectStreamPrinter.java ! test/lib/jdk/test/lib/hprof/model/JavaObjectArray.java ! test/lib/jdk/test/lib/hprof/model/JavaThing.java ! test/lib/jdk/test/lib/hprof/model/JavaValueArray.java ! test/lib/jdk/test/lib/hprof/model/ReachableExcludesImpl.java ! test/lib/jdk/test/lib/hprof/model/ReachableObjects.java ! test/lib/jdk/test/lib/hprof/util/ArraySorter.java ! test/lib/jdk/test/lib/hprof/util/Misc.java ! test/lib/jdk/test/lib/security/KeyStoreUtils.java ! test/lib/jdk/test/lib/security/timestamp/DefaultRespInterceptor.java ! test/lib/jdk/test/lib/security/timestamp/TsaHandler.java ! test/lib/jdk/test/lib/security/timestamp/TsaServer.java ! test/lib/jdk/test/lib/util/JavaAgentBuilder.java Changeset: 9d0a4c3f Author: Brian J. Stafford Committer: Thomas Schatzl Date: 2022-02-14 12:20:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d0a4c3f2e347c30ff56ba1416c08cc662f7f23c 8274238: Inconsistent type for young_list_target_length() Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1Policy.hpp Changeset: f07b8165 Author: Thomas Stuefe Date: 2022-02-14 16:41:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f07b8165231799383303e5c0755d07afd2feb7fd 8280940: gtest os.release_multi_mappings_vm is racy Reviewed-by: dcubed, sjohanss ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 88fc3bfd Author: Vladimir Ivanov Date: 2022-02-14 18:46:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/88fc3bfdff7f89a02fcfb16909df144e6173c658 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant pool entries Reviewed-by: dlong, redestad, neliasso ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_InstructionPrinter.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/opto/parse2.cpp + test/hotspot/jtreg/compiler/runtime/TestConstantDynamic.java ! test/hotspot/jtreg/compiler/runtime/TestConstantsInError.java Changeset: 16f649b9 Author: Ioi Lam Date: 2022-02-14 18:53:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16f649b9c5b480d2a8499b1a92939cdf53ecc8dc 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails after JDK-8279997 Reviewed-by: shade, dcubed ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java Changeset: 1a7b70a8 Author: Phil Race Date: 2022-02-14 23:31:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1a7b70a8be0a236b98925a8320d25d88a405d595 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4 Reviewed-by: serb ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java ! test/jdk/javax/sound/sampled/Clip/SetPositionHang.java Changeset: d4cd8dfe Author: Jaikiran Pai Date: 2022-02-15 03:53:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4cd8dfedbe220fb3b9a68650aba90536e9b12ee 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters Reviewed-by: dfuchs, naoto, mchung ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! test/langtools/tools/jdeps/Options.java Changeset: f33329eb Author: Harshitha Onkar Committer: Prasanta Sadhukhan Date: 2022-02-15 05:03:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f33329eb7f7a1a541d8f30ba8952b0b922ac5257 8016524: [macosx] Bottom line is not visible for JTableHeader Reviewed-by: psadhukhan, prr ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java + test/jdk/javax/swing/JTableHeader/8016524/JTHeaderBorderTest.java Changeset: b1564624 Author: Aleksey Shipilev Date: 2022-02-15 06:19:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b1564624ce454d0df9b2464424b7b5e449481ee6 8281467: Allow larger OptoLoopAlignment and CodeEntryAlignment Reviewed-by: kvn, dlong ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/globals.hpp + test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java + test/hotspot/jtreg/compiler/arguments/TestOptoLoopAlignment.java Changeset: 11f943d1 Author: Kim Barrett Date: 2022-02-15 06:51:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11f943d148e7bc8d931c382ff019b3e65a87432e 8280916: Simplify HotSpot Style Guide editorial changes Reviewed-by: dcubed, dholmes, stuefe, stefank, kvn, tschatzl ! doc/hotspot-style.html ! doc/hotspot-style.md Changeset: 622970e4 Author: Andrey Turbanov Date: 2022-02-15 07:10:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/622970e47cedd6e0b94b74235aa984ad79281389 8281728: Redundant null check in LineNumberInputStream.read Reviewed-by: redestad ! src/java.base/share/classes/java/io/LineNumberInputStream.java Changeset: 8819f453 Author: Nils Eliasson Date: 2022-02-15 08:20:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8819f4535743f6504b4aaa62c7d87926dd1b0013 8281722: Removal of PrintIdealLevel Reviewed-by: chagedorn, thartmann ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: f82866bc Author: Dmitry Markov Date: 2022-02-15 09:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f82866bc79cbeeac23716fa6fadd4877f5d0a462 8281555: [macos] Get rid of deprecated Style Masks constants Reviewed-by: serb, aivanov ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m ! test/jdk/javax/swing/JFrame/NSTexturedJFrame/NSTexturedJFrame.java Changeset: 1c12b159 Author: Nils Eliasson Date: 2022-02-15 09:49:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c12b159ffcbb3528a20ac585d8460bf730e303d 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp Reviewed-by: kvn, chagedorn, thartmann ! test/hotspot/jtreg/compiler/oracle/PrintIdealPhaseTest.java Changeset: 2112a9dc Author: Magnus Ihse Bursie Date: 2022-02-15 11:11:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2112a9dc49a41e11433f19d258d72806b321106c 8246033: bin/print_config.js script uses nashorn jjs tool Reviewed-by: erikj - bin/print-config.js Changeset: bc614840 Author: Albert Mingkun Yang Date: 2022-02-15 12:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc6148407e629bd99fa5a8577ebd90320610f349 8280136: Serial: Remove unnecessary use of ExpandHeap_lock Reviewed-by: iwalulya, kbarrett, sjohanss ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 2fe0bf66 Author: Stefan Johansson Date: 2022-02-15 16:22:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2fe0bf66b7cbbae3dc65249be4b04f4075a98efa 8281748: runtime/logging/RedefineClasses.java failed "assert(addr != __null) failed: invariant" Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp Changeset: 18704653 Author: Aleksey Shipilev Date: 2022-02-15 16:42:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18704653dcc76b6360b746a6a9c20d614633da0e 8281744: x86: Use short jumps in TIG::set_vtos_entry_points Reviewed-by: rehn, coleenp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp Changeset: 745f7e7d Author: Calvin Cheung Date: 2022-02-15 17:18:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/745f7e7d921afcf45a2fa87824841e4545054d21 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails Reviewed-by: minqi, iklam, stuefe ! test/hotspot/jtreg/runtime/cds/appcds/DumpingWithNoCoops.java Changeset: 394ce5f9 Author: Christian Stein Committer: Lance Andersen Date: 2022-02-15 17:55:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/394ce5f948c21b3861d76dd8db57957efa1df979 8280825: Modules that "provide" ToolProvider should document the name that can be used Reviewed-by: jjg, lancea, alanb ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.jartool/share/classes/module-info.java ! src/jdk.javadoc/share/classes/module-info.java ! src/jdk.jdeps/share/classes/module-info.java ! src/jdk.jlink/share/classes/module-info.java ! src/jdk.jpackage/share/classes/module-info.java Changeset: 1aff44b2 Author: Leonid Mesnik Date: 2022-02-15 17:59:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1aff44b2cfcf5d2253161985b902894ee69365fc 8279949: JavaThread::_free_handle_block leaks native memory Reviewed-by: dholmes, coleenp ! src/hotspot/share/runtime/jniHandles.cpp Changeset: a24498b7 Author: Leonid Mesnik Date: 2022-02-15 18:01:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a24498b777b76c04d7e6da0a8b5fb501f2fb4944 8281771: Crash in java_lang_invoke_MethodType::print_signature Reviewed-by: dholmes, shade ! src/hotspot/share/classfile/javaClasses.cpp Changeset: 0af356bb Author: Quan Anh Mai Committer: Sandhya Viswanathan Date: 2022-02-15 18:57:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0af356bb4bfee99223d4bd4f8b0001c5f362c150 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts Reviewed-by: psandoz, sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/tests/TestVectorCast.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/TestCastMethods.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/VectorReshapeHelper.java Changeset: a86cab8d Author: TheShermanTanker Committer: Tobias Hartmann Date: 2022-02-16 07:50:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a86cab8d4259f29af86aa6063b721e47827fb949 8236136: tests which use CompilationMode shouldn't be run w/ TieredStopAtLevel Reviewed-by: neliasso, kvn, thartmann ! test/hotspot/jtreg/compiler/compilercontrol/CompilationModeHighOnlyTest.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass/Launcher.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: fef5d74d Author: Aleksey Shipilev Date: 2022-02-16 09:42:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fef5d74d0e7fb32e3f63e9fbc34c5370e683e451 8281812: x86: Use short jumps in TemplateTable::condy_helper Reviewed-by: redestad, neliasso ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: d5b46665 Author: Jie Fu Date: 2022-02-16 13:46:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5b466657e29a5338b84fa9acfc1b76bf8c39d61 8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467 Reviewed-by: kvn, thartmann ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp Changeset: 7428b376 Author: Erik Gahlin Date: 2022-02-16 15:35:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7428b37696f1093094e69410f36dbb74098c9d4d 8281948: JFR: Parser skips too many bytes for fractional types Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ParserFactory.java Changeset: d8f44aa3 Author: Michael McMahon Date: 2022-02-16 16:01:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8f44aa39e921594505864e6270f42b745265293 8278067: Make HttpURLConnection default keep alive timeout configurable Reviewed-by: dfuchs ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java + test/jdk/sun/net/www/http/KeepAliveCache/KeepAliveProperty.java Changeset: 395bc141 Author: Emanuel Peter Committer: Christian Hagedorn Date: 2022-02-16 16:19:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733 8281732: add assert for non-NULL assumption for return of unique_ctrl_out Reviewed-by: kvn, chagedorn, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/multnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp Changeset: 0f3d3ac3 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2022-02-16 16:43:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f3d3ac32c9d163a5d91c6839d313111c72f1ad4 8061729: Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs Reviewed-by: dfuchs ! test/jdk/sun/net/www/http/HttpClient/ProxyFromCache.java ! test/jdk/sun/net/www/http/HttpClient/RequestURI.java ! test/jdk/sun/net/www/protocol/http/CloseOptionHeader.java + test/jdk/sun/net/www/protocol/http/HttpHeaderParserTest.java ! test/jdk/sun/net/www/protocol/http/NTLMTest.java ! test/jdk/sun/net/www/protocol/http/NoNTLM.java ! test/jdk/sun/net/www/protocol/http/RetryUponTimeout.java ! test/jdk/sun/net/www/protocol/http/UserAgent.java ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java + test/lib/jdk/test/lib/net/HttpHeaderParser.java Changeset: 9b74c3f2 Author: Naoto Sato Date: 2022-02-16 16:54:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9b74c3f2e74a4efdec1c1488e96ab5939a408df0 8176706: Additional Date-Time Formats Reviewed-by: joehw, rriggs ! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java ! make/jdk/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java ! src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java + test/jdk/java/time/test/java/time/format/Skeletons_en_US.properties + test/jdk/java/time/test/java/time/format/Skeletons_ja.properties + test/jdk/java/time/test/java/time/format/TestLocalizedPattern.java Changeset: bb4dece2 Author: Alexey Semenyuk Date: 2022-02-16 17:30:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb4dece246a56f2b225089c331e9f3d092dfbfa1 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinInstallerIconTest.java Changeset: 81645521 Author: Alexey Semenyuk Date: 2022-02-16 17:31:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81645521c81c7363d199e5051d51043146058a91 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java Changeset: 980d1878 Author: Mandy Chung Date: 2022-02-16 18:31:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/980d18789139295c95ec6045539b68d1ae57bc31 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library Reviewed-by: sundar, mcimadamore ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java + src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! test/jdk/jdk/internal/loader/NativeLibraries/Main.java ! test/jdk/jdk/internal/loader/NativeLibraries/java.base/jdk/internal/loader/NativeLibrariesTest.java Changeset: 847a99b5 Author: Aleksey Shipilev Date: 2022-02-16 20:08:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/847a99b53da6b2c82f7cd5f8634aa7bbae8f445e 8281822: Test failures on non-DTrace builds due to incomplete DTrace* flags handling Reviewed-by: dholmes, kvn ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/compiler/runtime/Test8168712.java ! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java + test/hotspot/jtreg/serviceability/dtrace/DTraceOptionsTest.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 67763df4 Author: Tim Prinzing Committer: Mandy Chung Date: 2022-02-16 20:09:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67763df4dce387da33da6d93d0f5d80e54cf8e5b 8281003: MethodHandles::lookup throws NPE if caller is null Reviewed-by: ihse, mchung, jrose, alanb ! make/test/JtregNativeJdk.gmk ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/NullCallerLookupTest.java + test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/exeNullCallerLookupTest.c Changeset: 48f6e930 Author: Daniel Fuchs Date: 2022-02-16 21:38:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48f6e93079f377a621ca769b820fa221062ceab1 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed Reviewed-by: michaelm, naoto ! test/jdk/ProblemList.txt Changeset: 9ba0760c Author: Martin Desruisseaux Committer: Alexey Ivanov Date: 2022-02-16 22:01:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ba0760cf85f9e843f3383b725017c9ffac350df 8275345: RasterFormatException when drawing a tiled image made of non-writable rasters Reviewed-by: prr, aivanov ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java + test/jdk/java/awt/image/DrawImage/TiledImage.java Changeset: 5ec7898d Author: Joe Darcy Date: 2022-02-16 22:02:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ec7898dbf1ebe261e5e25939cad42134611ff12 8281671: Class.getCanonicalName spec should explicitly cover array classes Reviewed-by: mchung ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/NameTest.java Changeset: 0b00ce17 Author: Alexey Semenyuk Date: 2022-02-16 23:23:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b00ce17cd6b530d9394e79ac8b07208cd4b92f5 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinL10nTest.java Changeset: 2be2a298 Author: Tobias Hartmann Date: 2022-02-15 07:07:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2be2a298f13c3a38d9518ccfea11dfd8a736d56c 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp - test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java Changeset: 0f2113ce Author: Pavel Kharskii Committer: Jesper Wilhelmsson Date: 2022-02-15 09:24:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f2113cee79b9645105b4753c7d7eacb83b872c2 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022 Reviewed-by: erikj, iris ! make/conf/version-numbers.conf Changeset: b6e48e67 Author: Jesper Wilhelmsson Date: 2022-02-17 01:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6e48e678244481dd45d38bc3ddc325fccda2acc Merge ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: cd234f5d Author: Alexey Semenyuk Date: 2022-02-17 05:27:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd234f5dbebd18ebf0c78dfdf533318cdc627971 8282007: Assorted enhancements to jpackage testing framework Reviewed-by: almatvee ! test/jdk/tools/jpackage/apps/Hello.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/CfgFile.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/RunnablePackageTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java ! test/jdk/tools/jpackage/run_tests.sh ! test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java - test/jdk/tools/jpackage/test_jpackage.sh ! test/jdk/tools/jpackage/windows/WinUpgradeUUIDTest.java Changeset: 1eec16b4 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2022-02-17 05:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1eec16b47be300e1462528bddf5d0686df3f042c 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE Reviewed-by: aph, njian ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 1864481d Author: Ioi Lam Date: 2022-02-17 06:40:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1864481df10d2f616cbfdecebf3bebbae04de5e1 8279969: NULL return from map_bitmap_region() needs to be checked Reviewed-by: ccheung, coleenp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/heapShared.cpp ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java Changeset: c0275e18 Author: Tyler Steele Committer: Thomas Stuefe Date: 2022-02-17 08:49:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0275e18b7cb4a01385b79ced46560322aeacc97 8203290: [AIX] Check functionality of JDK-8199712 (Flight Recorder) Implements JFR for AIX Reviewed-by: erikj, mdoerr, mgronlun, stuefe, ihse ! make/autoconf/jvm-features.m4 ! src/hotspot/os/aix/libperfstat_aix.cpp ! src/hotspot/os/aix/libperfstat_aix.hpp ! src/hotspot/os/aix/loadlib_aix.cpp ! src/hotspot/os/aix/loadlib_aix.hpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_perf_aix.cpp ! src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp ! test/jdk/ProblemList.txt ! test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java Changeset: b4900b12 Author: Prasanta Sadhukhan Date: 2022-02-17 09:36:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4900b1298e536c0ceaa77bc0ac0e8e6ccba6400 8264743: Add forRemoval for deprecated classes and method in javax/swing/plaf/basic Reviewed-by: trebari, prr ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java Changeset: 9ca435b4 Author: Julia Boes Date: 2022-02-17 10:35:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ca435b4c03f9741709bbfab22fb006de8c8c9d3 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java + src/jdk.httpserver/unix/classes/sun/net/httpserver/simpleserver/URIPathSegment.java + src/jdk.httpserver/windows/classes/sun/net/httpserver/simpleserver/URIPathSegment.java ! test/jdk/com/sun/net/httpserver/simpleserver/MapToPathTest.java Changeset: 3b7a3cfc Author: Albert Mingkun Yang Date: 2022-02-17 11:40:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3b7a3cfce345cc900e042c5378d35d1237bdcd78 8281971: Remove unimplemented InstanceRefKlass::do_next Reviewed-by: dholmes ! src/hotspot/share/oops/instanceRefKlass.hpp Changeset: d0e11808 Author: Andrey Turbanov Date: 2022-02-17 12:31:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d0e11808fd688d96e5cfeb586d1de277f26da5ad 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath Reviewed-by: bpb, darcy ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 4c7f8b49 Author: Joe Darcy Date: 2022-02-17 17:12:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c7f8b49a4845acf58272c42327328d6d2837cea 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Reviewed-by: sundar, alanb ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/ArrayType.java Changeset: a6f8a386 Author: Tim Prinzing Committer: Mandy Chung Date: 2022-02-17 17:34:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6f8a386efa7af162f4b815951287f0a9bc1f396 8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null Reviewed-by: erikj, ihse, mchung, bchristi ! make/test/JtregNativeJdk.gmk ! src/java.base/share/classes/java/lang/ClassLoader.java + test/jdk/java/lang/ClassLoader/BadRegisterAsParallelCapableCaller.java + test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/NullCallerClassLoaderTest.java + test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/exeNullCallerClassLoaderTest.c Changeset: cd9a3cf0 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2022-02-17 17:45:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd9a3cf05b2c200709103e2e8596414a62a1c441 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" Reviewed-by: dfuchs ! test/jdk/ProblemList.txt ! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java Changeset: 12927765 Author: Naoto Sato Date: 2022-02-17 19:03:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/129277653e51e9b1387ecee279a6ccee9199c8ff 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range Reviewed-by: joehw ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! test/jdk/java/text/Format/CompactNumberFormat/TestCompactPatternsValidity.java Changeset: 69fc273f Author: Daniel D. Daugherty Date: 2022-02-17 20:56:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69fc273f202352f74a313c37db0198be2be08616 8282075: ProblemList 3 compiler/whitebox tests on macosx-x64 Reviewed-by: mikael, bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: f830cbec Author: Magnus Ihse Bursie Date: 2022-02-17 21:18:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f830cbec909b91ad0f00f46a3496d83ecb5912ed 8188073: Add Capstone as backend for hsdis Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jorn Vernee Reviewed-by: erikj ! make/Hsdis.gmk ! make/autoconf/help.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in - src/utils/hsdis/README + src/utils/hsdis/README.md = src/utils/hsdis/binutils/hsdis-binutils.c + src/utils/hsdis/capstone/hsdis-capstone.c ! src/utils/hsdis/hsdis.h Changeset: fdce35f3 Author: Jie Fu Date: 2022-02-17 22:53:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdce35f3a1c12a64238d0c76c02451a25b0b4abb 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732 Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: a22f422b Author: Prasanta Sadhukhan Date: 2022-02-18 04:56:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a22f422b7f18dc134e48c6193bf690004635bf7d 8037573: Typo in DefaultTreeModel docs: askAllowsChildren instead of asksAllowsChildren Reviewed-by: prr, jdv, azvegint ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java Changeset: c9289583 Author: Jie Fu Date: 2022-02-18 05:02:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c9289583eb6919ced3b4115cf981180f6a957fbf 8281936: compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines Reviewed-by: shade, kvn ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Changeset: 7bcca769 Author: Roberto Casta?eda Lozano Date: 2022-02-18 08:35:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bcca7692b62a37f70c757694f6acff0295371cc 8279068: IGV: Update to work with JDK 16 and 17 Reviewed-by: kvn, neliasso, chagedorn ! src/utils/IdealGraphVisualizer/Bytecodes/pom.xml ! src/utils/IdealGraphVisualizer/ControlFlow/pom.xml ! src/utils/IdealGraphVisualizer/Coordinator/pom.xml ! src/utils/IdealGraphVisualizer/Data/pom.xml ! src/utils/IdealGraphVisualizer/Difference/pom.xml ! src/utils/IdealGraphVisualizer/Filter/pom.xml ! src/utils/IdealGraphVisualizer/FilterWindow/pom.xml ! src/utils/IdealGraphVisualizer/Graal/pom.xml ! src/utils/IdealGraphVisualizer/Graph/pom.xml ! src/utils/IdealGraphVisualizer/HierarchicalLayout/pom.xml ! src/utils/IdealGraphVisualizer/Layout/pom.xml ! src/utils/IdealGraphVisualizer/NetworkConnection/pom.xml ! src/utils/IdealGraphVisualizer/README.md ! src/utils/IdealGraphVisualizer/SelectionCoordinator/pom.xml ! src/utils/IdealGraphVisualizer/ServerCompiler/pom.xml ! src/utils/IdealGraphVisualizer/Settings/pom.xml ! src/utils/IdealGraphVisualizer/Util/pom.xml ! src/utils/IdealGraphVisualizer/View/pom.xml ! src/utils/IdealGraphVisualizer/application/pom.xml + src/utils/IdealGraphVisualizer/application/src/main/resources/idealgraphvisualizer.conf ! src/utils/IdealGraphVisualizer/branding/pom.xml ! src/utils/IdealGraphVisualizer/pom.xml Changeset: 138a1719 Author: Alex Menkov Date: 2022-02-18 09:21:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/138a17195d1695c6faaa156a43624c39c62b141b 8281267: VM HeapDumper dumps array classes several times Reviewed-by: cjplummer, coleenp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/services/heapDumper.cpp + test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java Changeset: 834d55c5 Author: Jan Lahoda Date: 2022-02-18 09:41:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/834d55c59f94674f521efda0b9801551a39c7c4d 8277300: Issues with javadoc support for preview features Reviewed-by: prappo, jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API2.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/api/API3.java + test/langtools/jdk/javadoc/doclet/testPreview/api2/module-info.java Changeset: e8224f7d Author: Albert Mingkun Yang Date: 2022-02-18 09:54:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e8224f7de9e4649105cfb0dd9e6a588505be4211 8282089: [BACKOUT] Parallel: Refactor PSCardTable::scavenge_contents_parallel Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psCardTable.cpp ! src/hotspot/share/gc/parallel/psCardTable.hpp Changeset: cd3b60d5 Author: duke Date: 2022-02-18 11:00:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd3b60d57a1cf27e556ad4a57acd678aaa319e62 Automatic merge of jdk:master into master From mcimadamore at openjdk.java.net Fri Feb 18 11:21:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 11:21:49 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v2] In-Reply-To: References: Message-ID: <58MEbd3vg0JjQxomG4yTEPhACm900oRbKVKBVQ_goB0=.d71d4df4-2acc-411a-84c0-464233de3768@github.com> > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix more spurious usages of ResourceScope ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/641/files - new: https://git.openjdk.java.net/panama-foreign/pull/641/files/0d779de6..d9f36bec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=00-01 Stats: 11 lines in 6 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Fri Feb 18 11:30:07 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 11:30:07 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v2] In-Reply-To: <0TcHY52s9k_K1TjtaeiMZ0pJ61KfjAGBHlzh12pup5I=.daf46a16-d50a-46d5-bc12-dc1b6f92a1e2@github.com> References: <1WfWM9Mevh0FGsT2wVfqwxhnYjDffm2MtKnDurPozpQ=.301f6564-74c6-47fc-a1b6-b1e2bba66354@github.com> <0TcHY52s9k_K1TjtaeiMZ0pJ61KfjAGBHlzh12pup5I=.daf46a16-d50a-46d5-bc12-dc1b6f92a1e2@github.com> Message-ID: On Fri, 18 Feb 2022 11:10:03 GMT, Quan Anh Mai wrote: >>> hat option was also considered, but discarded because it would make `SegmentAllocator` stateful, e.g. more complex than just a functional interface. >> >> Note that today there is no contract which says that all segments returned by a `SegmentAllocator` must have the same session. While some allocators might behave like that, I think it would not be ok to force that behavior on _all_ allocators. And, we considered to add, perhaps in the future, some small subinterface, like `ScopedSegmentAllocator` which also has a `session` accessor - this would be a good return type for the arena allocator methods, for instance. But this is a move that is orthogonal to the changes described in this PR (and also not a binding one - we can add the sub-interface even at a later point w/o breaking compatibility). > > Thanks a lot for your clarification, I still think that having a scope that throw on `close()` sounds a lot like the problem with `UnmodifiableCollection` but it seems the alternatives have been considered already. > Indeed the issues are similar. However, there are some characteristics that are unique to this API. MemorySegment is a lower-level API than, say Collection. Also, while we currently do not generate method handles which require a `MemorySession`, adding intricate subtyping hierarchies always has a cost when interacting with `invokeExact` - so this API often errs on the side of "avoid unnecessary intermediate types, if we can avoid it". Not to dismiss your concern, which is a valid one - just wanted to explain some of the rationale behind some of the API decisions we've been doing. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From duke at openjdk.java.net Fri Feb 18 11:46:55 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 18 Feb 2022 11:46:55 GMT Subject: [foreign-preview] RFR: Merge master [v2] In-Reply-To: References: Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 91 commits from the branch `master`that can **not** be merged into the branch `foreign-preview`: > > The following file contains merge conflicts: > > - src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-preview > $ git pull https://github.com/openjdk/panama-foreign.git foreign-preview > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +114:openjdk-bot-114 > $ git checkout openjdk-bot-114 > > # Merge the target branch > $ git merge foreign-preview > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-114:114 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke 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 665 additional commits since the last revision: - Merge branch 'foreign-preview' into openjdk-bot-114 - 8281595: ASM-ify scope acquire/release for down call parameters 8281387: Some downcall shapes show unexpected allocations Co-authored-by: Maurizio Cimadamore Reviewed-by: mcimadamore - Automatic merge of master into foreign-preview - 8281334: MemorySegment.ofBuffer does not keep byte buffer alive Reviewed-by: jvernee, psandoz - 8281228: Preview branch's CLinker.downcallHandle crashes inside asm Reviewed-by: sundar, jvernee - Automatic merge of master into foreign-preview - 8280596: ScopedMemoryAccess_closeScope: remove exception parameter Reviewed-by: mcimadamore - 8281147: Other tests that use the foreign API are missing --enable-preview Reviewed-by: mcimadamore - 8278414: Replace binding recipe customization using MH combinators with bytecode spinning Reviewed-by: mcimadamore - 8276647: Remove C2 trivial call intrinsification support Reviewed-by: mcimadamore - ... and 655 more: https://git.openjdk.java.net/panama-foreign/compare/cd3b60d5...125bce2b ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/645/files - new: https://git.openjdk.java.net/panama-foreign/pull/645/files/cd3b60d5..125bce2b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=645&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=645&range=00-01 Stats: 46291 lines in 428 files changed: 33974 ins; 10369 del; 1948 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/645.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/645/head:pull/645 PR: https://git.openjdk.java.net/panama-foreign/pull/645 From duke at openjdk.java.net Fri Feb 18 11:46:56 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 18 Feb 2022 11:46:56 GMT Subject: [foreign-preview] Integrated: Merge master In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 11:01:19 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 91 commits from the branch `master`that can **not** be merged into the branch `foreign-preview`: > > The following file contains merge conflicts: > > - src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-preview > $ git pull https://github.com/openjdk/panama-foreign.git foreign-preview > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +114:openjdk-bot-114 > $ git checkout openjdk-bot-114 > > # Merge the target branch > $ git merge foreign-preview > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-114:114 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke This pull request has now been integrated. Changeset: f4183182 Author: J. Duke Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/f41831820ce3f70f86904c1fa1e0f1e80cdefefe Stats: 12146 lines in 384 files changed: 8667 ins; 1979 del; 1500 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/645 From sundar at openjdk.java.net Fri Feb 18 12:49:40 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 18 Feb 2022 12:49:40 GMT Subject: [foreign-jextract] RFR: 8281764: jextract does not generate parameter names for function pointer typedefs Message-ID: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> Propagating TypedefDecl's ParmDecl child cursors to Types. ------------- Commit messages: - 8281764: jextract does not generate parameter names for function pointer typedefs Changes: https://git.openjdk.java.net/panama-foreign/pull/646/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281764 Stats: 142 lines in 11 files changed: 120 ins; 2 del; 20 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/646.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/646/head:pull/646 PR: https://git.openjdk.java.net/panama-foreign/pull/646 From maurizio.cimadamore at oracle.com Fri Feb 18 14:30:07 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 14:30:07 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> Message-ID: <8fbe8276-29d2-15a7-c7f5-70184b9de48f@oracle.com> Hi, quick update on this. The problem with library loading in JDK being too strict for Panama has been fixed upstream (thanks Mandy!): https://git.openjdk.java.net/jdk/pull/7435 We've just merged those changes into the Panama repo - which means that, if you build the latest version of the repo, you should be able to verify that the workarounds are no longer required. Please let us know how that goes. Cheers Maurizio On 10/02/2022 10:05, Maurizio Cimadamore wrote: > I have managed to create a simple reproducer on Windows: > > import jdk.incubator.foreign.CLinker; > > public class TestLookup { > ??? public static void main(String[] args) { > ??????? System.load("C:\\Windows\\System32\\ucrtbase.dll"); > ??????? CLinker.systemCLinker().lookup("foo"); > ??? } > } > > The call to CLinker::lookup fails with UnsatisfiedLinkError as > ucrtbase is already loaded by the application class loader. > > This seems to be a bug in the library loading mechanism - we do have a > "raw" library loading mechanism that is not subject to JNI restrictions: > > https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L99 > > > This library loader ends up calling this method which contains a class > loader check: > > https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L203 > > > I believe this loader check should be guarded by a "isJNI" flag, as we > did for other checks - e.g. whether JNI_OnLoad should be called. > > Cheers > Maurizio > > On 07/02/2022 12:19, Maurizio Cimadamore wrote: >> No problem. >> >> I've filed this: >> >> https://bugs.openjdk.java.net/browse/JDK-8281335 >> >> Cheers >> Maurizio >> >> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >>> Hi Maurizio, >>> >>> thanks allot for your help and for the investigation. >>> >>> best regards, >>> Clemens >>> >>> >>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>>> wrote: >>>> >>>> ? >>>> >>>> Hi Clemens (it seems like your message got dropped by the mailing >>>> list, not sure why). >>>> >>>> Your message seems to point at some bad interaction between >>>> jpackage and Panama both trying to load ucrtbase.dll (and only one >>>> can win). Apparently, the Panama code isn't executed early enough >>>> in the jpackage case. >>>> >>>> We'll need to investigate more. >>>> >>>> Maurizio >>>> >>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>>> Hello everybody, >>>>> >>>>> I am the developer of project librawfx >>>>> (github.com/lanthale/librawfx) and the app Photoslide >>>>> (github.com/lanthale/photoslide). >>>>> >>>>> At the begining of Photoslide the whole app was modularized and >>>>> therefore all was working including librawfx which is using >>>>> project Panama. After a while I had to change to a mixed >>>>> (modulepath for jdk+javafx libs and classpath for the rest) >>>>> environment and deployed my app PhotoSlide again. Under Linux and >>>>> OSX all is working as expected. The problem exists only under >>>>> Windows. Furthermore it exists only if I am creating a >>>>> Jlink/Jpackage distribution. Running the app from maven was >>>>> working as expected. Only the JPackage launcher have the issue and >>>>> I have no clue what the root cause is. >>>>> >>>>> The exception I am always seeing is: >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>> SCHWERWIEGEND: null >>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>> classloader >>>>> (Full stacktrace below) >>>>> >>>>> How can you reproduce the issue: >>>>> >>>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>>>> ?2. Start the app with "mvn javafx:run at default-cli" >>>>> ?3. Click on the open icon in the toolbar and select file >>>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>>> >>>>> ?4. The app is showing the image below the textarea >>>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>>>> ??? install" >>>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>>> ?7. Open the same file again -> No image is shown below the text >>>>> ??? area and the exception is thrown in the background >>>>> >>>>> >>>>> I have tried many things but it is only happening if I have >>>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>>>> files on the classpath. All libs which are not having any Panama >>>>> code inside of the app are working perfectly and it is only >>>>> happening on Windows. >>>>> >>>>> Thank you in advance for your help! >>>>> >>>>> best regards, >>>>> Clemens >>>>> >>>>> >>>>> >>>>> >>>>> *Full stacktrace from Photoslide:* >>>>> >>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>>>> createSearchIndex >>>>> INFORMATION: Start time create searchDB: 2022-02-03T19:44:41.693455 >>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>>>> lambda$checkForSoftwareUpdates$2 >>>>> INFORMATION: No new version found! >>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>>>> lambda$createSearchIndex$0 >>>>> INFORMATION: End time create searchDB: 2022-02-03T19:44:43.186194400 >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>>> SCHWERWIEGEND: null >>>>> java.lang.UnsatisfiedLinkError: Native Library >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>>> classloader >>>>> at >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>> Source) >>>>> at >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>>>> Source) >>>>> at >>>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>>>> Source) >>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>>> at >>>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>>> >>>>> at org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>>>> Source) >>>>> at >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>>>> Source) >>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >>>>> at >>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>>> >>>>> at >>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>>> >>>>> at >>>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>>>> Source) >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>> at >>>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>>>> Source) >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>>> at >>>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>>> Source) >>>>> at >>>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>> Source) >>>>> at java.base/java.lang.Thread.run(Unknown Source) From mcimadamore at openjdk.java.net Fri Feb 18 14:31:15 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 14:31:15 GMT Subject: [foreign-jextract] RFR: 8281764: jextract does not generate parameter names for function pointer typedefs In-Reply-To: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> References: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> Message-ID: On Fri, 18 Feb 2022 12:42:39 GMT, Athijegannathan Sundararajan wrote: > Propagating TypedefDecl's ParmDecl child cursors to Types. Looks good - I've added a suggestion to perhaps reduce the impact of the changes on TypeMaker. src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TypeMaker.java line 127: > 125: } > 126: > 127: Type makeTypeInternal(jdk.internal.clang.Type t, List params) { I believe you can avoid all the changes to this method, and have a simple method on FunctionType which gets a parameter name list and gives you a _new_ function type with the list in it - e.g. `withParameterNames`. Then you can call that method from `TreeMaker` _after_ you have parsed a `Type`. ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/646 From mcimadamore at openjdk.java.net Fri Feb 18 18:22:37 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 18:22:37 GMT Subject: [foreign-preview] RFR: 8282069: Set correct alignment constraints on ValueLayout constants Message-ID: Now that we have a good understanding of how to enforce alignment checks for both off-heap _and_ heap segments, we are in a position to set the correct alignment constraints on the various `ValueLayout.JAVA_XYZ` constants. The source changes are quite trivial; fixing the tests less so. The main issue is that some of the test are quite liberal in moving things in and out of `byte[]`. E.g. they create a `byte[]` and want to store a `JAVA_LONG` in it. If `JAVA_LONG` has the correct alignment (8 bytes) there's no way we can guarantee correctness and the code now fails (correctly). Also, we now proprerly check alignment on bulk copy operations too - so bulk copy tests, which were ok before, now fail when correct alignment constraints are applied. I've fixed some of the tests in simple ways - e.g. by using a `long[]` instead of a `byte[]`. But in some of the most complex tests I had to define unaligned layouts, as some of the tests are peeking and poking at memory in ways that is not compatible with aligned access (the byte buffer test is a good one, as byte buffer access is not aligned). Also, I had to tweak some code in the `BindingSpecializer` class - some of the bindings can sometimes read multiple fields in a single shot - so e.g. if you have a struct like `[f32 f32]` a single `long` read is performed to read both fields. This means that we do a `JAVA_LONG` read, but with an underlying memory alignment of 4, which is not going to work in some cases (especially in upcalls, where we use an arena allocator to allocate temp buffers; the arena allocator can "pack" structs more than just using `malloc`). For this reason I had to change that code to use unaligned layouts as well. ------------- Commit messages: - Fix spliterator test - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/647/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=647&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282069 Stats: 162 lines in 9 files changed: 41 ins; 20 del; 101 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/647.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/647/head:pull/647 PR: https://git.openjdk.java.net/panama-foreign/pull/647 From psandoz at openjdk.java.net Fri Feb 18 18:23:22 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 18 Feb 2022 18:23:22 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v4] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 02:52:06 GMT, Smita Kamath wrote: >> 8281562:[vectorapi] Add support for popcount operation > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Adding bitCount support for byte and short types. Added test case in the test framework Test update looks good. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 685: > 683: v0.uOp(m, (i, a) -> ($type$) Math.abs(a)); > 684: #if[!FP] > 685: #if[!double] No need for `#if[!double]` ? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 693: > 691: #end[intOrLong] > 692: #end[!double] > 693: #end[!FP] Suggestion: #end[!FP] src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 2047: > 2045: #end[!intOrLong] > 2046: #end[!double] > 2047: #end[!FP] Suggestion: #end[!FP] ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From psandoz at openjdk.java.net Fri Feb 18 18:23:25 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 18 Feb 2022 18:23:25 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v4] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 23:12:06 GMT, Paul Sandoz wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding bitCount support for byte and short types. Added test case in the test framework > > test/jdk/jdk/incubator/vector/PopcountUnitTest.java line 39: > >> 37: import java.util.stream.IntStream; >> 38: >> 39: public class PopcountUnitTest { > > You should replace this test by adding a bitcount test to test framework. Don't forgot to remove this test ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From psandoz at openjdk.java.net Fri Feb 18 18:55:15 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 18 Feb 2022 18:55:15 GMT Subject: [foreign-preview] RFR: 8282070: Drop workaround from memory segment implementation [v2] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 10:14:34 GMT, Maurizio Cimadamore wrote: >> Following some preliminary experiments (see [1]) it is now finally time to drop the various workarounds we have in the memory segment implementation. This patch removes two workarounds: >> >> * special treatment for "small" segments (e.g. segments whose size fits in an int) - see `MemorySegment::isSmall`; these segments were special cased so that bound checks would only involve `int` comparisons. This has now been fixed in JDK-8276116, and special treatment is no longer required. >> >> * special shortcuts to avoid extra alignment checks. Since when generating var handles from a layout we check most of the alignment constraints (except those involving the base address), in the past we have added a fastpath for these var handles, as C2 had trouble hoisting alignment checks outside of the loops. This has now been fixed in JDK-8277850 and is no longer required. >> >> I have run benchmarks before and after and got identical results. Some benchmarkks in `ParallelSum` got a boost, but those always have noise, due to multi-threading. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > * inlined Utils::scaleOffset into callsites > * drop redundant check from AbstractMemorySegment::checkBounds Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From maurizio.cimadamore at oracle.com Fri Feb 18 19:26:08 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 19:26:08 +0000 Subject: musinig on close actions Message-ID: <5903b39a-b728-253f-63d7-9d0edcbbc69c@oracle.com> Hi, I wanted to capture some thoughts on scope close actions, which originated from the good discussions we had in [1]. Basically, the status quo is that a close action is called _after_ the scope is closed. This is a forced move: when we execute the close action, we already have determined that e.g. the scope is not accessed by any other thread. If resources were still accessible by close actions, then closing a scope would not be safe (as they could be leaked to other threads). There is a minor inconvenience with this approach: if a close action needs to refer to some of the resources associated with the scope (e.g. a segment), the action needs to work on the resource using its memory address, thus losing safety and also expressiveness (e.g. to use var handles you need a memory segment). This was the issue pointed out in [1] with the FFmpeg API. There are other situations in which working on segments, rather than addresses, might be preferrable: for instance, one can come up with an API which turns an heap segment into an off-heap segment, inside a given scope (e.g. pinning). In certain cases where pinning is not supported directly by the GC, it might be required to copy the contents of the native segment back to the on-heap segment once the scope is closed. But if the segment is not alive after close, there's no way to do the copy. I've been toying with an idea, which builds upon the following two observations: 1. Resource-specific close actions are likely to arise when using the `MemorySegment::ofAddress` methods (or any of the `XYZ::ofAddress` factories) 2. A close action could safely operate on a *view* of the half-alive resource based on a "closingScope" which is confined on the thread that does the closing The API move that I have in mind is this: let's assume that we added an overload to `MemorySegment`, as follows: ``` static MemorySegment ofAddress(MemoryAddress addr, long size, MemorySession session, Consumer cleanupAction) ``` Which can be used as follows: ``` MemoryAddress addr = .... MemorySegment segment = MemorySegment.ofAddress(addr, 10L, session, ???????????????? segmentView -> println(segmentView.get(JAVA_DOUBLE, offset))); ``` How does this work? After a scope transitions into the closed state, but _before_ cleanup actions are called, the scope would spawn a _new_ _confined_ scope, owned by the thread from which cleanup action are called. That scope is then used to create resource views that will be passed to the close actions. The new session is then closed after _all_ the close actions have been executed. Crucially, since all views are confined and cannot? be accessed after `MemorySession::close()` completes, this works out ok safety-wise, I believe. In a way, this is a restricted form of safe handoff of a resource, from one scope to another. This allows clients to express close actions at the right level of abstraction, without the need to give up safety/expressiveness and drop down to `MemoryAddress`. Please note that I'm not proposing to drop support for "global" close actions (e.g. the `MemorySession::addCloseAction` method). These are still useful in many cases, as we've seen for pooled allocators [2]. So the above mechanism would be an addition to the API, rather than a replacement (and one that can also be considered at a later point, if needs be). Any thoughts on whether something like this could help? Cheers Maurizio [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016173.html [2] - https://github.com/openjdk/panama-foreign/pull/509 From psandoz at openjdk.java.net Fri Feb 18 19:29:12 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 18 Feb 2022 19:29:12 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v2] In-Reply-To: <58MEbd3vg0JjQxomG4yTEPhACm900oRbKVKBVQ_goB0=.d71d4df4-2acc-411a-84c0-464233de3768@github.com> References: <58MEbd3vg0JjQxomG4yTEPhACm900oRbKVKBVQ_goB0=.d71d4df4-2acc-411a-84c0-464233de3768@github.com> Message-ID: <5gTvauyTl56VCXax0Q53qVC76h1g8zWfSBzRO_gql9M=.c8df47a7-d51f-4410-9bc1-15e73a201ab9@github.com> On Fri, 18 Feb 2022 11:21:49 GMT, Maurizio Cimadamore wrote: >> This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html >> [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix more spurious usages of ResourceScope Marked as reviewed by psandoz (Committer). src/java.base/share/classes/java/lang/ClassLoader.java line 2470: > 2468: > 2469: // A resource scope which keeps this loader reachable. Useful when returning > 2470: // native symbols associated with libraries loaded by this loader. Suggestion: // A memory session which keeps this loader reachable. Useful when returning // native symbols associated with libraries loaded by this loader. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 303: > 301: > 302: public long address() { > 303: MemorySession scope = session(); Suggestion: MemorySession session = session(); src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 94: > 92: * acquiring is not required to guarantee safety. > 93: */ > 94: Runnable acquireSession(Buffer buffer, boolean async); In JavaDoc s/resource scope/memory session ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From psandoz at openjdk.java.net Fri Feb 18 19:58:15 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 18 Feb 2022 19:58:15 GMT Subject: [foreign-preview] RFR: 8282026: Remove support for unbound sequence layouts In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 15:23:43 GMT, Maurizio Cimadamore wrote: > When doing a pass over the memory layout API, I couldn't help noting that the API implementation and specification are made more complex by the fact that we have to specify what happens when a sequence layout *without a size* is found. Support for unbounded sequence layout was added many moons ago, with the understanding that it would have made life for jextract easier. > > This is not the case; all cases where jextract is using an unbounded sequence layout today can be replaced with using a simple zero-length sequence (which is allowed by the API, as are empty structs/unions). > > I also found that the only real use case for using unbounded sequence layout came from a quirk in the API to obtain var handles from layout. That is, if we want to obtain an indexed var handle into a JAVA_INT, we have to do the following: > > > VarHandle intHandle = MemoryLayout.newSequenceLayout(JAVA_INT) > .varHandle(PathElement.sequenceLayout()); > > > In hindsight, this is just boilerplate: in this case the user only cares about the element layout (`JAVA_INT`), but the API wants the user to wrap that element layout in a new sequence layout, only to then provide a path inside the sequence layout (which will add a free dimension to the resulting var handle). > > It is not hard to see that all the above can be simplified, by adding an extra API method on memory layouts: > > > VarHandle intHandle = JAVA_INT.arrayElementVarHandle(JAVA_INT); > > > This more explicit, succint, and provdies less opportunities for bugs to hide. > > Therefore, this patch removes support for unbounded sequence element; the net effect is that now _all_ layouts have a size - which significantly simplifies the use sites where layout sizes are computed (no need to use optional there). All without losing much in terms of expressiveness: zero-length sequence layout can be used in basically the same way in which unbounded sequence layouts were used before. I don't see any tests for `arrayElementSliceHandle`. src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 496: > 494: * {@snippet lang=java : > 495: * MemoryLayout.sequenceLayout(Long.MAX_VALUE, this) > 496: * .varHandle(PathElement.sequenceElement()); Suggestion: * MemoryLayout.sequenceLayout(Long.MAX_VALUE, this) * .sliceHandle(PathElement.sequenceElement()); ? src/java.base/share/classes/java/lang/foreign/SequenceLayout.java line 34: > 32: import java.util.OptionalLong; > 33: import jdk.internal.javac.PreviewFeature; > 34: Unused import `java.util.OptionalLong;`, suggest checking other files too. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/642 From psandoz at openjdk.java.net Fri Feb 18 20:05:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 18 Feb 2022 20:05:05 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 16:11:52 GMT, Maurizio Cimadamore wrote: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Java parts look good. ------------- Marked as reviewed by psandoz (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/643 From psandoz at openjdk.java.net Fri Feb 18 20:40:17 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 18 Feb 2022 20:40:17 GMT Subject: [foreign-preview] RFR: 8282069: Set correct alignment constraints on ValueLayout constants In-Reply-To: References: Message-ID: <4nfCDQ7KM7GVHTzw30D-auO7Om6N6qXyE7RizifP5uk=.c9c67dce-b2fb-40ac-81c4-a104bcbaacbb@github.com> On Fri, 18 Feb 2022 18:14:43 GMT, Maurizio Cimadamore wrote: > Now that we have a good understanding of how to enforce alignment checks for both off-heap _and_ heap segments, we are in a position to set the correct alignment constraints on the various `ValueLayout.JAVA_XYZ` constants. > > The source changes are quite trivial; fixing the tests less so. The main issue is that some of the test are quite liberal in moving things in and out of `byte[]`. E.g. they create a `byte[]` and want to store a `JAVA_LONG` in it. If `JAVA_LONG` has the correct alignment (8 bytes) there's no way we can guarantee correctness and the code now fails (correctly). > > Also, we now proprerly check alignment on bulk copy operations too - so bulk copy tests, which were ok before, now fail when correct alignment constraints are applied. > > I've fixed some of the tests in simple ways - e.g. by using a `long[]` instead of a `byte[]`. But in some of the most complex tests I had to define unaligned layouts, as some of the tests are peeking and poking at memory in ways that is not compatible with aligned access (the byte buffer test is a good one, as byte buffer access is not aligned). > > Also, I had to tweak some code in the `BindingSpecializer` class - some of the bindings can sometimes read multiple fields in a single shot - so e.g. if you have a struct like `[f32 f32]` a single `long` read is performed to read both fields. This means that we do a `JAVA_LONG` read, but with an underlying memory alignment of 4, which is not going to work in some cases (especially in upcalls, where we use an arena allocator to allocate temp buffers; the arena allocator can "pack" structs more than just using `malloc`). For this reason I had to change that code to use unaligned layouts as well. Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/647 From svkamath at openjdk.java.net Fri Feb 18 20:41:05 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 18 Feb 2022 20:41:05 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v5] In-Reply-To: References: Message-ID: > 8281562:[vectorapi] Add support for popcount operation Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: deleted PopcountUnitTest.java and made changes as per review comments ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/173/files - new: https://git.openjdk.java.net/panama-vector/pull/173/files/b97d4941..3fed293b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=04 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=03-04 Stats: 100 lines in 8 files changed: 14 ins; 86 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/173/head:pull/173 PR: https://git.openjdk.java.net/panama-vector/pull/173 From mcimadamore at openjdk.java.net Fri Feb 18 21:31:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 21:31:02 GMT Subject: [foreign-preview] Integrated: 8282070: Drop workaround from memory segment implementation In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 19:07:12 GMT, Maurizio Cimadamore wrote: > Following some preliminary experiments (see [1]) it is now finally time to drop the various workarounds we have in the memory segment implementation. This patch removes two workarounds: > > * special treatment for "small" segments (e.g. segments whose size fits in an int) - see `MemorySegment::isSmall`; these segments were special cased so that bound checks would only involve `int` comparisons. This has now been fixed in JDK-8276116, and special treatment is no longer required. > > * special shortcuts to avoid extra alignment checks. Since when generating var handles from a layout we check most of the alignment constraints (except those involving the base address), in the past we have added a fastpath for these var handles, as C2 had trouble hoisting alignment checks outside of the loops. This has now been fixed in JDK-8277850 and is no longer required. > > I have run benchmarks before and after and got identical results. Some benchmarkks in `ParallelSum` got a boost, but those always have noise, due to multi-threading. This pull request has now been integrated. Changeset: 78f02203 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/78f02203767cf4bac49eeea44be2844680dc728b Stats: 252 lines in 14 files changed: 26 ins; 114 del; 112 mod 8282070: Drop workaround from memory segment implementation Reviewed-by: jvernee, psandoz ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/644 From mcimadamore at openjdk.java.net Fri Feb 18 21:33:58 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 21:33:58 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v3] In-Reply-To: References: Message-ID: <89M-7ee-1nSLT5iOJxsGUzv1njJWk0BfBjSkdzsGgYI=.79a3fff7-7a42-43d2-9e12-13c0cf437329@github.com> > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/java/lang/ClassLoader.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/641/files - new: https://git.openjdk.java.net/panama-foreign/pull/641/files/d9f36bec..d3a6c44f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From svkamath at openjdk.java.net Fri Feb 18 21:52:50 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 18 Feb 2022 21:52:50 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v6] In-Reply-To: References: Message-ID: > 8281562:[vectorapi] Add support for popcount operation Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Removed [!double] from template file ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/173/files - new: https://git.openjdk.java.net/panama-vector/pull/173/files/3fed293b..027dba54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=05 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=173&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/173/head:pull/173 PR: https://git.openjdk.java.net/panama-vector/pull/173 From mcimadamore at openjdk.java.net Fri Feb 18 21:55:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 21:55:46 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v4] In-Reply-To: References: Message-ID: <0hzKR-0dOhsam9ycHKLWuzaCmRFUu7kI-XCzqd6Yt8M=.a06b164b-38b3-494d-b841-8cbbee72f912@github.com> > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments * replace spurious usages of `scope` in direct buffer template ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/641/files - new: https://git.openjdk.java.net/panama-foreign/pull/641/files/d3a6c44f..2ee6f16b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=02-03 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From maurizio.cimadamore at oracle.com Fri Feb 18 22:16:07 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 22:16:07 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: <1785426525.1353083.1645221850331@email.ionos.de> References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> <8fbe8276-29d2-15a7-c7f5-70184b9de48f@oracle.com> <1785426525.1353083.1645221850331@email.ionos.de> Message-ID: <94c4cc44-d042-4ade-c675-9a800caadf4a@oracle.com> Hi Clemens, no worries - I will let you know when we have an EA with the fix available (we'll probably wait to accumulate some other fixes/features as well). Thanks Maurizio On 18/02/2022 22:04, Clemens Lanthaler wrote: > Hi, > Thanks allot for the info. I have seen that the fix will be part of > JDK19 and frankly speeking I have never build a jdk by myself. I would > appreciate if there is a chance to get a binary of this pre build > including panama. > > Thank you in advance. > > best regards, > Clemens > >> Maurizio Cimadamore hat am >> 18.02.2022 15:30 geschrieben: >> >> >> Hi, >> quick update on this. The problem with library loading in JDK being too >> strict for Panama has been fixed upstream (thanks Mandy!): >> >> https://git.openjdk.java.net/jdk/pull/7435 >> >> >> We've just merged those changes into the Panama repo - which means that, >> if you build the latest version of the repo, you should be able to >> verify that the workarounds are no longer required. >> >> Please let us know how that goes. >> >> Cheers >> Maurizio >> >> On 10/02/2022 10:05, Maurizio Cimadamore wrote: >>> I have managed to create a simple reproducer on Windows: >>> import jdk.incubator.foreign.CLinker; >>> public class TestLookup { >>> ??? public static void main(String[] args) { >>> System.load("C:\\Windows\\System32\\ucrtbase.dll"); >>> ??????? CLinker.systemCLinker().lookup("foo"); >>> ??? } >>> } >>> The call to CLinker::lookup fails with UnsatisfiedLinkError as >>> ucrtbase is already loaded by the application class loader. >>> This seems to be a bug in the library loading mechanism - we do have a >>> "raw" library loading mechanism that is not subject to JNI >>> restrictions: >>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L99 >>> >>> >> > >>> This library loader ends up calling this method which contains a class >>> loader check: >>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L203 >>> >>> >> > >>> I believe this loader check should be guarded by a "isJNI" flag, as we >>> did for other checks - e.g. whether JNI_OnLoad should be called. >>> Cheers >>> Maurizio >>> On 07/02/2022 12:19, Maurizio Cimadamore wrote: >>>> No problem. >> >> I've filed this: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8281335 >> >> >> >> Cheers >> >> Maurizio >> >> >> >> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >> >>> Hi Maurizio, >> >>> >> >>> thanks allot for your help and for the investigation. >> >>> >> >>> best regards, >> >>> Clemens >> >>> >> >>> >> >>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >> >>>> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Hi Clemens (it seems like your message got dropped by the mailing >> >>>> list, not sure why). >> >>>> >> >>>> Your message seems to point at some bad interaction between >> >>>> jpackage and Panama both trying to load ucrtbase.dll (and only one >> >>>> can win). Apparently, the Panama code isn't executed early enough >> >>>> in the jpackage case. >> >>>> >> >>>> We'll need to investigate more. >> >>>> >> >>>> Maurizio >> >>>> >> >>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >> >>>>> Hello everybody, >> >>>>> >> >>>>> I am the developer of project librawfx >> >>>>> (github.com/lanthale/librawfx) and the app Photoslide >> >>>>> (github.com/lanthale/photoslide). >> >>>>> >> >>>>> At the begining of Photoslide the whole app was modularized and >> >>>>> therefore all was working including librawfx which is using >> >>>>> project Panama. After a while I had to change to a mixed >> >>>>> (modulepath for jdk+javafx libs and classpath for the rest) >> >>>>> environment and deployed my app PhotoSlide again. Under Linux and >> >>>>> OSX all is working as expected. The problem exists only under >> >>>>> Windows. Furthermore it exists only if I am creating a >> >>>>> Jlink/Jpackage distribution. Running the app from maven was >> >>>>> working as expected. Only the JPackage launcher have the issue and >> >>>>> I have no clue what the root cause is. >> >>>>> >> >>>>> The exception I am always seeing is: >> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >> >>>>> SCHWERWIEGEND: null >> >>>>> java.lang.UnsatisfiedLinkError: Native Library >> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >> >>>>> classloader >> >>>>> (Full stacktrace below) >> >>>>> >> >>>>> How can you reproduce the issue: >> >>>>> >> >>>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >> >> >> >>>>> ?2. Start the app with "mvn javafx:run at default-cli" >> >>>>> ?3. Click on the open icon in the toolbar and select file >> >>>>> >> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >> >> >>>>> >> >>>>> ?4. The app is showing the image below the textarea >> >>>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >> >>>>> ??? install" >> >>>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >> >>>>> ?7. Open the same file again -> No image is shown below the text >> >>>>> ??? area and the exception is thrown in the background >> >>>>> >> >>>>> >> >>>>> I have tried many things but it is only happening if I have >> >>>>> OpenJFX+JDK Modules on the module path and the rest of the jar >> >>>>> files on the classpath. All libs which are not having any Panama >> >>>>> code inside of the app are working perfectly and it is only >> >>>>> happening on Windows. >> >>>>> >> >>>>> Thank you in advance for your help! >> >>>>> >> >>>>> best regards, >> >>>>> Clemens >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> *Full stacktrace from Photoslide:* >> >>>>> >> >>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >> >>>>> createSearchIndex >> >>>>> INFORMATION: Start time create searchDB: >> 2022-02-03T19:44:41.693455 >> >>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >> >>>>> lambda$checkForSoftwareUpdates$2 >> >>>>> INFORMATION: No new version found! >> >>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >> >>>>> lambda$createSearchIndex$0 >> >>>>> INFORMATION: End time create searchDB: >> 2022-02-03T19:44:43.186194400 >> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >> >>>>> SCHWERWIEGEND: null >> >>>>> java.lang.UnsatisfiedLinkError: Native Library >> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >> >>>>> classloader >> >>>>> at >> >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >> >>>>> Source) >> >>>>> at >> >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >> >>>>> Source) >> >>>>> at >> >>>>> >> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >> >> >>>>> Source) >> >>>>> at >> >>>>> >> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >> >> >>>>> Source) >> >>>>> at >> >>>>> >> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >> >> >>>>> Source) >> >>>>> at >> >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >> >>>>> Source) >> >>>>> at >> >>>>> >> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >> >>>>> Source) >> >>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >> >>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >> >>>>> at >> >>>>> >> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >> >>>>> >> >>>>> at >> org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >> >>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >> >>>>> at >> >>>>> >> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >> >>>>> Source) >> >>>>> at >> >>>>> >> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >> >>>>> Source) >> >>>>> at >> >>>>> >> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >> >> >>>>> Source) >> >>>>> at >> >>>>> >> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >> >> >>>>> Source) >> >>>>> at >> >>>>> >> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >> >> >>>>> Source) >> >>>>> at >> >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >> >>>>> Source) >> >>>>> at >> >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >> >>>>> Source) >> >>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown Source) >> >>>>> at >> >>>>> >> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >> >>>>> >> >>>>> at >> >>>>> >> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >> >>>>> >> >>>>> at >> >>>>> >> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >> >>>>> Source) >> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >> >>>>> at >> >>>>> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >> >>>>> Source) >> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >> >>>>> at >> >>>>> >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >> >>>>> Source) >> >>>>> at >> >>>>> >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >> >>>>> Source) >> >>>>> at java.base/java.lang.Thread.run(Unknown Source) From mcimadamore at openjdk.java.net Fri Feb 18 22:27:33 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 22:27:33 GMT Subject: [foreign-preview] RFR: 8282026: Remove support for unbound sequence layouts [v2] In-Reply-To: References: Message-ID: > When doing a pass over the memory layout API, I couldn't help noting that the API implementation and specification are made more complex by the fact that we have to specify what happens when a sequence layout *without a size* is found. Support for unbounded sequence layout was added many moons ago, with the understanding that it would have made life for jextract easier. > > This is not the case; all cases where jextract is using an unbounded sequence layout today can be replaced with using a simple zero-length sequence (which is allowed by the API, as are empty structs/unions). > > I also found that the only real use case for using unbounded sequence layout came from a quirk in the API to obtain var handles from layout. That is, if we want to obtain an indexed var handle into a JAVA_INT, we have to do the following: > > > VarHandle intHandle = MemoryLayout.newSequenceLayout(JAVA_INT) > .varHandle(PathElement.sequenceLayout()); > > > In hindsight, this is just boilerplate: in this case the user only cares about the element layout (`JAVA_INT`), but the API wants the user to wrap that element layout in a new sequence layout, only to then provide a path inside the sequence layout (which will add a free dimension to the resulting var handle). > > It is not hard to see that all the above can be simplified, by adding an extra API method on memory layouts: > > > VarHandle intHandle = JAVA_INT.arrayElementVarHandle(JAVA_INT); > > > This more explicit, succint, and provdies less opportunities for bugs to hide. > > Therefore, this patch removes support for unbounded sequence element; the net effect is that now _all_ layouts have a size - which significantly simplifies the use sites where layout sizes are computed (no need to use optional there). All without losing much in terms of expressiveness: zero-length sequence layout can be used in basically the same way in which unbounded sequence layouts were used before. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Remove unused imports Drop arrayElementSliceHandle ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/642/files - new: https://git.openjdk.java.net/panama-foreign/pull/642/files/a15648f7..a954e84e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=642&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=642&range=00-01 Stats: 28 lines in 7 files changed: 22 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/642.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/642/head:pull/642 PR: https://git.openjdk.java.net/panama-foreign/pull/642 From mcimadamore at openjdk.java.net Fri Feb 18 22:27:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 18 Feb 2022 22:27:34 GMT Subject: [foreign-preview] RFR: 8282026: Remove support for unbound sequence layouts In-Reply-To: References: Message-ID: <7Cj2gYXz6TnFd4hUOgdPjQbDHi7qayG42at8_N8C400=.587c4ab4-1044-47d0-adfb-76bedace4ad8@github.com> On Thu, 17 Feb 2022 15:23:43 GMT, Maurizio Cimadamore wrote: > When doing a pass over the memory layout API, I couldn't help noting that the API implementation and specification are made more complex by the fact that we have to specify what happens when a sequence layout *without a size* is found. Support for unbounded sequence layout was added many moons ago, with the understanding that it would have made life for jextract easier. > > This is not the case; all cases where jextract is using an unbounded sequence layout today can be replaced with using a simple zero-length sequence (which is allowed by the API, as are empty structs/unions). > > I also found that the only real use case for using unbounded sequence layout came from a quirk in the API to obtain var handles from layout. That is, if we want to obtain an indexed var handle into a JAVA_INT, we have to do the following: > > > VarHandle intHandle = MemoryLayout.newSequenceLayout(JAVA_INT) > .varHandle(PathElement.sequenceLayout()); > > > In hindsight, this is just boilerplate: in this case the user only cares about the element layout (`JAVA_INT`), but the API wants the user to wrap that element layout in a new sequence layout, only to then provide a path inside the sequence layout (which will add a free dimension to the resulting var handle). > > It is not hard to see that all the above can be simplified, by adding an extra API method on memory layouts: > > > VarHandle intHandle = JAVA_INT.arrayElementVarHandle(JAVA_INT); > > > This more explicit, succint, and provdies less opportunities for bugs to hide. > > Therefore, this patch removes support for unbounded sequence element; the net effect is that now _all_ layouts have a size - which significantly simplifies the use sites where layout sizes are computed (no need to use optional there). All without losing much in terms of expressiveness: zero-length sequence layout can be used in basically the same way in which unbounded sequence layouts were used before. After some more thinking I decided to drop `arrayElementSliceHandle` for the time being. The "sliceHandle" method is already quite nichey, and you can always get there by wrapping into a sequence layout and then unwrap with a sequence element path, to get a strided MH. In other words, I think the API should make it easy to express array-like var handles, which are the most common form - other things should be possible as well (and they are) but not sure they are worth the API estate. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/642 From psandoz at openjdk.java.net Sat Feb 19 00:52:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Sat, 19 Feb 2022 00:52:05 GMT Subject: [foreign-preview] RFR: 8282026: Remove support for unbound sequence layouts In-Reply-To: <7Cj2gYXz6TnFd4hUOgdPjQbDHi7qayG42at8_N8C400=.587c4ab4-1044-47d0-adfb-76bedace4ad8@github.com> References: <7Cj2gYXz6TnFd4hUOgdPjQbDHi7qayG42at8_N8C400=.587c4ab4-1044-47d0-adfb-76bedace4ad8@github.com> Message-ID: On Fri, 18 Feb 2022 22:23:23 GMT, Maurizio Cimadamore wrote: > After some more thinking I decided to drop `arrayElementSliceHandle` for the time being. I agree. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/642 From psandoz at openjdk.java.net Sat Feb 19 00:55:14 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Sat, 19 Feb 2022 00:55:14 GMT Subject: [vectorIntrinsics] RFR: 8281562:[vectorapi] Add support for popcount operation [v6] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 21:52:50 GMT, Smita Kamath wrote: >> 8281562:[vectorapi] Add support for popcount operation > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Removed [!double] from template file Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From psandoz at openjdk.java.net Sat Feb 19 00:56:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Sat, 19 Feb 2022 00:56:05 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v4] In-Reply-To: <0hzKR-0dOhsam9ycHKLWuzaCmRFUu7kI-XCzqd6Yt8M=.a06b164b-38b3-494d-b841-8cbbee72f912@github.com> References: <0hzKR-0dOhsam9ycHKLWuzaCmRFUu7kI-XCzqd6Yt8M=.a06b164b-38b3-494d-b841-8cbbee72f912@github.com> Message-ID: On Fri, 18 Feb 2022 21:55:46 GMT, Maurizio Cimadamore wrote: >> This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html >> [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments > * replace spurious usages of `scope` in direct buffer template Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From svkamath at openjdk.java.net Sat Feb 19 01:03:14 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Sat, 19 Feb 2022 01:03:14 GMT Subject: [vectorIntrinsics] Integrated: 8281562:[vectorapi] Add support for popcount operation In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 22:41:36 GMT, Smita Kamath wrote: > 8281562:[vectorapi] Add support for popcount operation This pull request has now been integrated. Changeset: 0ad2b19f Author: Smita Kamath Committer: Sandhya Viswanathan URL: https://git.openjdk.java.net/panama-vector/commit/0ad2b19f75e6bbaac5f38f60290dfc92d2118bc0 Stats: 2228 lines in 78 files changed: 2166 ins; 0 del; 62 mod 8281562:[vectorapi] Add support for popcount operation Reviewed-by: sviswanathan, psandoz ------------- PR: https://git.openjdk.java.net/panama-vector/pull/173 From anhmdq at gmail.com Sun Feb 20 08:43:58 2022 From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=) Date: Sun, 20 Feb 2022 16:43:58 +0800 Subject: UTF-8 validation using Vector API Message-ID: Hi, I have spent this weekend trying to make a UTF-8 validator using the Vector API and the look-up algorithm proposed by Keiser and Lemire [1]. The implementation is straightforward and the result looks good with the throughput validating twitter.json reaching 9GB/s. For reference, the throughput of my machine running simdjson [2] is around 20.5GB/s. Using the Vector API and tunning the performance, there are some noticeable points I can come up with: 1, The most significant anomaly is that the compiler seems to be not so good at register management. Even after many attempts to reduce the number of vectors living across iterations, there are still a lot of vectors being spilled on the stack, this leads to a lot of load and store in a latency-sensitive hot loop. 2, A rearrange operation is often used in look-up tables. However, the current situation requires excessive range checks on every invocation. Remove these range checks (set jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0) increases the throughput by roughly 15%, resulting in more than 10GB/s. Furthermore, currently, the wrapping is conducted upon the creations of the vector shuffles. As a result, I propose adding a method rearrangeWithWrap that takes an additional argument representing the wrapping modulus. If the modulus is constant, it opens the ability to remove the costly range check as well as more efficient rearrange implementations as rearrangement requires O(n^2) connections and a wide rearrangement may be much more costly than that on narrower vectors. For experiments, I replaced the rearrangement with a cheaper operation in the lookup phase (the add operation). This combined with the range check removal resulted in a nearly 40% increase in throughput which approached 13GB/s. 3, Slice operation should be improved. Given it takes several API points in the Vector class, I believe we should implement it using a more efficient manner than a general rearrange one. 4, Vectors loaded from constant vector objects are currently not hoisted outside the loop, while easy to make ones (all zeros and all ones) are fine creating on the fly. The source code of my implementation can be found here [3], the files I used for testing and benchmarking are taken from here [4]. Thanks a lot for your reading, Quan Anh [1]: [2010.03090] Validating UTF-8 In Less Than One Instruction Per Byte (arxiv.org) [2]: simdjson/simdjson: Parsing gigabytes of JSON per second (github.com) [3]: merykitty/utf8-validator: A high performance UTF-8 validator written using Java Vector API (github.com) [4]: AugustNagro/utf8.java: Vectorized UTF-8 Validation for Java (github.com) From duncan.gittins at gmail.com Sun Feb 20 21:04:23 2022 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Sun, 20 Feb 2022 21:04:23 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: <94c4cc44-d042-4ade-c675-9a800caadf4a@oracle.com> References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> <8fbe8276-29d2-15a7-c7f5-70184b9de48f@oracle.com> <1785426525.1353083.1645221850331@email.ionos.de> <94c4cc44-d042-4ade-c675-9a800caadf4a@oracle.com> Message-ID: <20049201-d204-b977-ef50-55be0b8d8aea@gmail.com> Maurizio I setup my sample javafx/jpackage app to use your minimal test case as a JavaFX button action handler: System.load("C:\\Windows\\System32\\ucrtbase.dll"); ??? Optional sym = CLinker.systemCLinker().lookup("foo"); As noted, the above fails in current EA release: java.lang.UnsatisfiedLinkError: Native Library C:\Windows\System32\ucrtbase.dll already loaded in another classload, and it works fine after building / running from current Panama repo pull. Kind regards Duncan On 18/02/2022 22:16, Maurizio Cimadamore wrote: > Hi Clemens, > no worries - I will let you know when we have an EA with the fix > available (we'll probably wait to accumulate some other fixes/features > as well). > > Thanks > Maurizio > > On 18/02/2022 22:04, Clemens Lanthaler wrote: >> Hi, >> Thanks allot for the info. I have seen that the fix will be part of >> JDK19 and frankly speeking I have never build a jdk by myself. I >> would appreciate if there is a chance to get a binary of this pre >> build including panama. >> >> Thank you in advance. >> >> best regards, >> Clemens >> >>> Maurizio Cimadamore hat am >>> 18.02.2022 15:30 geschrieben: >>> >>> >>> Hi, >>> quick update on this. The problem with library loading in JDK being too >>> strict for Panama has been fixed upstream (thanks Mandy!): >>> >>> https://git.openjdk.java.net/jdk/pull/7435 >>> >>> >>> We've just merged those changes into the Panama repo - which means >>> that, >>> if you build the latest version of the repo, you should be able to >>> verify that the workarounds are no longer required. >>> >>> Please let us know how that goes. >>> >>> Cheers >>> Maurizio >>> >>> On 10/02/2022 10:05, Maurizio Cimadamore wrote: >>>> I have managed to create a simple reproducer on Windows: >>>> import jdk.incubator.foreign.CLinker; >>>> public class TestLookup { >>>> ??? public static void main(String[] args) { >>>> System.load("C:\\Windows\\System32\\ucrtbase.dll"); >>>> ??????? CLinker.systemCLinker().lookup("foo"); >>>> ??? } >>>> } >>>> The call to CLinker::lookup fails with UnsatisfiedLinkError as >>>> ucrtbase is already loaded by the application class loader. >>>> This seems to be a bug in the library loading mechanism - we do have a >>>> "raw" library loading mechanism that is not subject to JNI >>>> restrictions: >>>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L99 >>>> >>>> >>> > >>>> This library loader ends up calling this method which contains a class >>>> loader check: >>>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L203 >>>> >>>> >>> > >>>> I believe this loader check should be guarded by a "isJNI" flag, as we >>>> did for other checks - e.g. whether JNI_OnLoad should be called. >>>> Cheers >>>> Maurizio >>>> On 07/02/2022 12:19, Maurizio Cimadamore wrote: >>>>> No problem. >>> >> I've filed this: >>> >> >>> >> https://bugs.openjdk.java.net/browse/JDK-8281335 >>> >> >>> >> Cheers >>> >> Maurizio >>> >> >>> >> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >>> >>> Hi Maurizio, >>> >>> >>> >>> thanks allot for your help and for the investigation. >>> >>> >>> >>> best regards, >>> >>> Clemens >>> >>> >>> >>> >>> >>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>> >>>> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Hi Clemens (it seems like your message got dropped by the mailing >>> >>>> list, not sure why). >>> >>>> >>> >>>> Your message seems to point at some bad interaction between >>> >>>> jpackage and Panama both trying to load ucrtbase.dll (and only one >>> >>>> can win). Apparently, the Panama code isn't executed early enough >>> >>>> in the jpackage case. >>> >>>> >>> >>>> We'll need to investigate more. >>> >>>> >>> >>>> Maurizio >>> >>>> >>> >>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>> >>>>> Hello everybody, >>> >>>>> >>> >>>>> I am the developer of project librawfx >>> >>>>> (github.com/lanthale/librawfx) and the app Photoslide >>> >>>>> (github.com/lanthale/photoslide). >>> >>>>> >>> >>>>> At the begining of Photoslide the whole app was modularized and >>> >>>>> therefore all was working including librawfx which is using >>> >>>>> project Panama. After a while I had to change to a mixed >>> >>>>> (modulepath for jdk+javafx libs and classpath for the rest) >>> >>>>> environment and deployed my app PhotoSlide again. Under Linux and >>> >>>>> OSX all is working as expected. The problem exists only under >>> >>>>> Windows. Furthermore it exists only if I am creating a >>> >>>>> Jlink/Jpackage distribution. Running the app from maven was >>> >>>>> working as expected. Only the JPackage launcher have the issue >>> and >>> >>>>> I have no clue what the root cause is. >>> >>>>> >>> >>>>> The exception I am always seeing is: >>> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>> >>>>> SCHWERWIEGEND: null >>> >>>>> java.lang.UnsatisfiedLinkError: Native Library >>> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>> >>>>> classloader >>> >>>>> (Full stacktrace below) >>> >>>>> >>> >>>>> How can you reproduce the issue: >>> >>>>> >>> >>>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>> >>> >>> >>>>> ?2. Start the app with "mvn javafx:run at default-cli" >>> >>>>> ?3. Click on the open icon in the toolbar and select file >>> >>>>> >>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>> >>> >>>>> >>> >>>>> ?4. The app is showing the image below the textarea >>> >>>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage clean >>> >>>>> ??? install" >>> >>>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>> >>>>> ?7. Open the same file again -> No image is shown below the text >>> >>>>> ??? area and the exception is thrown in the background >>> >>>>> >>> >>>>> >>> >>>>> I have tried many things but it is only happening if I have >>> >>>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>> >>>>> files on the classpath. All libs which are not having any Panama >>> >>>>> code inside of the app are working perfectly and it is only >>> >>>>> happening on Windows. >>> >>>>> >>> >>>>> Thank you in advance for your help! >>> >>>>> >>> >>>>> best regards, >>> >>>>> Clemens >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> *Full stacktrace from Photoslide:* >>> >>>>> >>> >>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>> >>>>> createSearchIndex >>> >>>>> INFORMATION: Start time create searchDB: >>> 2022-02-03T19:44:41.693455 >>> >>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>> >>>>> lambda$checkForSoftwareUpdates$2 >>> >>>>> INFORMATION: No new version found! >>> >>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>> >>>>> lambda$createSearchIndex$0 >>> >>>>> INFORMATION: End time create searchDB: >>> 2022-02-03T19:44:43.186194400 >>> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>> >>>>> SCHWERWIEGEND: null >>> >>>>> java.lang.UnsatisfiedLinkError: Native Library >>> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>> >>>>> classloader >>> >>>>> at >>> >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>> >>>>> Source) >>> >>>>> at >>> >>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>> >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>> >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>> >>> >>>>> Source) >>> >>>>> at >>> >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>> >>> >>>>> Source) >>> >>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>> >>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>> >>>>> at >>> >>>>> >>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>> >>>>> >>> >>>>> at >>> org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>> >>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>> >>>>> at >>> >>>>> >>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>> >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>> >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>> >>> >>>>> Source) >>> >>>>> at >>> >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>> >>>>> Source) >>> >>>>> at >>> >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>> >>>>> Source) >>> >>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown >>> Source) >>> >>>>> at >>> >>>>> >>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>> >>> >>>>> >>> >>>>> at >>> >>>>> >>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>> >>> >>>>> >>> >>>>> at >>> >>>>> >>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>> >>>>> Source) >>> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>> >>>>> at >>> >>>>> >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>> >>>>> Source) >>> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>> >>>>> at >>> >>>>> >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>> >>>>> Source) >>> >>>>> at >>> >>>>> >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>> >>>>> Source) >>> >>>>> at java.base/java.lang.Thread.run(Unknown Source) From john.r.rose at oracle.com Mon Feb 21 02:27:10 2022 From: john.r.rose at oracle.com (John Rose) Date: Sun, 20 Feb 2022 18:27:10 -0800 Subject: UTF-8 validation using Vector API In-Reply-To: References: Message-ID: <01ABCEF1-EE22-46ED-95DB-CA8CCF970AAF@oracle.com> This is a very helpful case study. In a recent presentation I put forward UTF8 parsing as an important challenge problem, exercising segmented expansion. This current experiment could be an exploratory step in that direction. http://cr.openjdk.java.net/~jrose/pres/202202-VectorTopics.pdf (You message is timely; I have placed a link to it on my page 23, and adjusted a few points there to reflect our exchange here.) It is sad that you didn?t/couldn?t use the `slice` method directly, but used the SLICE_4 constant permutation. That?s worth fixing. If there is a ?boundary condition? that `slice` doesn?t handle right we should address that too. By boundary condition I mean a special case in a nearest neighbor computation at an end of the vector where there?s no neighbor, but just the ?cliff? at the end. In general, I think the Vector API might possibly be friendlier to boundary conditions, but I think we have to discover this by experience. One area that will push this experience further is adopting multi-vectors, which have more interior, but require clear and explicit processing at their ends, in many use cases. (See p. 9ff.) Ideally, the optimizer should be able to ?see through? a computed permutation (including the fromOp index expression) and use either a constant-folded permutation vector, or an ad hoc cross lane motion instruction (there are very many in both AVX and SVE). That would cover slice. Of course, we could also try to make slice have it?s own little intrinsic ?silo? but that has less of a payoff. You observe that the range checks in the LUT lookups add 15% and propose just removing them or incorporating wrap logic. There is another more ?Java-like? way out of the problem, which is to have the optimizer reason about the range-values of the index lanes and omit the range check if the index lanes are already provably in range. That is the case in your code, since before every `selectFrom` operation you first do a lanewise `AND` with a nibble mask (0x0F or 0x00 all lanes). The optimizer should be tracking something like `TypeInt` range information on these lanes, I think, or perhaps compute a bitwise support mask for every vector. Using a rearrange or select where the indexes are already in range should not be penalized with a dynamic check. Given logic like the above, a new `rearrangeWithWrap` function is not so much needed, since a user can code equivalent functionality with an explicit wrap operation, which is then treated like the `AND` above. In your code you have explicit copes from constant vectors to ?live? vector registers in the loop: > var hi2Lut = HI2_LUT.lanewise(VectorOperators.XOR, 0); It is a bug in the optimizer if it requires these in order to get good performance. Your comment about rematerializing simple ones-and-zeroes on the fly in the loop is a good one. The optimizer can do that stuff with scalar constants but we are not (I think) there yet with vectors. The same point goes for constant lookup-table (LUT) bit patterns. It shouldn?t be necessary to ?nudge? the optimizer to pick them up properly. I have a request? It would be good if you were to write a version of your code which is as simple and clear as possible, as if the optimizer had no bugs but instead was smart about vectors (and their lanes) as it is about scalars. The reason this would be good is we would have something to debug the optimizer with, because we would want to identify the reasons you had to modify your code by hand to nudge the optimizer to do something it should not need nudging in order to do. Thank you again for this excellent study. ? John On 20 Feb 2022, at 0:43, Qu?n Anh Mai wrote: > Hi, > > I have spent this weekend trying to make a UTF-8 validator using the Vector > API and the look-up algorithm proposed by Keiser and Lemire [1]. The > implementation is straightforward and the result looks good with the > throughput validating twitter.json reaching 9GB/s. For reference, the > throughput of my machine running simdjson [2] is around 20.5GB/s. Using the > Vector API and tunning the performance, there are some noticeable points I > can come up with > ? From sundar at openjdk.java.net Mon Feb 21 09:34:59 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 21 Feb 2022 09:34:59 GMT Subject: [foreign-jextract] RFR: 8281764: jextract does not generate parameter names for function pointer typedefs [v2] In-Reply-To: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> References: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> Message-ID: > Propagating TypedefDecl's ParmDecl child cursors to Types. Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: cleanup based on code review comments ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/646/files - new: https://git.openjdk.java.net/panama-foreign/pull/646/files/ba18fbd8..0a8d2e20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=646&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=646&range=00-01 Stats: 86 lines in 4 files changed: 45 ins; 30 del; 11 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/646.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/646/head:pull/646 PR: https://git.openjdk.java.net/panama-foreign/pull/646 From maurizio.cimadamore at oracle.com Mon Feb 21 10:15:53 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 10:15:53 +0000 Subject: Issue in combination with JLink/JPackage In-Reply-To: <20049201-d204-b977-ef50-55be0b8d8aea@gmail.com> References: <084c5e5d-b78d-50aa-7b58-c3db9d95b56b@oracle.com> <8fbe8276-29d2-15a7-c7f5-70184b9de48f@oracle.com> <1785426525.1353083.1645221850331@email.ionos.de> <94c4cc44-d042-4ade-c675-9a800caadf4a@oracle.com> <20049201-d204-b977-ef50-55be0b8d8aea@gmail.com> Message-ID: On 20/02/2022 21:04, Duncan Gittins wrote: > Maurizio > > I setup my sample javafx/jpackage app to use your minimal test case as > a JavaFX button action handler: > > System.load("C:\\Windows\\System32\\ucrtbase.dll"); > ??? Optional sym = CLinker.systemCLinker().lookup("foo"); > > As noted, the above fails in current EA release: > java.lang.UnsatisfiedLinkError: Native Library > C:\Windows\System32\ucrtbase.dll already loaded in another classload, > and it works fine after building / running from current Panama repo pull. Thanks for verifying! Maurizio > > Kind regards > > Duncan > > On 18/02/2022 22:16, Maurizio Cimadamore wrote: >> Hi Clemens, >> no worries - I will let you know when we have an EA with the fix >> available (we'll probably wait to accumulate some other >> fixes/features as well). >> >> Thanks >> Maurizio >> >> On 18/02/2022 22:04, Clemens Lanthaler wrote: >>> Hi, >>> Thanks allot for the info. I have seen that the fix will be part of >>> JDK19 and frankly speeking I have never build a jdk by myself. I >>> would appreciate if there is a chance to get a binary of this pre >>> build including panama. >>> >>> Thank you in advance. >>> >>> best regards, >>> Clemens >>> >>>> Maurizio Cimadamore hat am >>>> 18.02.2022 15:30 geschrieben: >>>> >>>> >>>> Hi, >>>> quick update on this. The problem with library loading in JDK being >>>> too >>>> strict for Panama has been fixed upstream (thanks Mandy!): >>>> >>>> https://git.openjdk.java.net/jdk/pull/7435 >>>> >>>> >>>> We've just merged those changes into the Panama repo - which means >>>> that, >>>> if you build the latest version of the repo, you should be able to >>>> verify that the workarounds are no longer required. >>>> >>>> Please let us know how that goes. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> On 10/02/2022 10:05, Maurizio Cimadamore wrote: >>>>> I have managed to create a simple reproducer on Windows: >>>>> import jdk.incubator.foreign.CLinker; >>>>> public class TestLookup { >>>>> ??? public static void main(String[] args) { >>>>> System.load("C:\\Windows\\System32\\ucrtbase.dll"); >>>>> ??????? CLinker.systemCLinker().lookup("foo"); >>>>> ??? } >>>>> } >>>>> The call to CLinker::lookup fails with UnsatisfiedLinkError as >>>>> ucrtbase is already loaded by the application class loader. >>>>> This seems to be a bug in the library loading mechanism - we do >>>>> have a >>>>> "raw" library loading mechanism that is not subject to JNI >>>>> restrictions: >>>>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L99 >>>>> >>>>> >>>> > >>>>> This library loader ends up calling this method which contains a >>>>> class >>>>> loader check: >>>>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L203 >>>>> >>>>> >>>> > >>>>> I believe this loader check should be guarded by a "isJNI" flag, >>>>> as we >>>>> did for other checks - e.g. whether JNI_OnLoad should be called. >>>>> Cheers >>>>> Maurizio >>>>> On 07/02/2022 12:19, Maurizio Cimadamore wrote: >>>>>> No problem. >>>> >> I've filed this: >>>> >> >>>> >> https://bugs.openjdk.java.net/browse/JDK-8281335 >>>> >> >>>> >> Cheers >>>> >> Maurizio >>>> >> >>>> >> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote: >>>> >>> Hi Maurizio, >>>> >>> >>>> >>> thanks allot for your help and for the investigation. >>>> >>> >>>> >>> best regards, >>>> >>> Clemens >>>> >>> >>>> >>> >>>> >>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Clemens (it seems like your message got dropped by the mailing >>>> >>>> list, not sure why). >>>> >>>> >>>> >>>> Your message seems to point at some bad interaction between >>>> >>>> jpackage and Panama both trying to load ucrtbase.dll (and only >>>> one >>>> >>>> can win). Apparently, the Panama code isn't executed early enough >>>> >>>> in the jpackage case. >>>> >>>> >>>> >>>> We'll need to investigate more. >>>> >>>> >>>> >>>> Maurizio >>>> >>>> >>>> >>>> On 05/02/2022 15:31, Clemens Lanthaler wrote: >>>> >>>>> Hello everybody, >>>> >>>>> >>>> >>>>> I am the developer of project librawfx >>>> >>>>> (github.com/lanthale/librawfx) and the app Photoslide >>>> >>>>> (github.com/lanthale/photoslide). >>>> >>>>> >>>> >>>>> At the begining of Photoslide the whole app was modularized and >>>> >>>>> therefore all was working including librawfx which is using >>>> >>>>> project Panama. After a while I had to change to a mixed >>>> >>>>> (modulepath for jdk+javafx libs and classpath for the rest) >>>> >>>>> environment and deployed my app PhotoSlide again. Under Linux >>>> and >>>> >>>>> OSX all is working as expected. The problem exists only under >>>> >>>>> Windows. Furthermore it exists only if I am creating a >>>> >>>>> Jlink/Jpackage distribution. Running the app from maven was >>>> >>>>> working as expected. Only the JPackage launcher have the >>>> issue and >>>> >>>>> I have no clue what the root cause is. >>>> >>>>> >>>> >>>>> The exception I am always seeing is: >>>> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>> >>>>> SCHWERWIEGEND: null >>>> >>>>> java.lang.UnsatisfiedLinkError: Native Library >>>> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>> >>>>> classloader >>>> >>>>> (Full stacktrace below) >>>> >>>>> >>>> >>>>> How can you reproduce the issue: >>>> >>>>> >>>> >>>>> ?1. Git clone project https://github.com/lanthale/JeditFX.git >>>> >>>> >>>> >>>>> ?2. Start the app with "mvn javafx:run at default-cli" >>>> >>>>> ?3. Click on the open icon in the toolbar and select file >>>> >>>>> >>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" >>>> >>>> >>>>> >>>> >>>>> ?4. The app is showing the image below the textarea >>>> >>>>> ?5. Create the jlink/jpackage app-image with "mvn -Ppackage >>>> clean >>>> >>>>> ??? install" >>>> >>>>> ?6. Start the exe jeditfx.exe in directory ".\target\jeditfx" >>>> >>>>> ?7. Open the same file again -> No image is shown below the text >>>> >>>>> ??? area and the exception is thrown in the background >>>> >>>>> >>>> >>>>> >>>> >>>>> I have tried many things but it is only happening if I have >>>> >>>>> OpenJFX+JDK Modules on the module path and the rest of the jar >>>> >>>>> files on the classpath. All libs which are not having any Panama >>>> >>>>> code inside of the app are working perfectly and it is only >>>> >>>>> happening on Windows. >>>> >>>>> >>>> >>>>> Thank you in advance for your help! >>>> >>>>> >>>> >>>>> best regards, >>>> >>>>> Clemens >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> *Full stacktrace from Photoslide:* >>>> >>>>> >>>> >>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex >>>> >>>>> createSearchIndex >>>> >>>>> INFORMATION: Start time create searchDB: >>>> 2022-02-03T19:44:41.693455 >>>> >>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater >>>> >>>>> lambda$checkForSoftwareUpdates$2 >>>> >>>>> INFORMATION: No new version found! >>>> >>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex >>>> >>>>> lambda$createSearchIndex$0 >>>> >>>>> INFORMATION: End time create searchDB: >>>> 2022-02-03T19:44:43.186194400 >>>> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load >>>> >>>>> SCHWERWIEGEND: null >>>> >>>>> java.lang.UnsatisfiedLinkError: Native Library >>>> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another >>>> >>>>> classloader >>>> >>>>> at >>>> >>>>> >>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown >>>> >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown >>>> >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown >>>> >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown >>>> >>>> >>>>> Source) >>>> >>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33) >>>> >>>>> at org.libraw.win.libraw_h.(libraw_h.java:15) >>>> >>>>> at >>>> >>>>> >>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) >>>> >>>>> >>>> >>>>> at >>>> org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168) >>>> >>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84) >>>> >>>>> at >>>> >>>>> >>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown >>>> >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown >>>> >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown >>>> >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown >>>> >>>>> Source) >>>> >>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown >>>> Source) >>>> >>>>> at >>>> >>>>> >>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) >>>> >>>> >>>>> >>>> >>>>> at >>>> >>>>> >>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) >>>> >>>> >>>>> >>>> >>>>> at >>>> >>>>> >>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown >>>> >>>>> Source) >>>> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>> >>>>> at >>>> >>>>> >>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown >>>> >>>>> Source) >>>> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown Source) >>>> >>>>> at >>>> >>>>> >>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>> >>>>> Source) >>>> >>>>> at >>>> >>>>> >>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>> >>>>> Source) >>>> >>>>> at java.base/java.lang.Thread.run(Unknown Source) > > From mcimadamore at openjdk.java.net Mon Feb 21 10:26:15 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 10:26:15 GMT Subject: [foreign-jextract] RFR: 8281764: jextract does not generate parameter names for function pointer typedefs [v2] In-Reply-To: References: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> Message-ID: <7cTdC68kRRDTmW8bIk4o2fIqfpg9ybSY-IBfoowjUUk=.671b2a0f-de4d-47e8-939c-9e16b8981eae@github.com> On Mon, 21 Feb 2022 09:34:59 GMT, Athijegannathan Sundararajan wrote: >> Propagating TypedefDecl's ParmDecl child cursors to Types. > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > cleanup based on code review comments Marked as reviewed by mcimadamore (Committer). src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TreeMaker.java line 262: > 260: Type.Function funcType = null; > 261: boolean isFuncPtrType = false; > 262: if (canonicalType instanceof Type.Function) { I believe `OutputFactory::getAsFunctionPointer` as code that is similar to this (given a type, return it as a function type - following typedefs if necessary). Maybe we should move this into some util function and share? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/646 From sundar at openjdk.java.net Mon Feb 21 10:30:18 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 21 Feb 2022 10:30:18 GMT Subject: [foreign-jextract] RFR: 8281764: jextract does not generate parameter names for function pointer typedefs [v2] In-Reply-To: <7cTdC68kRRDTmW8bIk4o2fIqfpg9ybSY-IBfoowjUUk=.671b2a0f-de4d-47e8-939c-9e16b8981eae@github.com> References: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> <7cTdC68kRRDTmW8bIk4o2fIqfpg9ybSY-IBfoowjUUk=.671b2a0f-de4d-47e8-939c-9e16b8981eae@github.com> Message-ID: <5FP9wDoVCCOns7BA-hn9m6B661ciYxYYCVuJnISBe7Y=.6505e0b2-ef80-4e15-b55d-3599f9a01a54@github.com> On Mon, 21 Feb 2022 10:22:50 GMT, Maurizio Cimadamore wrote: >> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup based on code review comments > > src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TreeMaker.java line 262: > >> 260: Type.Function funcType = null; >> 261: boolean isFuncPtrType = false; >> 262: if (canonicalType instanceof Type.Function) { > > I believe `OutputFactory::getAsFunctionPointer` as code that is similar to this (given a type, return it as a function type - following typedefs if necessary). Maybe we should move this into some util function and share? That part of the code assumes all Types are properly resolved. In TreeMaker, we're in the middle TypeMaker's construction (resolution happens later). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/646 From mcimadamore at openjdk.java.net Mon Feb 21 11:40:38 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 11:40:38 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v5] In-Reply-To: References: Message-ID: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'foreign-preview' into session_preview - Address review comments * replace spurious usages of `scope` in direct buffer template - Update src/java.base/share/classes/java/lang/ClassLoader.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Co-authored-by: Paul Sandoz - Fix more spurious usages of ResourceScope - Fix whitespaces - Merge branch 'foreign-preview' into session_preview - Fix reference to ResourceScope in javadoc - Fix MemorySession javadoc - Initial push ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/641/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=04 Stats: 4701 lines in 139 files changed: 1501 ins; 1333 del; 1867 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Mon Feb 21 11:41:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 11:41:49 GMT Subject: [foreign-preview] RFR: 8282026: Remove support for unbound sequence layouts [v3] In-Reply-To: References: Message-ID: > When doing a pass over the memory layout API, I couldn't help noting that the API implementation and specification are made more complex by the fact that we have to specify what happens when a sequence layout *without a size* is found. Support for unbounded sequence layout was added many moons ago, with the understanding that it would have made life for jextract easier. > > This is not the case; all cases where jextract is using an unbounded sequence layout today can be replaced with using a simple zero-length sequence (which is allowed by the API, as are empty structs/unions). > > I also found that the only real use case for using unbounded sequence layout came from a quirk in the API to obtain var handles from layout. That is, if we want to obtain an indexed var handle into a JAVA_INT, we have to do the following: > > > VarHandle intHandle = MemoryLayout.newSequenceLayout(JAVA_INT) > .varHandle(PathElement.sequenceLayout()); > > > In hindsight, this is just boilerplate: in this case the user only cares about the element layout (`JAVA_INT`), but the API wants the user to wrap that element layout in a new sequence layout, only to then provide a path inside the sequence layout (which will add a free dimension to the resulting var handle). > > It is not hard to see that all the above can be simplified, by adding an extra API method on memory layouts: > > > VarHandle intHandle = JAVA_INT.arrayElementVarHandle(JAVA_INT); > > > This more explicit, succint, and provdies less opportunities for bugs to hide. > > Therefore, this patch removes support for unbounded sequence element; the net effect is that now _all_ layouts have a size - which significantly simplifies the use sites where layout sizes are computed (no need to use optional there). All without losing much in terms of expressiveness: zero-length sequence layout can be used in basically the same way in which unbounded sequence layouts were used before. Maurizio Cimadamore 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 two new commits since the last revision: - Drop arrayElementSliceHandle - Remove unused imports ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/642/files - new: https://git.openjdk.java.net/panama-foreign/pull/642/files/a954e84e..bd95f06d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=642&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=642&range=01-02 Stats: 47 lines in 2 files changed: 0 ins; 47 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/642.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/642/head:pull/642 PR: https://git.openjdk.java.net/panama-foreign/pull/642 From mcimadamore at openjdk.java.net Mon Feb 21 12:10:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 12:10:49 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v6] In-Reply-To: References: Message-ID: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix spurious reference to ResourceScopeImpl after merge ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/641/files - new: https://git.openjdk.java.net/panama-foreign/pull/641/files/3b33c667..bf979ed7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=05 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 13:36:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 13:36:12 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v6] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 12:10:49 GMT, Maurizio Cimadamore wrote: >> This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html >> [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix spurious reference to ResourceScopeImpl after merge src/java.base/share/classes/java/lang/foreign/MemorySession.java line 147: > 145: * a thread other than the thread {@linkplain #ownerThread() owning} this memory session. > 146: */ > 147: void addCloseAction(Runnable runnable); A note here, or on `openImplicit`, saying that a close action should not reference the session itself would be good I think. Suggestion inline (feel free to change). Suggestion: /** * Add a custom cleanup action which will be executed when the memory session is closed. * The order in which custom cleanup actions are invoked once the memory session is closed is unspecified. *

* Users should take care so that the {@code Runnable} instance provided as a close action does not reference this * memory sessison. This will create a reference cycle that will keep the session alive indefinitely if it is expected to be * cleanup up by a cleaner. * @param runnable the custom cleanup action to be associated with this memory session. * @throws IllegalStateException if this memory session is not {@linkplain #isAlive() alive}, or if access occurs from * a thread other than the thread {@linkplain #ownerThread() owning} this memory session. */ void addCloseAction(Runnable runnable); src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 64: > 62: import java.util.Objects; > 63: import java.util.function.Consumer; > 64: import java.util.function.UnaryOperator; Spurious imports? src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 499: > 497: @Override > 498: public MemorySession session() { > 499: return new MemorySessionImpl.NonCloseableView(sessionImpl()); Can this just return `MemorySession.global()`? src/java.base/share/classes/jdk/internal/foreign/abi/UpcallStubs.java line 59: > 57: } > 58: }); > 59: return new NativeSymbolImpl("upcall:" + Long.toHexString(entry), MemoryAddress.ofLong(entry), ((MemorySessionImpl)session)); If I understand correctly, this doesn't use `Scoped.toSessionImpl` since the session doesn't need to be closed in this case? test/jdk/java/foreign/SafeFunctionAccessTest.java line 192: > 190: static void checkSession(MemorySession session) { > 191: try { > 192: ((MemorySession)session).close(); Redundant cast? test/jdk/java/foreign/TestRestricted.java line 69: > 67: var mh = MethodHandles.lookup().findStatic(MemorySegment.class, "ofAddress", > 68: MethodType.methodType(MemorySegment.class, MemoryAddress.class, long.class, MemorySession.class)); > 69: var seg = (MemorySegment)mh.invoke(MemoryAddress.NULL, 4000L, MemorySession.global()); Why is this relaxed to invoke? test/jdk/java/foreign/valist/VaListTest.java line 132: > 130: = actions -> MacOsAArch64Linker.newVaList(actions, MemorySession.openConfined()); > 131: private static final Function, VaList> platformVaListFactory > 132: = (builder) -> VaList.make(builder, MemorySession.openConfined()); Now that the tests no longer close the scope, maybe these scopes should be implicit scopes? (at least then we still test the eventual closure of the VaList). test/micro/org/openjdk/bench/java/lang/foreign/BulkMismatchAcquire.java line 122: > 120: if (session instanceof MemorySession) { > 121: ((MemorySession) session).close(); > 122: } Seems like this check is redundant? Or maybe this should check for isCloseable ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 13:36:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 13:36:12 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v6] In-Reply-To: References: Message-ID: <00_aWAZ84M8pBeLczEPASBTa2IqVb5WCmXG1Oct5xBw=.da477378-161f-4fba-84d9-f3351b8199e0@github.com> On Mon, 21 Feb 2022 12:16:01 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix spurious reference to ResourceScopeImpl after merge > > src/java.base/share/classes/java/lang/foreign/MemorySession.java line 147: > >> 145: * a thread other than the thread {@linkplain #ownerThread() owning} this memory session. >> 146: */ >> 147: void addCloseAction(Runnable runnable); > > A note here, or on `openImplicit`, saying that a close action should not reference the session itself would be good I think. Suggestion inline (feel free to change). > Suggestion: > > /** > * Add a custom cleanup action which will be executed when the memory session is closed. > * The order in which custom cleanup actions are invoked once the memory session is closed is unspecified. > *

> * Users should take care so that the {@code Runnable} instance provided as a close action does not reference this > * memory sessison. This will create a reference cycle that will keep the session alive indefinitely if it is expected to be > * cleanup up by a cleaner. > * @param runnable the custom cleanup action to be associated with this memory session. > * @throws IllegalStateException if this memory session is not {@linkplain #isAlive() alive}, or if access occurs from > * a thread other than the thread {@linkplain #ownerThread() owning} this memory session. > */ > void addCloseAction(Runnable runnable); Though, this was pre-existing... so could be done in a followup as well. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 13:54:18 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 13:54:18 GMT Subject: [foreign-preview] RFR: 8282026: Remove support for unbound sequence layouts [v3] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 11:41:49 GMT, Maurizio Cimadamore wrote: >> When doing a pass over the memory layout API, I couldn't help noting that the API implementation and specification are made more complex by the fact that we have to specify what happens when a sequence layout *without a size* is found. Support for unbounded sequence layout was added many moons ago, with the understanding that it would have made life for jextract easier. >> >> This is not the case; all cases where jextract is using an unbounded sequence layout today can be replaced with using a simple zero-length sequence (which is allowed by the API, as are empty structs/unions). >> >> I also found that the only real use case for using unbounded sequence layout came from a quirk in the API to obtain var handles from layout. That is, if we want to obtain an indexed var handle into a JAVA_INT, we have to do the following: >> >> >> VarHandle intHandle = MemoryLayout.newSequenceLayout(JAVA_INT) >> .varHandle(PathElement.sequenceLayout()); >> >> >> In hindsight, this is just boilerplate: in this case the user only cares about the element layout (`JAVA_INT`), but the API wants the user to wrap that element layout in a new sequence layout, only to then provide a path inside the sequence layout (which will add a free dimension to the resulting var handle). >> >> It is not hard to see that all the above can be simplified, by adding an extra API method on memory layouts: >> >> >> VarHandle intHandle = JAVA_INT.arrayElementVarHandle(JAVA_INT); >> >> >> This more explicit, succint, and provdies less opportunities for bugs to hide. >> >> Therefore, this patch removes support for unbounded sequence element; the net effect is that now _all_ layouts have a size - which significantly simplifies the use sites where layout sizes are computed (no need to use optional there). All without losing much in terms of expressiveness: zero-length sequence layout can be used in basically the same way in which unbounded sequence layouts were used before. > > Maurizio Cimadamore 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 two new commits since the last revision: > > - Drop arrayElementSliceHandle > - Remove unused imports Marked as reviewed by jvernee (Committer). src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 241: > 239: newLayout = newLayout.withBitAlignment(oldLayout.bitAlignment()); > 240: if (oldLayout.name().isPresent()) { > 241: newLayout = newLayout.withName(oldLayout.name().get()); oof, nice catch! ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/642 From mcimadamore at openjdk.java.net Mon Feb 21 14:20:13 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 14:20:13 GMT Subject: [foreign-preview] Integrated: 8282026: Remove support for unbound sequence layouts In-Reply-To: References: Message-ID: <0zx0LsNOSx2aqr1pzim7uhiDN4ZgjSdV0Fkya0rUwPw=.304c4d61-28e4-4036-a9e7-0722fc3d1d9f@github.com> On Thu, 17 Feb 2022 15:23:43 GMT, Maurizio Cimadamore wrote: > When doing a pass over the memory layout API, I couldn't help noting that the API implementation and specification are made more complex by the fact that we have to specify what happens when a sequence layout *without a size* is found. Support for unbounded sequence layout was added many moons ago, with the understanding that it would have made life for jextract easier. > > This is not the case; all cases where jextract is using an unbounded sequence layout today can be replaced with using a simple zero-length sequence (which is allowed by the API, as are empty structs/unions). > > I also found that the only real use case for using unbounded sequence layout came from a quirk in the API to obtain var handles from layout. That is, if we want to obtain an indexed var handle into a JAVA_INT, we have to do the following: > > > VarHandle intHandle = MemoryLayout.newSequenceLayout(JAVA_INT) > .varHandle(PathElement.sequenceLayout()); > > > In hindsight, this is just boilerplate: in this case the user only cares about the element layout (`JAVA_INT`), but the API wants the user to wrap that element layout in a new sequence layout, only to then provide a path inside the sequence layout (which will add a free dimension to the resulting var handle). > > It is not hard to see that all the above can be simplified, by adding an extra API method on memory layouts: > > > VarHandle intHandle = JAVA_INT.arrayElementVarHandle(JAVA_INT); > > > This more explicit, succint, and provdies less opportunities for bugs to hide. > > Therefore, this patch removes support for unbounded sequence element; the net effect is that now _all_ layouts have a size - which significantly simplifies the use sites where layout sizes are computed (no need to use optional there). All without losing much in terms of expressiveness: zero-length sequence layout can be used in basically the same way in which unbounded sequence layouts were used before. This pull request has now been integrated. Changeset: 14b6c7b4 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/14b6c7b447e0ac50003b15b93a4e8577d094f665 Stats: 297 lines in 36 files changed: 24 ins; 177 del; 96 mod 8282026: Remove support for unbound sequence layouts Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/642 From mcimadamore at openjdk.java.net Mon Feb 21 14:37:41 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 14:37:41 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v2] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Avoid creation of ThreadListHandle in first handshake ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/5e26ae25..56a6543d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Mon Feb 21 15:06:53 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:06:53 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v3] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: fix whitespaces ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/56a6543d..ee128088 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Mon Feb 21 15:07:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:07:35 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v7] In-Reply-To: References: Message-ID: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'foreign-preview' into session_preview - Fix spurious reference to ResourceScopeImpl after merge - Merge branch 'foreign-preview' into session_preview - Address review comments * replace spurious usages of `scope` in direct buffer template - Update src/java.base/share/classes/java/lang/ClassLoader.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Co-authored-by: Paul Sandoz - Fix more spurious usages of ResourceScope - Fix whitespaces - Merge branch 'foreign-preview' into session_preview - Fix reference to ResourceScope in javadoc - ... and 2 more: https://git.openjdk.java.net/panama-foreign/compare/14b6c7b4...bee07da5 ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/641/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=06 Stats: 4693 lines in 139 files changed: 1496 ins; 1328 del; 1869 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Mon Feb 21 15:07:38 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:07:38 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v7] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:30:31 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'foreign-preview' into session_preview >> - Fix spurious reference to ResourceScopeImpl after merge >> - Merge branch 'foreign-preview' into session_preview >> - Address review comments >> * replace spurious usages of `scope` in direct buffer template >> - Update src/java.base/share/classes/java/lang/ClassLoader.java >> >> Co-authored-by: Paul Sandoz >> - Update src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template >> >> Co-authored-by: Paul Sandoz >> - Fix more spurious usages of ResourceScope >> - Fix whitespaces >> - Merge branch 'foreign-preview' into session_preview >> - Fix reference to ResourceScope in javadoc >> - ... and 2 more: https://git.openjdk.java.net/panama-foreign/compare/14b6c7b4...bee07da5 > > src/java.base/share/classes/jdk/internal/foreign/abi/UpcallStubs.java line 59: > >> 57: } >> 58: }); >> 59: return new NativeSymbolImpl("upcall:" + Long.toHexString(entry), MemoryAddress.ofLong(entry), ((MemorySessionImpl)session)); > > If I understand correctly, this doesn't use `Scoped.toSessionImpl` since the session doesn't need to be closed in this case? No: `NativeSymbolImpl` wants a true, closeable MemorySessionImpl. Then, if you look at that class, its `session` method will return a non closeable view of that session. The `toSessionImpl` happens in `AbstractCLinker::upcallStub`. > test/jdk/java/foreign/TestRestricted.java line 69: > >> 67: var mh = MethodHandles.lookup().findStatic(MemorySegment.class, "ofAddress", >> 68: MethodType.methodType(MemorySegment.class, MemoryAddress.class, long.class, MemorySession.class)); >> 69: var seg = (MemorySegment)mh.invoke(MemoryAddress.NULL, 4000L, MemorySession.global()); > > Why is this relaxed to invoke? Not sure - probably just a refactoring accident ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 15:17:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 15:17:00 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 15:06:53 GMT, Maurizio Cimadamore wrote: >> This patch improves the logic for closing shared resource scopes, by using the following algorithm: >> >> 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope >> 2. do an initial handshake, to collect all threads that are accessing the scope concurrently >> 3. if no thread is found, finish >> 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). >> >> Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. >> >> Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). >> >> Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespaces I'll run tests on Windows as well. src/hotspot/share/prims/scopedMemoryAccess.cpp line 87: > 85: LockFreeStackThreadsElement(JavaThread* thread) : _entry(), _thread(thread) {} > 86: typedef LockFreeStack ThreadStack; > 87: }; 2 things in this class. 1. `_entry` seems to be the next entry in the stack (looking at LockFreeStack). So I'd prefer to call the field and function `_next` and `next_ptr` respectively. 2. The _entry() field is default initialized, which AFAIK means it might be garbage. Either way, please initialize it to `nullptr` explicitly. Suggestion: class LockFreeStackThreadsElement : public CHeapObj { typedef LockFreeStackThreadsElement Element; Element* volatile _next; static Element* volatile* next_ptr(Element& e) { return &e._next; } public: JavaThread* _thread; LockFreeStackThreadsElement(JavaThread* thread) : _next(nullptr), _thread(thread) {} typedef LockFreeStack ThreadStack; }; src/hotspot/share/prims/scopedMemoryAccess.cpp line 190: > 188: // if the thread is not in the list handle, we can safely skip further handshakes, > 189: // as that means that the thread has been created when the scope state has already > 190: // been set to CLOSED - meaning that the thread access will fail anyway. I don't get this comment... It seems true that 1. there might be threads in the thread list which are not in the problematic stack. 2. or vice versa, there can be threads in the stack that are not in the thread list. --- 1. seems to be covered by the fact that we are iterating the threads in the thread stack, instead of the ones in the list. 2. It seems that the `includes` check is needed since a thread might have died since the initial handshake, in which case we don't want to handshake it again? So, I think the comment should read something regarding 2. instead. e.g. Suggestion: // if the thread is not in the list handle, it means that it has died since the initial handshake. // in that case we don't need to handshake it again. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Mon Feb 21 15:25:44 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:25:44 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v8] In-Reply-To: References: Message-ID: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/641/files - new: https://git.openjdk.java.net/panama-foreign/pull/641/files/bee07da5..d1fc22b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=07 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=06-07 Stats: 14 lines in 6 files changed: 2 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 15:25:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 15:25:44 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v8] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 15:21:50 GMT, Maurizio Cimadamore wrote: >> This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html >> [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 15:25:45 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 15:25:45 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v8] In-Reply-To: References: Message-ID: <4yrEEKJgFDdJ7nbTlpB6M8Qk0vrp2gQpBORG0QHzwgU=.d7bf64ad-5c48-40a1-b260-f90898694d62@github.com> On Mon, 21 Feb 2022 15:02:49 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/UpcallStubs.java line 59: >> >>> 57: } >>> 58: }); >>> 59: return new NativeSymbolImpl("upcall:" + Long.toHexString(entry), MemoryAddress.ofLong(entry), ((MemorySessionImpl)session)); >> >> If I understand correctly, this doesn't use `Scoped.toSessionImpl` since the session doesn't need to be closed in this case? > > No: `NativeSymbolImpl` wants a true, closeable MemorySessionImpl. Then, if you look at that class, its `session` method will return a non closeable view of that session. The `toSessionImpl` happens in `AbstractCLinker::upcallStub`. I see. I think that's fine, but maybe that call should be moved here for clarity? (or maybe just add an `assert session.isClosable()` for documentation). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 15:33:03 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 15:33:03 GMT Subject: [foreign-preview] RFR: 8282069: Set correct alignment constraints on ValueLayout constants In-Reply-To: References: Message-ID: <6BzGLQWkCCF4YuSlF-yqOUP6uBLnZ5yHZjFTfSf0wH8=.71152054-2bb4-4e89-b210-69dcad126649@github.com> On Fri, 18 Feb 2022 18:14:43 GMT, Maurizio Cimadamore wrote: > Now that we have a good understanding of how to enforce alignment checks for both off-heap _and_ heap segments, we are in a position to set the correct alignment constraints on the various `ValueLayout.JAVA_XYZ` constants. > > The source changes are quite trivial; fixing the tests less so. The main issue is that some of the test are quite liberal in moving things in and out of `byte[]`. E.g. they create a `byte[]` and want to store a `JAVA_LONG` in it. If `JAVA_LONG` has the correct alignment (8 bytes) there's no way we can guarantee correctness and the code now fails (correctly). > > Also, we now proprerly check alignment on bulk copy operations too - so bulk copy tests, which were ok before, now fail when correct alignment constraints are applied. > > I've fixed some of the tests in simple ways - e.g. by using a `long[]` instead of a `byte[]`. But in some of the most complex tests I had to define unaligned layouts, as some of the tests are peeking and poking at memory in ways that is not compatible with aligned access (the byte buffer test is a good one, as byte buffer access is not aligned). > > Also, I had to tweak some code in the `BindingSpecializer` class - some of the bindings can sometimes read multiple fields in a single shot - so e.g. if you have a struct like `[f32 f32]` a single `long` read is performed to read both fields. This means that we do a `JAVA_LONG` read, but with an underlying memory alignment of 4, which is not going to work in some cases (especially in upcalls, where we use an arena allocator to allocate temp buffers; the arena allocator can "pack" structs more than just using `malloc`). For this reason I had to change that code to use unaligned layouts as well. Marked as reviewed by jvernee (Committer). src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 547: > 545: /** > 546: * A value layout constant whose size is the same as that of a machine address ({@code size_t}), > 547: * bit alignment set to {@code size_t * 8}, and byte order set to {@link ByteOrder#nativeOrder()}. Suggestion: * bit alignment set to {@code sizeof(size_t) * 8}, and byte order set to {@link ByteOrder#nativeOrder()}. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/647 From mcimadamore at openjdk.java.net Mon Feb 21 15:38:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:38:47 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v9] In-Reply-To: References: Message-ID: <-uypBnpPWAc7KUBAQGfWfIGC_IkdL2f1mLPm-G5lbsU=.11cb626c-1e4d-4fb7-9b3b-00821863a472@github.com> > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add a comment in UpcallStubs ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/641/files - new: https://git.openjdk.java.net/panama-foreign/pull/641/files/d1fc22b4..1b10439f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=08 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=641&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/641/head:pull/641 PR: https://git.openjdk.java.net/panama-foreign/pull/641 From jvernee at openjdk.java.net Mon Feb 21 15:38:48 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 15:38:48 GMT Subject: [foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession [v9] In-Reply-To: <4yrEEKJgFDdJ7nbTlpB6M8Qk0vrp2gQpBORG0QHzwgU=.d7bf64ad-5c48-40a1-b260-f90898694d62@github.com> References: <4yrEEKJgFDdJ7nbTlpB6M8Qk0vrp2gQpBORG0QHzwgU=.d7bf64ad-5c48-40a1-b260-f90898694d62@github.com> Message-ID: On Mon, 21 Feb 2022 15:19:40 GMT, Jorn Vernee wrote: >> No: `NativeSymbolImpl` wants a true, closeable MemorySessionImpl. Then, if you look at that class, its `session` method will return a non closeable view of that session. The `toSessionImpl` happens in `AbstractCLinker::upcallStub`. > > I see. I think that's fine, but maybe that call should be moved here for clarity? (or maybe just add an `assert session.isClosable()` for documentation). Thanks, the comment helps :) ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Mon Feb 21 15:41:43 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:41:43 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v4] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/prims/scopedMemoryAccess.cpp Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/ee128088..2479b986 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Mon Feb 21 15:41:44 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:41:44 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 15:02:35 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> fix whitespaces > > src/hotspot/share/prims/scopedMemoryAccess.cpp line 87: > >> 85: LockFreeStackThreadsElement(JavaThread* thread) : _entry(), _thread(thread) {} >> 86: typedef LockFreeStack ThreadStack; >> 87: }; > > 2 things in this class. > 1. `_entry` seems to be the next entry in the stack (looking at LockFreeStack). So I'd prefer to call the field and function `_next` and `next_ptr` respectively. > 2. The _entry() field is default initialized, which AFAIK means it might be garbage (depending on what the compiler does). Either way, please initialize it to `nullptr` explicitly. > Suggestion: > > class LockFreeStackThreadsElement : public CHeapObj { > typedef LockFreeStackThreadsElement Element; > > Element* volatile _next; > static Element* volatile* next_ptr(Element& e) { return &e._next; } > > public: > JavaThread* _thread; > LockFreeStackThreadsElement(JavaThread* thread) : _next(nullptr), _thread(thread) {} > typedef LockFreeStack ThreadStack; > }; Thanks for the suggestion > src/hotspot/share/prims/scopedMemoryAccess.cpp line 190: > >> 188: // if the thread is not in the list handle, we can safely skip further handshakes, >> 189: // as that means that the thread has been created when the scope state has already >> 190: // been set to CLOSED - meaning that the thread access will fail anyway. > > I don't get this comment... > > It seems true that > 1. there might be threads in the thread list which are not in the problematic stack. (threads that were created after the initial handshake) > 2. or vice versa, there can be threads in the stack that are not in the thread list. (threads that have died since the initial handshake) > > --- > > 1. seems to be covered by the fact that we are iterating the threads in the thread stack, instead of the ones in the list. > 2. It seems that the `includes` check is needed since a thread might have died since the initial handshake, in which case we don't want to handshake it again? > > So, I think the comment should read something regarding 2. instead. e.g. > Suggestion: > > // if the thread is not in the list handle, it means that it has died since the initial handshake. > // in that case we don't need to handshake it again. The logic here has changed to reflect some internal comments - I will update the comment accordingly ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Mon Feb 21 15:48:53 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:48:53 GMT Subject: [foreign-preview] RFR: 8282069: Set correct alignment constraints on ValueLayout constants [v2] In-Reply-To: References: Message-ID: > Now that we have a good understanding of how to enforce alignment checks for both off-heap _and_ heap segments, we are in a position to set the correct alignment constraints on the various `ValueLayout.JAVA_XYZ` constants. > > The source changes are quite trivial; fixing the tests less so. The main issue is that some of the test are quite liberal in moving things in and out of `byte[]`. E.g. they create a `byte[]` and want to store a `JAVA_LONG` in it. If `JAVA_LONG` has the correct alignment (8 bytes) there's no way we can guarantee correctness and the code now fails (correctly). > > Also, we now proprerly check alignment on bulk copy operations too - so bulk copy tests, which were ok before, now fail when correct alignment constraints are applied. > > I've fixed some of the tests in simple ways - e.g. by using a `long[]` instead of a `byte[]`. But in some of the most complex tests I had to define unaligned layouts, as some of the tests are peeking and poking at memory in ways that is not compatible with aligned access (the byte buffer test is a good one, as byte buffer access is not aligned). > > Also, I had to tweak some code in the `BindingSpecializer` class - some of the bindings can sometimes read multiple fields in a single shot - so e.g. if you have a struct like `[f32 f32]` a single `long` read is performed to read both fields. This means that we do a `JAVA_LONG` read, but with an underlying memory alignment of 4, which is not going to work in some cases (especially in upcalls, where we use an arena allocator to allocate temp buffers; the arena allocator can "pack" structs more than just using `malloc`). For this reason I had to change that code to use unaligned layouts as well. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/foreign/ValueLayout.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/647/files - new: https://git.openjdk.java.net/panama-foreign/pull/647/files/007f8e9b..6edf30cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=647&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=647&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/647.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/647/head:pull/647 PR: https://git.openjdk.java.net/panama-foreign/pull/647 From mcimadamore at openjdk.java.net Mon Feb 21 15:49:53 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:49:53 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v5] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak comments in scopedMemoryAccess ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/2479b986..13306945 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=04 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=03-04 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From jvernee at openjdk.java.net Mon Feb 21 15:49:53 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 15:49:53 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v5] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 15:45:41 GMT, Maurizio Cimadamore wrote: >> This patch improves the logic for closing shared resource scopes, by using the following algorithm: >> >> 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope >> 2. do an initial handshake, to collect all threads that are accessing the scope concurrently >> 3. if no thread is found, finish >> 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). >> >> Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. >> >> Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). >> >> Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak comments in scopedMemoryAccess Nice! Tests also pass on Windows ------------- Marked as reviewed by jvernee (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Mon Feb 21 15:50:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 15:50:10 GMT Subject: [foreign-preview] Integrated: 8281855: Rename ResourceScope to MemorySession In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 17:32:50 GMT, Maurizio Cimadamore wrote: > This patch implements some of the changes described in [1] and [2]. More specifically, the `ResourceScope` abstraction is renamed into `MemorySession`, and the session accessors in `MemorySegment`, `NativeSymbol` and `VaList` are tweaked to return *non-closeable* session views. To counteract this change, `MemorySession` now supports `equals` and `hashCode`, so that sessions views can be compared to each other in ways that are not identity-sensitive. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016152.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016254.html This pull request has now been integrated. Changeset: 9214de40 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/9214de405df46073544e1535f4399d82c6226333 Stats: 4693 lines in 139 files changed: 1496 ins; 1328 del; 1869 mod 8281855: Rename ResourceScope to MemorySession Reviewed-by: psandoz, jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/641 From mcimadamore at openjdk.java.net Mon Feb 21 16:07:31 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 16:07:31 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v6] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'foreign-preview' into better-handshake - Tweak comments in scopedMemoryAccess - Update src/hotspot/share/prims/scopedMemoryAccess.cpp Co-authored-by: Jorn Vernee - fix whitespaces - Avoid creation of ThreadListHandle in first handshake - Fix whitespaces - Tweak ResourceScope javadoc - More cleanup: make close_scope return type be `void` - Add more code comments - Add comments, fix test - ... and 1 more: https://git.openjdk.java.net/panama-foreign/compare/9214de40...e7bf6c07 ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/643/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=05 Stats: 82 lines in 4 files changed: 50 ins; 14 del; 18 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Mon Feb 21 16:14:22 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 16:14:22 GMT Subject: [foreign-preview] RFR: 8282069: Set correct alignment constraints on ValueLayout constants [v3] In-Reply-To: References: Message-ID: > Now that we have a good understanding of how to enforce alignment checks for both off-heap _and_ heap segments, we are in a position to set the correct alignment constraints on the various `ValueLayout.JAVA_XYZ` constants. > > The source changes are quite trivial; fixing the tests less so. The main issue is that some of the test are quite liberal in moving things in and out of `byte[]`. E.g. they create a `byte[]` and want to store a `JAVA_LONG` in it. If `JAVA_LONG` has the correct alignment (8 bytes) there's no way we can guarantee correctness and the code now fails (correctly). > > Also, we now proprerly check alignment on bulk copy operations too - so bulk copy tests, which were ok before, now fail when correct alignment constraints are applied. > > I've fixed some of the tests in simple ways - e.g. by using a `long[]` instead of a `byte[]`. But in some of the most complex tests I had to define unaligned layouts, as some of the tests are peeking and poking at memory in ways that is not compatible with aligned access (the byte buffer test is a good one, as byte buffer access is not aligned). > > Also, I had to tweak some code in the `BindingSpecializer` class - some of the bindings can sometimes read multiple fields in a single shot - so e.g. if you have a struct like `[f32 f32]` a single `long` read is performed to read both fields. This means that we do a `JAVA_LONG` read, but with an underlying memory alignment of 4, which is not going to work in some cases (especially in upcalls, where we use an arena allocator to allocate temp buffers; the arena allocator can "pack" structs more than just using `malloc`). For this reason I had to change that code to use unaligned layouts as well. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'foreign-preview' into aligned_layout_constants - Update src/java.base/share/classes/java/lang/foreign/ValueLayout.java Co-authored-by: Jorn Vernee - Fix spliterator test - Initial push ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/647/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=647&range=02 Stats: 162 lines in 9 files changed: 41 ins; 20 del; 101 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/647.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/647/head:pull/647 PR: https://git.openjdk.java.net/panama-foreign/pull/647 From mcimadamore at openjdk.java.net Mon Feb 21 16:14:24 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 16:14:24 GMT Subject: [foreign-preview] Integrated: 8282069: Set correct alignment constraints on ValueLayout constants In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 18:14:43 GMT, Maurizio Cimadamore wrote: > Now that we have a good understanding of how to enforce alignment checks for both off-heap _and_ heap segments, we are in a position to set the correct alignment constraints on the various `ValueLayout.JAVA_XYZ` constants. > > The source changes are quite trivial; fixing the tests less so. The main issue is that some of the test are quite liberal in moving things in and out of `byte[]`. E.g. they create a `byte[]` and want to store a `JAVA_LONG` in it. If `JAVA_LONG` has the correct alignment (8 bytes) there's no way we can guarantee correctness and the code now fails (correctly). > > Also, we now proprerly check alignment on bulk copy operations too - so bulk copy tests, which were ok before, now fail when correct alignment constraints are applied. > > I've fixed some of the tests in simple ways - e.g. by using a `long[]` instead of a `byte[]`. But in some of the most complex tests I had to define unaligned layouts, as some of the tests are peeking and poking at memory in ways that is not compatible with aligned access (the byte buffer test is a good one, as byte buffer access is not aligned). > > Also, I had to tweak some code in the `BindingSpecializer` class - some of the bindings can sometimes read multiple fields in a single shot - so e.g. if you have a struct like `[f32 f32]` a single `long` read is performed to read both fields. This means that we do a `JAVA_LONG` read, but with an underlying memory alignment of 4, which is not going to work in some cases (especially in upcalls, where we use an arena allocator to allocate temp buffers; the arena allocator can "pack" structs more than just using `malloc`). For this reason I had to change that code to use unaligned layouts as well. This pull request has now been integrated. Changeset: afad8e0d Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/afad8e0dc58c0adee6b858cc1c2139ffdfa9e7e0 Stats: 162 lines in 9 files changed: 41 ins; 20 del; 101 mod 8282069: Set correct alignment constraints on ValueLayout constants Reviewed-by: psandoz, jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/647 From jvernee at openjdk.java.net Mon Feb 21 16:14:36 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 16:14:36 GMT Subject: [foreign-preview] RFR: 8280721: Rewrite binding of foreign classes to use javaClasses.h/cpp [v3] In-Reply-To: References: Message-ID: > Hi, > > This patch is a refactoring of the binding between the VM and several Java classes using by the linker. > > The usual way of creating such mappings is by declaring a C++ companion class in javaClasses.(h/c)pp, but because the bound Javas classes were previously in an incubator module, that wasn't possible. > > Now that we have moved to java.base, we can create the missing C++ companion classes, and remove the code that did ad-hoc lookup of field offsets in the constructor of the ForeignGlobals class in the VM. > > Additionally, this patch also removes 2 proxy classes (VMStorageProxy and ABIDescriptorProxy) that are no longer needed. As well as move NativeEntryPoint from the jdk.internal.invoke package to the jdk.internal.foreign package, since it was the only class in that package. > > Thanks, > Jorn Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Drop incorrect imports - Fix spurious semantics change - Merge branch 'foreign-preview' into Move_Internal_Invoke - Merge branch 'foreign-preview' into Move_Internal_Invoke - Remove unimplemented NativeCallConv::print_on - Add direct javaClasses bindings for panama foreign classes - Remove jdk.internal.invoke package ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/634/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=634&range=02 Stats: 618 lines in 27 files changed: 314 ins; 245 del; 59 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/634.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/634/head:pull/634 PR: https://git.openjdk.java.net/panama-foreign/pull/634 From mcimadamore at openjdk.java.net Mon Feb 21 16:33:05 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 16:33:05 GMT Subject: [foreign-preview] RFR: 8280721: Rewrite binding of foreign classes to use javaClasses.h/cpp [v3] In-Reply-To: References: Message-ID: <2-xbUNc3b6mtsGx2jo-0ZIxow87QKfPd7VR_w7Tw384=.7a7e6248-4d35-485a-975b-a1474adb23c9@github.com> On Mon, 21 Feb 2022 16:14:36 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch is a refactoring of the binding between the VM and several Java classes using by the linker. >> >> The usual way of creating such mappings is by declaring a C++ companion class in javaClasses.(h/c)pp, but because the bound Javas classes were previously in an incubator module, that wasn't possible. >> >> Now that we have moved to java.base, we can create the missing C++ companion classes, and remove the code that did ad-hoc lookup of field offsets in the constructor of the ForeignGlobals class in the VM. >> >> Additionally, this patch also removes 2 proxy classes (VMStorageProxy and ABIDescriptorProxy) that are no longer needed. As well as move NativeEntryPoint from the jdk.internal.invoke package to the jdk.internal.foreign package, since it was the only class in that package. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Drop incorrect imports > - Fix spurious semantics change > - Merge branch 'foreign-preview' into Move_Internal_Invoke > - Merge branch 'foreign-preview' into Move_Internal_Invoke > - Remove unimplemented NativeCallConv::print_on > - Add direct javaClasses bindings for panama foreign classes > - Remove jdk.internal.invoke package Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/634 From jvernee at openjdk.java.net Mon Feb 21 16:37:10 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 16:37:10 GMT Subject: [foreign-preview] Integrated: 8280721: Rewrite binding of foreign classes to use javaClasses.h/cpp In-Reply-To: References: Message-ID: <6QUeQv0U5fnfy1eFWx7QQ87bZLVrjknkCP_jrkHXVK4=.7602a173-82a3-47b2-98dd-a221108681bf@github.com> On Mon, 31 Jan 2022 16:25:58 GMT, Jorn Vernee wrote: > Hi, > > This patch is a refactoring of the binding between the VM and several Java classes using by the linker. > > The usual way of creating such mappings is by declaring a C++ companion class in javaClasses.(h/c)pp, but because the bound Javas classes were previously in an incubator module, that wasn't possible. > > Now that we have moved to java.base, we can create the missing C++ companion classes, and remove the code that did ad-hoc lookup of field offsets in the constructor of the ForeignGlobals class in the VM. > > Additionally, this patch also removes 2 proxy classes (VMStorageProxy and ABIDescriptorProxy) that are no longer needed. As well as move NativeEntryPoint from the jdk.internal.invoke package to the jdk.internal.foreign package, since it was the only class in that package. > > Thanks, > Jorn This pull request has now been integrated. Changeset: 06223fb7 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/06223fb7251b9f69c8c48393cd2e5026c27e5c30 Stats: 618 lines in 27 files changed: 314 ins; 245 del; 59 mod 8280721: Rewrite binding of foreign classes to use javaClasses.h/cpp Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/634 From mcimadamore at openjdk.java.net Mon Feb 21 16:51:38 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 16:51:38 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v7] In-Reply-To: References: Message-ID: <49FBgQF0AWA6X2J4u1HxG4NHSpdQtXA5Fbhy42telZk=.0c6df19c-45ce-494a-9125-8ecd7e784c94@github.com> > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak javadoc @throws tag for `MemorySession::close` ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/e7bf6c07..1d18dd30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=06 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From sundar at openjdk.java.net Mon Feb 21 17:04:39 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 21 Feb 2022 17:04:39 GMT Subject: [foreign-jextract] RFR: 8281764: jextract does not generate parameter names for function pointer typedefs [v3] In-Reply-To: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> References: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> Message-ID: > Propagating TypedefDecl's ParmDecl child cursors to Types. Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: refactored pointer-type check to Utils.java ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/646/files - new: https://git.openjdk.java.net/panama-foreign/pull/646/files/0a8d2e20..b798cad9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=646&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=646&range=01-02 Stats: 19 lines in 3 files changed: 12 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/646.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/646/head:pull/646 PR: https://git.openjdk.java.net/panama-foreign/pull/646 From sundar at openjdk.java.net Mon Feb 21 17:04:40 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 21 Feb 2022 17:04:40 GMT Subject: [foreign-jextract] RFR: 8281764: jextract does not generate parameter names for function pointer typedefs [v2] In-Reply-To: <5FP9wDoVCCOns7BA-hn9m6B661ciYxYYCVuJnISBe7Y=.6505e0b2-ef80-4e15-b55d-3599f9a01a54@github.com> References: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> <7cTdC68kRRDTmW8bIk4o2fIqfpg9ybSY-IBfoowjUUk=.671b2a0f-de4d-47e8-939c-9e16b8981eae@github.com> <5FP9wDoVCCOns7BA-hn9m6B661ciYxYYCVuJnISBe7Y=.6505e0b2-ef80-4e15-b55d-3599f9a01a54@github.com> Message-ID: On Mon, 21 Feb 2022 10:26:47 GMT, Athijegannathan Sundararajan wrote: >> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TreeMaker.java line 262: >> >>> 260: Type.Function funcType = null; >>> 261: boolean isFuncPtrType = false; >>> 262: if (canonicalType instanceof Type.Function) { >> >> I believe `OutputFactory::getAsFunctionPointer` as code that is similar to this (given a type, return it as a function type - following typedefs if necessary). Maybe we should move this into some util function and share? > > That part of the code assumes all Types are properly resolved. In TreeMaker, we're in the middle TypeMaker's construction (resolution happens later). refactored pointer type check to Utils.java. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/646 From jvernee at openjdk.java.net Mon Feb 21 17:30:17 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 17:30:17 GMT Subject: [foreign-preview] RFR: Remove unused functions and includes Message-ID: This patch removes some unused functions and includes which GCC was issuing warnings about. ------------- Commit messages: - Remove unused functions and includes Changes: https://git.openjdk.java.net/panama-foreign/pull/648/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=648&range=00 Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/648.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/648/head:pull/648 PR: https://git.openjdk.java.net/panama-foreign/pull/648 From mcimadamore at openjdk.java.net Mon Feb 21 18:16:05 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 18:16:05 GMT Subject: [foreign-preview] RFR: Remove unused functions and includes In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 17:23:42 GMT, Jorn Vernee wrote: > This patch removes some unused functions and includes which GCC was issuing warnings about. Works on Linux ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/648 From jvernee at openjdk.java.net Mon Feb 21 18:21:03 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Feb 2022 18:21:03 GMT Subject: [foreign-preview] Integrated: Remove unused functions and includes In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 17:23:42 GMT, Jorn Vernee wrote: > This patch removes some unused functions and includes which GCC was issuing warnings about. This pull request has now been integrated. Changeset: a225c6e3 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/a225c6e392493162080d15725a8c5180050fd8c3 Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod Remove unused functions and includes Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/648 From mcimadamore at openjdk.java.net Mon Feb 21 18:23:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Feb 2022 18:23:35 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v8] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix reference to boolean return type in ScopedMemoryAccess::closeScope ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/1d18dd30..fee2a483 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=07 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=06-07 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From dholmes at openjdk.java.net Tue Feb 22 00:50:06 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Feb 2022 00:50:06 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v8] In-Reply-To: References: Message-ID: <9Gj9bchLWW5adWUNpHjKeFdoRWihUNluQa_s1Fv8JRE=.0a09d536-ca62-42aa-acde-c2df2bbacd6c@github.com> On Mon, 21 Feb 2022 18:23:35 GMT, Maurizio Cimadamore wrote: >> This patch improves the logic for closing shared resource scopes, by using the following algorithm: >> >> 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope >> 2. do an initial handshake, to collect all threads that are accessing the scope concurrently >> 3. if no thread is found, finish >> 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). >> >> Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. >> >> Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). >> >> Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix reference to boolean return type in ScopedMemoryAccess::closeScope Hi Maurizio, A few minor nits on the comments but the handshaking protocol looks good. Thanks, David src/hotspot/share/prims/scopedMemoryAccess.cpp line 162: > 160: > 161: /* > 162: * This functin performs a thread-local handshake against all threads running at the time s/functin/function/ src/hotspot/share/prims/scopedMemoryAccess.cpp line 164: > 162: * This functin performs a thread-local handshake against all threads running at the time > 163: * the given scope (deopt) was closed. If the handshake closure finds that a thread has > 164: * safepointed inside a scoped method (that is, a method inside the ScopedMemoryAccess class Do you really mean "safepointed" here, or do you just mean the point where the handshake is processed? src/hotspot/share/prims/scopedMemoryAccess.cpp line 167: > 165: * annotated with the '@Scoped' annotation), whose local variables mention the scope being closed > 166: * (deopt), the thread is added to a problematic stack. After the handshake, each thread in > 167: * the problematic stack is handshaked again, individually, to check that it has exited I suggest saying "list" rather than "stack" as VM developers tend to assume "stack" means thread stack. src/hotspot/share/prims/scopedMemoryAccess.cpp line 183: > 181: return; > 182: } > 183: // now iterate on all problematic threads, until we converge. Note: from this point on, s/now/Now/ s/on/over/ src/hotspot/share/prims/scopedMemoryAccess.cpp line 191: > 189: while (element != NULL) { > 190: JavaThread* thread = element->_thread; > 191: // if the thread is not in the list handle, it means that the thread has died, s/if/If/ ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/643 From sundar at openjdk.java.net Tue Feb 22 02:51:15 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 22 Feb 2022 02:51:15 GMT Subject: [foreign-jextract] Integrated: 8281764: jextract does not generate parameter names for function pointer typedefs In-Reply-To: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> References: <0smENTD6uskaxtMdUwSgpQPBOZ6OJtnqAoZ7GL1m3Wg=.5ce81d75-6cc0-4779-a812-40c8af9ca165@github.com> Message-ID: On Fri, 18 Feb 2022 12:42:39 GMT, Athijegannathan Sundararajan wrote: > Propagating TypedefDecl's ParmDecl child cursors to Types. This pull request has now been integrated. Changeset: f03c3135 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/f03c31351a35b8bbd84eb7e6b12522730e73923b Stats: 167 lines in 12 files changed: 146 ins; 6 del; 15 mod 8281764: jextract does not generate parameter names for function pointer typedefs Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/646 From mcimadamore at openjdk.java.net Tue Feb 22 09:57:54 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 09:57:54 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v9] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments: Fix comments in scopedMemoryAccess::closeScope ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/fee2a483..a266c779 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=08 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=07-08 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From mcimadamore at openjdk.java.net Tue Feb 22 10:46:28 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 10:46:28 GMT Subject: [foreign-preview] RFR: 8282215: Handle failures when initializing SystemLookup Message-ID: This patch handles failures originating from initialization of the SystemLookup class; instead of propagating these failures, we now swallow them, so that initialization of a `CLinker` can proceed. This adds some robustness to client code, and doubles down on the optional return type of the CLinker's lookup method. The test checks that, when running with `os.name` set to Windows, we always manage to perform a lookup (even if we are executing the test on Linux/MacOS). The test trivially passes on Windows. ------------- Commit messages: - Fix jtreg test header - Tweak lookup name - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/649/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=649&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282215 Stats: 63 lines in 3 files changed: 58 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/649/head:pull/649 PR: https://git.openjdk.java.net/panama-foreign/pull/649 From mcimadamore at openjdk.java.net Tue Feb 22 10:46:29 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 10:46:29 GMT Subject: [foreign-preview] RFR: 8282215: Handle failures when initializing SystemLookup In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 10:39:06 GMT, Maurizio Cimadamore wrote: > This patch handles failures originating from initialization of the SystemLookup class; instead of propagating these failures, we now swallow them, so that initialization of a `CLinker` can proceed. This adds some robustness to client code, and doubles down on the optional return type of the CLinker's lookup method. > > The test checks that, when running with `os.name` set to Windows, we always manage to perform a lookup (even if we are executing the test on Linux/MacOS). The test trivially passes on Windows. src/java.base/share/classes/java/lang/foreign/SequenceLayout.java line 94: > 92: > 93: /** > 94: * {@return the element count of this sequence layout} This is an unrelated fix, addressing a javadoc issue introduced by JDK-8282026 ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/649 From jvernee at openjdk.java.net Tue Feb 22 12:47:06 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 12:47:06 GMT Subject: [foreign-preview] RFR: 8282215: Handle failures when initializing SystemLookup In-Reply-To: References: Message-ID: <_vOqk611jT7hFliA1SJ9DblbD9q-yf71Tb_6GN8sSUM=.bf1707a5-e8d7-4184-ae11-c2d1bbcf7040@github.com> On Tue, 22 Feb 2022 10:39:06 GMT, Maurizio Cimadamore wrote: > This patch handles failures originating from initialization of the SystemLookup class; instead of propagating these failures, we now swallow them, so that initialization of a `CLinker` can proceed. This adds some robustness to client code, and doubles down on the optional return type of the CLinker's lookup method. > > The test checks that, when running with `os.name` set to Windows, we always manage to perform a lookup (even if we are executing the test on Linux/MacOS). The test trivially passes on Windows. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/649 From mcimadamore at openjdk.java.net Tue Feb 22 13:04:05 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 13:04:05 GMT Subject: [foreign-preview] Integrated: 8282215: Handle failures when initializing SystemLookup In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 10:39:06 GMT, Maurizio Cimadamore wrote: > This patch handles failures originating from initialization of the SystemLookup class; instead of propagating these failures, we now swallow them, so that initialization of a `CLinker` can proceed. This adds some robustness to client code, and doubles down on the optional return type of the CLinker's lookup method. > > The test checks that, when running with `os.name` set to Windows, we always manage to perform a lookup (even if we are executing the test on Linux/MacOS). The test trivially passes on Windows. This pull request has now been integrated. Changeset: 5620d82e Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/5620d82e42996edaa2109b2dd5cc99bfd4eb6df2 Stats: 63 lines in 3 files changed: 58 ins; 0 del; 5 mod 8282215: Handle failures when initializing SystemLookup Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/649 From mcimadamore at openjdk.java.net Tue Feb 22 13:11:27 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 13:11:27 GMT Subject: [foreign-preview] RFR: 8280460: MemorySegment::allocateNative should be tolerant of zero-sized allocation requests Message-ID: This patch addresses the issues discussed here: https://mail.openjdk.java.net/pipermail/panama-dev/2022-January/016071.html And makes `MemorySegment::allocateNative` tolerand of zero-sized allocation requests. After evaluating a number of alternatives, I have decided to do what `ByteBuffer` also does, that is, always compute the size of the allocation as `max(size, 1L)`. This means that we always perform some allocation - which works better with alignment constraints (e.g. the address you get back is aligned as per request; this is a corner case, but makes the API more consistent). I've tweaked the javadoc to reflect that (and also added some javadoc to `SegmentAllocator` as well), and added a test for various kinds of native segments, created both safely and unsafely. ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/650/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=650&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280460 Stats: 37 lines in 6 files changed: 27 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/650.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/650/head:pull/650 PR: https://git.openjdk.java.net/panama-foreign/pull/650 From anhmdq at gmail.com Tue Feb 22 13:17:47 2022 From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=) Date: Tue, 22 Feb 2022 21:17:47 +0800 Subject: UTF-8 validation using Vector API In-Reply-To: <01ABCEF1-EE22-46ED-95DB-CA8CCF970AAF@oracle.com> References: <01ABCEF1-EE22-46ED-95DB-CA8CCF970AAF@oracle.com> Message-ID: Hi, Thank you very much for your comprehensive response and insightful document. The idea of tracking the value interval (as being done with scalar) of each lane in vectors is really elegant and brilliant as it can easily take down all the concerns raised above. Constant folding will surely eliminate range checks of rearrange operations as the upper bound is surely known statically. Constant shuffle vectors will also allow recognition of slicing patterns with constant shifts. Although it would be much harder to detect variable-shift slice operations, that is less of a problem since with more optimal rearrange we can always do a general shuffle with just some extra instructions and no range checks. Constant vectors also allow backend matcher to emit more efficient codes since it can recognize that look-up tables are just a broadcast of 128-bit lanes and reduce 5 expensive instructions including a memory load with a single instruction. For constant vectors, the situation is very different from a scalar value. While a scalar can be materialized in at most 2 instructions with no memory load for floating points and often less than 1 with integers, materializing a vector may be really expensive both regarding execution time and code size, and keeping the vector around increases register pressure. So it is a trade-off and best left to the developers to decide, most of the time they will hoist the calculation out of the loop themselves and if they decide to put the calculation inside a loop there may be a real reason to do so. Given Vector API is a very low-level API, I think it is more suitable to make the API optimizable upon dedication rather than optimized-ish in general cases. And a more predictable result would be more welcome than some ad-hoc magic. Your wonderful document has a lot of ideas, I just want to add that you don't need to involve memory to replicate a compress operation as you can compute the cumulative sum of the not of the mask then subtract that from a iota index vector to achieve a shuffle index vector. Thank you very much, Quan Anh On Mon, 21 Feb 2022 at 10:27, John Rose wrote: > This is a very helpful case study. > > In a recent presentation I put forward UTF8 parsing > as an important challenge problem, exercising segmented > expansion. This current experiment could be an exploratory > step in that direction. > > http://cr.openjdk.java.net/~jrose/pres/202202-VectorTopics.pdf > > (You message is timely; I have placed a link to it on my page 23, > and adjusted a few points there to reflect our exchange here.) > > It is sad that you didn?t/couldn?t use the slice method directly, > but used the SLICE_4 constant permutation. That?s worth fixing. > If there is a ?boundary condition? that slice doesn?t handle > right we should address that too. By boundary condition I mean > a special case in a nearest neighbor computation at an end of the > vector where there?s no neighbor, but just the ?cliff? at the end. > In general, I think the Vector API might possibly be friendlier > to boundary conditions, but I think we have to discover this by > experience. One area that will push this experience further is > adopting multi-vectors, which have more interior, but require > clear and explicit processing at their ends, in many use cases. > (See p. 9ff.) > > Ideally, the optimizer should be able to ?see through? a computed > permutation (including the fromOp index expression) and use > either a constant-folded permutation vector, or an ad hoc cross > lane motion instruction (there are very many in both AVX and SVE). > That would cover slice. Of course, we could also try to make > slice have it?s own little intrinsic ?silo? but that has less of > a payoff. > > You observe that the range checks in the LUT lookups add 15% > and propose just removing them or incorporating wrap logic. > There is another more ?Java-like? way out of the problem, which > is to have the optimizer reason about the range-values of the > index lanes and omit the range check if the index lanes are > already provably in range. That is the case in your code, > since before every selectFrom operation you first do a > lanewise AND with a nibble mask (0x0F or 0x00 all lanes). > The optimizer should be tracking something like TypeInt > range information on these lanes, I think, or perhaps > compute a bitwise support mask for every vector. Using > a rearrange or select where the indexes are already in > range should not be penalized with a dynamic check. > Given logic like the above, a new rearrangeWithWrap > function is not so much needed, since a user can code > equivalent functionality with an explicit wrap operation, > which is then treated like the AND above. > > In your code you have explicit copes from constant > vectors to ?live? vector registers in the loop: > > var hi2Lut = HI2_LUT.lanewise(VectorOperators.XOR, 0); > > It is a bug in the optimizer if it requires these in order > to get good performance. > > Your comment about rematerializing simple ones-and-zeroes on the > fly in the loop is a good one. The optimizer can do that stuff > with scalar constants but we are not (I think) there yet with > vectors. The same point goes for constant lookup-table (LUT) > bit patterns. It shouldn?t be necessary to ?nudge? the optimizer > to pick them up properly. > > I have a request? > > It would be good if you were to write a version of your code > which is as simple and clear as possible, as if the optimizer > had no bugs but instead was smart about vectors (and their lanes) > as it is about scalars. The reason this would be good is we would > have something to debug the optimizer with, because we would want > to identify the reasons you had to modify your code by hand to > nudge the optimizer to do something it should not need nudging > in order to do. > > Thank you again for this excellent study. > > ? John > > On 20 Feb 2022, at 0:43, Qu?n Anh Mai wrote: > > Hi, > > I have spent this weekend trying to make a UTF-8 validator using the > Vector > API and the look-up algorithm proposed by Keiser and Lemire [1]. The > implementation is straightforward and the result looks good with the > throughput validating twitter.json reaching 9GB/s. For reference, the > throughput of my machine running simdjson [2] is around 20.5GB/s. Using > the > Vector API and tunning the performance, there are some noticeable points I > can come up with > ? > > From mcimadamore at openjdk.java.net Tue Feb 22 14:03:44 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 14:03:44 GMT Subject: [foreign-preview] RFR: 8282061: Improve support for deterministic closure of shared scopes [v10] In-Reply-To: References: Message-ID: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix handshake test (previous test changes were incomplete) ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/643/files - new: https://git.openjdk.java.net/panama-foreign/pull/643/files/a266c779..79bb8a68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=09 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=643&range=08-09 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/643.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/643/head:pull/643 PR: https://git.openjdk.java.net/panama-foreign/pull/643 From jvernee at openjdk.java.net Tue Feb 22 14:05:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 14:05:00 GMT Subject: [foreign-preview] RFR: 8280460: MemorySegment::allocateNative should be tolerant of zero-sized allocation requests In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 13:05:57 GMT, Maurizio Cimadamore wrote: > This patch addresses the issues discussed here: > > https://mail.openjdk.java.net/pipermail/panama-dev/2022-January/016071.html > > And makes `MemorySegment::allocateNative` tolerand of zero-sized allocation requests. After evaluating a number of alternatives, I have decided to do what `ByteBuffer` also does, that is, always compute the size of the allocation as `max(size, 1L)`. > > This means that we always perform some allocation - which works better with alignment constraints (e.g. the address you get back is aligned as per request; this is a corner case, but makes the API more consistent). > > I've tweaked the javadoc to reflect that (and also added some javadoc to `SegmentAllocator` as well), and added a test for various kinds of native segments, created both safely and unsafely. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/650 From jvernee at openjdk.java.net Tue Feb 22 14:12:34 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 14:12:34 GMT Subject: [foreign-preview] RFR: 8276648: Downcall stubs are never freed Message-ID: Hi, The current code adds native invokers (downcall stubs) to a CocurrentHashMap cache, and they stay there until the application exits. This patch replaces that cache with a SoftReferenceCache (brought to the top level from AbstractLinker), which allows at least the values to be evicted when they become unreachable. Those value, which are NativeEntryPoint instances, are also registered with a cleaner, whose cleanup action will free the stub from the code cache. Thanks, Jorn ------------- Commit messages: - Use SoftReferenceCache for NativeEntryPoint and free stubs with a cleaner Changes: https://git.openjdk.java.net/panama-foreign/pull/651/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=651&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276648 Stats: 135 lines in 5 files changed: 88 ins; 35 del; 12 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/651.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/651/head:pull/651 PR: https://git.openjdk.java.net/panama-foreign/pull/651 From mcimadamore at openjdk.java.net Tue Feb 22 14:45:11 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 14:45:11 GMT Subject: [foreign-preview] Integrated: 8280460: MemorySegment::allocateNative should be tolerant of zero-sized allocation requests In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 13:05:57 GMT, Maurizio Cimadamore wrote: > This patch addresses the issues discussed here: > > https://mail.openjdk.java.net/pipermail/panama-dev/2022-January/016071.html > > And makes `MemorySegment::allocateNative` tolerand of zero-sized allocation requests. After evaluating a number of alternatives, I have decided to do what `ByteBuffer` also does, that is, always compute the size of the allocation as `max(size, 1L)`. > > This means that we always perform some allocation - which works better with alignment constraints (e.g. the address you get back is aligned as per request; this is a corner case, but makes the API more consistent). > > I've tweaked the javadoc to reflect that (and also added some javadoc to `SegmentAllocator` as well), and added a test for various kinds of native segments, created both safely and unsafely. This pull request has now been integrated. Changeset: 8403a4df Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/8403a4dfdf3ef0c838edfea5ae36849e77465045 Stats: 37 lines in 6 files changed: 27 ins; 1 del; 9 mod 8280460: MemorySegment::allocateNative should be tolerant of zero-sized allocation requests Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/650 From mcimadamore at openjdk.java.net Tue Feb 22 14:52:13 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 14:52:13 GMT Subject: [foreign-preview] RFR: 8276648: Downcall stubs are never freed In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 14:06:28 GMT, Jorn Vernee wrote: > Hi, > > The current code adds native invokers (downcall stubs) to a CocurrentHashMap cache, and they stay there until the application exits. > > This patch replaces that cache with a SoftReferenceCache (brought to the top level from AbstractLinker), which allows at least the values to be evicted when they become unreachable. > > Those value, which are NativeEntryPoint instances, are also registered with a cleaner, whose cleanup action will free the stub from the code cache. > > Thanks, > Jorn Looks good src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 68: > 66: > 67: CacheKey key = new CacheKey(methodType, abi, Arrays.asList(argMoves), Arrays.asList(returnMoves), needsReturnBuffer); > 68: return INVOKER_CACHE.get(key, k -> { This uses a combination of soft references (cache) and phantom references (cleaner). So, cache entries will be evicted when the NEP is softly reachable - meaning that the GC will clear the entries when under pressure. But the cleaner won't be able to run until the entry is evicted (because the entry has a soft reference to the NEP, and to be phantom-reachable you need NOT to be soft-reachable). Assuming that's what you want, then it looks ok. E.g. the cleaner here will "just" make sure that some action is executed when the entry is evicted. ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/651 From jvernee at openjdk.java.net Tue Feb 22 15:24:21 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 15:24:21 GMT Subject: [foreign-preview] RFR: 8277601: OptimizedEntryBlob should implement preserve_callee_argument_oops Message-ID: Hi, preserve_callee_argument_oops is currently not implemented, but it is also never called in practice. Rather than leaving the implementation empty, or writing an implementation that is never actually called, this patch adds a `ShouldNotReachHere()` to the implementation so that we fail-fast in the case this function starts being called in the future. Thanks, Jorn ------------- Commit messages: - Stub out preserve_callee_argument_oops Changes: https://git.openjdk.java.net/panama-foreign/pull/652/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=652&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277601 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/652.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/652/head:pull/652 PR: https://git.openjdk.java.net/panama-foreign/pull/652 From jvernee at openjdk.java.net Tue Feb 22 15:26:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 15:26:00 GMT Subject: [foreign-preview] RFR: 8276648: Downcall stubs are never freed In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 14:47:35 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> The current code adds native invokers (downcall stubs) to a CocurrentHashMap cache, and they stay there until the application exits. >> >> This patch replaces that cache with a SoftReferenceCache (brought to the top level from AbstractLinker), which allows at least the values to be evicted when they become unreachable. >> >> Those value, which are NativeEntryPoint instances, are also registered with a cleaner, whose cleanup action will free the stub from the code cache. >> >> Thanks, >> Jorn > > src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 68: > >> 66: >> 67: CacheKey key = new CacheKey(methodType, abi, Arrays.asList(argMoves), Arrays.asList(returnMoves), needsReturnBuffer); >> 68: return INVOKER_CACHE.get(key, k -> { > > This uses a combination of soft references (cache) and phantom references (cleaner). So, cache entries will be evicted when the NEP is softly reachable - meaning that the GC will clear the entries when under pressure. But the cleaner won't be able to run until the entry is evicted (because the entry has a soft reference to the NEP, and to be phantom-reachable you need NOT to be soft-reachable). Assuming that's what you want, then it looks ok. E.g. the cleaner here will "just" make sure that some action is executed when the entry is evicted. Yes, that is the intent. We want to keep the downcall stub around until after the NEP is evicted from the cache. The cleanup is just there to make sure the VM stub is freed as well, and it is tied to the reachability of the associated NEP, which is strongly reachable from a downcall method handle. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/651 From mcimadamore at openjdk.java.net Tue Feb 22 15:29:03 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 15:29:03 GMT Subject: [foreign-preview] RFR: 8277601: OptimizedEntryBlob should implement preserve_callee_argument_oops In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 15:19:06 GMT, Jorn Vernee wrote: > Hi, > > preserve_callee_argument_oops is currently not implemented, but it is also never called in practice. > > Rather than leaving the implementation empty, or writing an implementation that is never actually called, this patch adds a `ShouldNotReachHere()` to the implementation so that we fail-fast in the case this function starts being called in the future. > > Thanks, > Jorn Makes sense ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/652 From jvernee at openjdk.java.net Tue Feb 22 16:07:21 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 16:07:21 GMT Subject: [foreign-preview] Integrated: 8276648: Downcall stubs are never freed In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 14:06:28 GMT, Jorn Vernee wrote: > Hi, > > The current code adds native invokers (downcall stubs) to a CocurrentHashMap cache, and they stay there until the application exits. > > This patch replaces that cache with a SoftReferenceCache (brought to the top level from AbstractLinker), which allows at least the values to be evicted when they become unreachable. > > Those value, which are NativeEntryPoint instances, are also registered with a cleaner, whose cleanup action will free the stub from the code cache. > > Thanks, > Jorn This pull request has now been integrated. Changeset: 4115fcbe Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/4115fcbeed5db7073a3b156192e74c2a3df7b768 Stats: 135 lines in 5 files changed: 88 ins; 35 del; 12 mod 8276648: Downcall stubs are never freed Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/651 From jvernee at openjdk.java.net Tue Feb 22 16:08:13 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 16:08:13 GMT Subject: [foreign-preview] Integrated: 8277601: OptimizedEntryBlob should implement preserve_callee_argument_oops In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 15:19:06 GMT, Jorn Vernee wrote: > Hi, > > preserve_callee_argument_oops is currently not implemented, but it is also never called in practice. > > Rather than leaving the implementation empty, or writing an implementation that is never actually called, this patch adds a `ShouldNotReachHere()` to the implementation so that we fail-fast in the case this function starts being called in the future. > > Thanks, > Jorn This pull request has now been integrated. Changeset: 144af9f4 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/144af9f43cd2d6f88b675b8c85e4034e5b9d6695 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8277601: OptimizedEntryBlob should implement preserve_callee_argument_oops Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/652 From anhmdq at gmail.com Tue Feb 22 16:44:33 2022 From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=) Date: Wed, 23 Feb 2022 00:44:33 +0800 Subject: UTF-8 validation using Vector API In-Reply-To: <01ABCEF1-EE22-46ED-95DB-CA8CCF970AAF@oracle.com> References: <01ABCEF1-EE22-46ED-95DB-CA8CCF970AAF@oracle.com> Message-ID: > Your wonderful document has a lot of ideas, I just want to add that you don't need to involve memory to replicate a compress operation as you can compute the cumulative sum of the not of the mask then subtract that from a iota index vector to achieve a shuffle index vector. Silly me messed up this part, please ignore it. Another way (should be correct this time) would be to do a lookup on the value of the mask to find the correct shuffle Thanks a lot, Quan Anh On Mon, 21 Feb 2022 at 10:27, John Rose wrote: > This is a very helpful case study. > > In a recent presentation I put forward UTF8 parsing > as an important challenge problem, exercising segmented > expansion. This current experiment could be an exploratory > step in that direction. > > http://cr.openjdk.java.net/~jrose/pres/202202-VectorTopics.pdf > > (You message is timely; I have placed a link to it on my page 23, > and adjusted a few points there to reflect our exchange here.) > > It is sad that you didn?t/couldn?t use the slice method directly, > but used the SLICE_4 constant permutation. That?s worth fixing. > If there is a ?boundary condition? that slice doesn?t handle > right we should address that too. By boundary condition I mean > a special case in a nearest neighbor computation at an end of the > vector where there?s no neighbor, but just the ?cliff? at the end. > In general, I think the Vector API might possibly be friendlier > to boundary conditions, but I think we have to discover this by > experience. One area that will push this experience further is > adopting multi-vectors, which have more interior, but require > clear and explicit processing at their ends, in many use cases. > (See p. 9ff.) > > Ideally, the optimizer should be able to ?see through? a computed > permutation (including the fromOp index expression) and use > either a constant-folded permutation vector, or an ad hoc cross > lane motion instruction (there are very many in both AVX and SVE). > That would cover slice. Of course, we could also try to make > slice have it?s own little intrinsic ?silo? but that has less of > a payoff. > > You observe that the range checks in the LUT lookups add 15% > and propose just removing them or incorporating wrap logic. > There is another more ?Java-like? way out of the problem, which > is to have the optimizer reason about the range-values of the > index lanes and omit the range check if the index lanes are > already provably in range. That is the case in your code, > since before every selectFrom operation you first do a > lanewise AND with a nibble mask (0x0F or 0x00 all lanes). > The optimizer should be tracking something like TypeInt > range information on these lanes, I think, or perhaps > compute a bitwise support mask for every vector. Using > a rearrange or select where the indexes are already in > range should not be penalized with a dynamic check. > Given logic like the above, a new rearrangeWithWrap > function is not so much needed, since a user can code > equivalent functionality with an explicit wrap operation, > which is then treated like the AND above. > > In your code you have explicit copes from constant > vectors to ?live? vector registers in the loop: > > var hi2Lut = HI2_LUT.lanewise(VectorOperators.XOR, 0); > > It is a bug in the optimizer if it requires these in order > to get good performance. > > Your comment about rematerializing simple ones-and-zeroes on the > fly in the loop is a good one. The optimizer can do that stuff > with scalar constants but we are not (I think) there yet with > vectors. The same point goes for constant lookup-table (LUT) > bit patterns. It shouldn?t be necessary to ?nudge? the optimizer > to pick them up properly. > > I have a request? > > It would be good if you were to write a version of your code > which is as simple and clear as possible, as if the optimizer > had no bugs but instead was smart about vectors (and their lanes) > as it is about scalars. The reason this would be good is we would > have something to debug the optimizer with, because we would want > to identify the reasons you had to modify your code by hand to > nudge the optimizer to do something it should not need nudging > in order to do. > > Thank you again for this excellent study. > > ? John > > On 20 Feb 2022, at 0:43, Qu?n Anh Mai wrote: > > Hi, > > I have spent this weekend trying to make a UTF-8 validator using the > Vector > API and the look-up algorithm proposed by Keiser and Lemire [1]. The > implementation is straightforward and the result looks good with the > throughput validating twitter.json reaching 9GB/s. For reference, the > throughput of my machine running simdjson [2] is around 20.5GB/s. Using > the > Vector API and tunning the performance, there are some noticeable points I > can come up with > ? > > From sundar at openjdk.java.net Tue Feb 22 16:55:33 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 22 Feb 2022 16:55:33 GMT Subject: [foreign-jextract] RFR: 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name Message-ID: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> Missed transforming function typedef parameter names as java safe identifiers. ------------- Commit messages: - 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name Changes: https://git.openjdk.java.net/panama-foreign/pull/653/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=653&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282235 Stats: 51 lines in 3 files changed: 46 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/653.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/653/head:pull/653 PR: https://git.openjdk.java.net/panama-foreign/pull/653 From mcimadamore at openjdk.java.net Tue Feb 22 17:21:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 17:21:01 GMT Subject: [foreign-jextract] RFR: 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name In-Reply-To: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> References: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> Message-ID: On Tue, 22 Feb 2022 16:43:41 GMT, Athijegannathan Sundararajan wrote: > Missed transforming function typedef parameter names as java safe identifiers. src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/FunctionalInterfaceBuilder.java line 72: > 70: name = parameterNames.get().get(i); > 71: } > 72: return name.isEmpty()? "_x" + i : Utils.javaSafeIdentifier(name); Do we do this for regular native functions? e.g. int foo(int abstract); ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/653 From sundar at openjdk.java.net Tue Feb 22 17:33:13 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 22 Feb 2022 17:33:13 GMT Subject: [foreign-jextract] RFR: 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name In-Reply-To: References: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> Message-ID: On Tue, 22 Feb 2022 17:17:34 GMT, Maurizio Cimadamore wrote: >> Missed transforming function typedef parameter names as java safe identifiers. > > src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/FunctionalInterfaceBuilder.java line 72: > >> 70: name = parameterNames.get().get(i); >> 71: } >> 72: return name.isEmpty()? "_x" + i : Utils.javaSafeIdentifier(name); > > Do we do this for regular native functions? > > e.g. > > int foo(int abstract); We already call Utils.javaSafeIdentifier() elsewhere. So this is already taken care of (8262825) ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/653 From mcimadamore at openjdk.java.net Tue Feb 22 17:43:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 17:43:10 GMT Subject: [foreign-jextract] RFR: 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name In-Reply-To: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> References: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> Message-ID: <7RlorEi9eJNGe9_Tp__qssARA2MDggOg1knlEAGHdGw=.0827b473-cdf6-4360-bb59-c9a57a9e04b0@github.com> On Tue, 22 Feb 2022 16:43:41 GMT, Athijegannathan Sundararajan wrote: > Missed transforming function typedef parameter names as java safe identifiers. Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/653 From mcimadamore at openjdk.java.net Tue Feb 22 17:43:13 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Feb 2022 17:43:13 GMT Subject: [foreign-jextract] RFR: 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name In-Reply-To: References: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> Message-ID: On Tue, 22 Feb 2022 17:29:33 GMT, Athijegannathan Sundararajan wrote: >> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/FunctionalInterfaceBuilder.java line 72: >> >>> 70: name = parameterNames.get().get(i); >>> 71: } >>> 72: return name.isEmpty()? "_x" + i : Utils.javaSafeIdentifier(name); >> >> Do we do this for regular native functions? >> >> e.g. >> >> int foo(int abstract); > > We already call Utils.javaSafeIdentifier() elsewhere. So this is already taken care of (8261893) thanks for the explanation ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/653 From sundar at openjdk.java.net Tue Feb 22 17:48:13 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 22 Feb 2022 17:48:13 GMT Subject: [foreign-jextract] Integrated: 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name In-Reply-To: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> References: <1qVXhyxtJinOo1EKW2b6wydHZadxoFyMpHZL7PBN8Dk=.ab92ea71-5093-4c8b-9984-b8e0bcdc8e56@github.com> Message-ID: On Tue, 22 Feb 2022 16:43:41 GMT, Athijegannathan Sundararajan wrote: > Missed transforming function typedef parameter names as java safe identifiers. This pull request has now been integrated. Changeset: 11efb79c Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/11efb79cbb1f44e25e76be4d1d607b27a8dba728 Stats: 51 lines in 3 files changed: 46 ins; 2 del; 3 mod 8282235: jextract crashes when a Java keyword is used in as a function pointer typedef parameter name Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/653 From jvernee at openjdk.java.net Tue Feb 22 18:14:46 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 22 Feb 2022 18:14:46 GMT Subject: [foreign-preview] RFR: 8275648: Linker naming bikeshed Message-ID: Hi, This PR renames several classes, functions, and files in the linker implementation. So far this has been avoided while the implementation was still being worked out. But now that we are moving to preview state, it is time to revisit these names. Roughly speaking, the following name changes are applied: - ProgrammableInvoker -> DowncallLinker - ProgrammableUpcallHandler -> UpcallLinker - 'native invoker' -> 'downcall stub' - 'optimzed upcall stub' -> 'upcall stub' - OptimizedEntryBlob -> UpcallStub - optimized_entry_frame -> upcall_stub_frame Then, some source files in hotspot are also renamed as follows: - universalNativeInvoker* -> downcallLinker* - universalUpcallHandler* -> upcallLinker* - foreign_globals* -> foreignGlobals* (to match existing convention) I've also fixed up some outdated comments. Thanks, Jorn ------------- Commit messages: - Rename everything Changes: https://git.openjdk.java.net/panama-foreign/pull/654/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=654&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275648 Stats: 1511 lines in 75 files changed: 642 ins; 646 del; 223 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/654.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/654/head:pull/654 PR: https://git.openjdk.java.net/panama-foreign/pull/654 From jvernee at openjdk.java.net Wed Feb 23 13:50:27 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 23 Feb 2022 13:50:27 GMT Subject: [foreign-preview] RFR: 8275648: Linker naming bikeshed [v2] In-Reply-To: References: Message-ID: > Hi, > > This PR renames several classes, functions, and files in the linker implementation. So far this has been avoided while the implementation was still being worked out. But now that we are moving to preview state, it is time to revisit these names. > > Roughly speaking, the following name changes are applied: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed upcall stub' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then, some source files in hotspot are also renamed as follows: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > I've also fixed up some outdated comments. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix some indentation + remove old comment ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/654/files - new: https://git.openjdk.java.net/panama-foreign/pull/654/files/c8aceece..dc3e0d2b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=654&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=654&range=00-01 Stats: 15 lines in 4 files changed: 0 ins; 6 del; 9 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/654.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/654/head:pull/654 PR: https://git.openjdk.java.net/panama-foreign/pull/654 From mcimadamore at openjdk.java.net Wed Feb 23 15:19:16 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 23 Feb 2022 15:19:16 GMT Subject: [foreign-preview] RFR: 8275648: Linker naming bikeshed [v2] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 13:50:27 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR renames several classes, functions, and files in the linker implementation. So far this has been avoided while the implementation was still being worked out. But now that we are moving to preview state, it is time to revisit these names. >> >> Roughly speaking, the following name changes are applied: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed upcall stub' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then, some source files in hotspot are also renamed as follows: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> I've also fixed up some outdated comments. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fix some indentation + remove old comment Looks good - one suspicious reference to PUH (see comment) src/hotspot/share/prims/upcallLinker.cpp line 131: > 129: } > 130: > 131: JVM_ENTRY(jlong, PUH_MakeUpcallStub(JNIEnv *env, jclass unused, jobject mh, jobject abi, jobject conv, Isn't PUH a leftover of ProgrammableUpcallHandler? (here and elsewhere in this file) ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/654 From jvernee at openjdk.java.net Wed Feb 23 15:44:18 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 23 Feb 2022 15:44:18 GMT Subject: [foreign-preview] RFR: 8275648: Linker naming bikeshed [v3] In-Reply-To: References: Message-ID: <66KJDzIglo36lRASdXB9jqO_Lx3j1Xvt4hyVvYffT8s=.2981081e-6d03-49b4-8f6b-10a287d29a49@github.com> > Hi, > > This PR renames several classes, functions, and files in the linker implementation. So far this has been avoided while the implementation was still being worked out. But now that we are moving to preview state, it is time to revisit these names. > > Roughly speaking, the following name changes are applied: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed upcall stub' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then, some source files in hotspot are also renamed as follows: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > I've also fixed up some outdated comments. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: PUH -> UL ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/654/files - new: https://git.openjdk.java.net/panama-foreign/pull/654/files/dc3e0d2b..9c94e202 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=654&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=654&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/654.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/654/head:pull/654 PR: https://git.openjdk.java.net/panama-foreign/pull/654 From jvernee at openjdk.java.net Wed Feb 23 15:44:21 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 23 Feb 2022 15:44:21 GMT Subject: [foreign-preview] RFR: 8275648: Linker naming bikeshed [v2] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 15:13:37 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix some indentation + remove old comment > > src/hotspot/share/prims/upcallLinker.cpp line 131: > >> 129: } >> 130: >> 131: JVM_ENTRY(jlong, PUH_MakeUpcallStub(JNIEnv *env, jclass unused, jobject mh, jobject abi, jobject conv, > > Isn't PUH a leftover of ProgrammableUpcallHandler? (here and elsewhere in this file) Right, good catch! ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/654 From mcimadamore at openjdk.java.net Wed Feb 23 16:41:12 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 23 Feb 2022 16:41:12 GMT Subject: [foreign-preview] RFR: 8275648: Linker naming bikeshed [v3] In-Reply-To: <66KJDzIglo36lRASdXB9jqO_Lx3j1Xvt4hyVvYffT8s=.2981081e-6d03-49b4-8f6b-10a287d29a49@github.com> References: <66KJDzIglo36lRASdXB9jqO_Lx3j1Xvt4hyVvYffT8s=.2981081e-6d03-49b4-8f6b-10a287d29a49@github.com> Message-ID: <74vM1XQoJ0lRYbkUYGjbiqwvcXQdy-oCxvSyeW_pWtw=.ad42ca15-c5cd-47db-b267-42e5f03784da@github.com> On Wed, 23 Feb 2022 15:44:18 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR renames several classes, functions, and files in the linker implementation. So far this has been avoided while the implementation was still being worked out. But now that we are moving to preview state, it is time to revisit these names. >> >> Roughly speaking, the following name changes are applied: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed upcall stub' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then, some source files in hotspot are also renamed as follows: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> I've also fixed up some outdated comments. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > PUH -> UL All good on Linux. ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/654 From jvernee at openjdk.java.net Wed Feb 23 16:55:08 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 23 Feb 2022 16:55:08 GMT Subject: [foreign-preview] Integrated: 8275648: Linker naming bikeshed In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 18:05:33 GMT, Jorn Vernee wrote: > Hi, > > This PR renames several classes, functions, and files in the linker implementation. So far this has been avoided while the implementation was still being worked out. But now that we are moving to preview state, it is time to revisit these names. > > Roughly speaking, the following name changes are applied: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed upcall stub' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then, some source files in hotspot are also renamed as follows: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > I've also fixed up some outdated comments. > > Thanks, > Jorn This pull request has now been integrated. Changeset: b1b2bcd2 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/b1b2bcd20743521dd0227534e420e121c85afb1f Stats: 2181 lines in 76 files changed: 979 ins; 989 del; 213 mod 8275648: Linker naming bikeshed Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/654 From john.r.rose at oracle.com Wed Feb 23 17:07:11 2022 From: john.r.rose at oracle.com (John Rose) Date: Wed, 23 Feb 2022 09:07:11 -0800 Subject: [External] : Re: UTF-8 validation using Vector API In-Reply-To: References: <01ABCEF1-EE22-46ED-95DB-CA8CCF970AAF@oracle.com> Message-ID: It?s easy to confuse compress-like operations with expand-like operations, or (as I said in the doc) ?pushing? vs. ?pulling? reordering. I think both hardware designers and programmers assume that, given a fully general ?pulling? primitive (shuffle/permute using index vector) it must be just a quick step to the other kind of operation. But in fact, although the hardware design is doable either way, the software design is hard in one direction, if the primitives are missing. Which they are. Specifically, I like to characterize the ?missing primitive? (the one that ?pushes? values based on associated indexes or keys or mask bits) as a kind ?sort?, and note that the standard shuffle/permute operation is just the inverse, which you could call ?unsort? to make the difference clear. On hardware which supports a native ?compress? operation driven by an associated mask, you basically get a one-bit sort key (and have to do it twice); from there you can build up more complex sort algorithms by picking masks based on comparisons to pivots. But I hope some day hardware designers will take a second look at ?compress? and consider steering it using a parallel vector/array of key values, rather than a series of mask bits. Your suggestion of treating the mask as an index into a table of permutation vectors is a good one, though it doesn?t scale well. There are ways to partition the mask and do block-wise compresses using table lookup, and then fix the problem by merging the separately sorted blocks. This is the hallmark of (all?) sort algorithms: You can subdivide the problem, but then there?s always a residual merge to recombine the subdivided parts. On 22 Feb 2022, at 8:44, Qu?n Anh Mai wrote: >> Your wonderful document has a lot of ideas, I just want to add that you > don't need to involve memory to replicate a compress operation as you can > compute the cumulative sum of the not of the mask then subtract that from a > iota index vector to achieve a shuffle index vector. > > Silly me messed up this part, please ignore it. Another way (should be > correct this time) would be to do a lookup on the value of the mask to find > the correct shuffle > From jbhateja at openjdk.java.net Wed Feb 23 19:55:31 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 23 Feb 2022 19:55:31 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master Message-ID: Rebasing vectorIntrinsics to latest mainline. Thanks, Jatin ------------- Commit messages: - Merge branch 'master' of http://github.com/openjdk/panama-vector into merge_master - 8282309: Operation before upper case conversion - 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() - 8281217: Source file launch with security manager enabled fails - 8281376: Consider polymorphic methods when looking for overrides - 8282279: Interpret case-insensitive string locale independently - 8282208: Reduce MachNode size - 8282225: GHA: Allow one concurrent run per PR only - 8255577: Possible issues with SR_initialize - 8282194: C1: Missing side effects of dynamic constant linkage - ... and 624 more: https://git.openjdk.java.net/panama-vector/compare/0ad2b19f...356b868d The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=174&range=00.0 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=174&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/174/files Stats: 66611 lines in 1946 files changed: 45939 ins; 11591 del; 9081 mod Patch: https://git.openjdk.java.net/panama-vector/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/174/head:pull/174 PR: https://git.openjdk.java.net/panama-vector/pull/174 From sviswanathan at openjdk.java.net Wed Feb 23 21:49:07 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 23 Feb 2022 21:49:07 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 19:47:13 GMT, Jatin Bhateja wrote: > Rebasing vectorIntrinsics to latest mainline. > > Thanks, > Jatin Marked as reviewed by sviswanathan (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/174 From jbhateja at openjdk.java.net Thu Feb 24 02:15:03 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 24 Feb 2022 02:15:03 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2] In-Reply-To: References: Message-ID: > Rebasing vectorIntrinsics to latest mainline. > > Thanks, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 801 commits: - Merge branch 'master' of http://github.com/openjdk/panama-vector into merge_master - 8281562:[vectorapi] Add support for popcount operation Reviewed-by: sviswanathan, psandoz - 8278468: AArch64: [vectorapi] SVE backend support for CompressM and CompressV(B/H) Reviewed-by: njian - Merge panama-vector:master Reviewed-by: jbhateja - Merge panama-vector:master Reviewed-by: njian - Update asmtest.out.h due to incorrect merge Reviewed-by: eliu - Merge panama-vector:vectorIntrinsics+compress Reviewed-by: jbhateja - Compress JavaDoc. Reviewed-by: sviswanathan - Merge panama-vector:vectorIntrinsics Reviewed-by: eliu - 8276083: Incremental patch to further optimize new compress/expand APIs over X86 Reviewed-by: psandoz - ... and 791 more: https://git.openjdk.java.net/panama-vector/compare/7dc7184c...356b868d ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/174/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=174&range=01 Stats: 78282 lines in 198 files changed: 78221 ins; 33 del; 28 mod Patch: https://git.openjdk.java.net/panama-vector/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/174/head:pull/174 PR: https://git.openjdk.java.net/panama-vector/pull/174 From jbhateja at openjdk.java.net Thu Feb 24 02:15:05 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 24 Feb 2022 02:15:05 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 19:47:13 GMT, Jatin Bhateja wrote: > Rebasing vectorIntrinsics to latest mainline. > > Thanks, > Jatin This pull request has now been integrated. Changeset: 5ed82025 Author: Jatin Bhateja URL: https://git.openjdk.java.net/panama-vector/commit/5ed820253f1ea82c7996d76d5e9c9592f24161b7 Stats: 66611 lines in 1946 files changed: 45939 ins; 11591 del; 9081 mod Merge panama-vector:master Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/174 From jboes at openjdk.java.net Thu Feb 24 11:20:03 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 24 Feb 2022 11:20:03 GMT Subject: [foreign-preview] RFR: 8282210: Relax policy for restricted method invocation Message-ID: This change adapts the policy for restricted method invocation, which is controlled via the --enable-native-access flag. As a transitional mode, access to restricted methods is allowed when the flag is not specified, with a runtime warning being omitted on first invocation. This mode supports applications and use cases where the flag cannot easily be specified. The behaviour for when the flag is specified remains unchanged. ------------- Commit messages: - Merge remote-tracking branch 'origin/warn-native-access' into warn-native-access - refactor module check and adapt test - account for unnamed module - update warning output - incorporate existing test - Merge branch 'foreign-preview' into warn-native-access - refactor test - Merge branch 'foreign-preview' into warn-native-access - add test and implementation change - Merge branch 'foreign-preview' into warn-native-access - ... and 5 more: https://git.openjdk.java.net/panama-foreign/compare/a225c6e3...70cf305a Changes: https://git.openjdk.java.net/panama-foreign/pull/655/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282210 Stats: 658 lines in 16 files changed: 356 ins; 246 del; 56 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/655.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/655/head:pull/655 PR: https://git.openjdk.java.net/panama-foreign/pull/655 From jvernee at openjdk.java.net Thu Feb 24 12:18:30 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Feb 2022 12:18:30 GMT Subject: [foreign-preview] RFR: 8282210: Relax policy for restricted method invocation In-Reply-To: References: Message-ID: <1cWBfCXWXpk1Q0mT8iJinvXod9C6zdSTgY0sm8gUtCk=.e59ed1c9-b7bd-4825-9c62-97114414a9dd@github.com> On Thu, 24 Feb 2022 11:13:57 GMT, Julia Boes wrote: > This change adapts the policy for restricted method invocation, which is controlled via the --enable-native-access flag. > > As a transitional mode, access to restricted methods is allowed when the flag is not specified, with a runtime warning being omitted on first invocation. This mode supports applications and use cases where the flag cannot easily be specified. > > The behaviour for when the flag is specified remains unchanged. Nice test! One minor comment inline. test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccess.java line 182: > 180: .outputTo(System.out) > 181: .errorTo(System.out); > 182: if (expectedResult != null) I don't see how `expectedResult` could be `null` here? If it is `null` unexpectedly, I think it would be better to fail here (to avoid false-positives). ------------- Marked as reviewed by jvernee (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/655 From jboes at openjdk.java.net Thu Feb 24 14:03:16 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 24 Feb 2022 14:03:16 GMT Subject: [foreign-preview] RFR: 8282210: Relax policy for restricted method invocation [v2] In-Reply-To: <1cWBfCXWXpk1Q0mT8iJinvXod9C6zdSTgY0sm8gUtCk=.e59ed1c9-b7bd-4825-9c62-97114414a9dd@github.com> References: <1cWBfCXWXpk1Q0mT8iJinvXod9C6zdSTgY0sm8gUtCk=.e59ed1c9-b7bd-4825-9c62-97114414a9dd@github.com> Message-ID: <8ieg0lzf3XWdaxxMR9X5072xwQxCu9hd31Kj9v3fs4I=.d66a4c5a-2126-4032-8823-50f3296b9027@github.com> On Thu, 24 Feb 2022 12:15:08 GMT, Jorn Vernee wrote: > Nice test! One minor comment inline. The test is based on the JDK 15 version of `tools/launcher/modules/illegalaccess/IllegalAccessTest.java`, Maurizio pointed me to it. > test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccess.java line 182: > >> 180: .outputTo(System.out) >> 181: .errorTo(System.out); >> 182: if (expectedResult != null) > > I don't see how `expectedResult` could be `null` here? If it is `null` unexpectedly, I think it would be better to fail here (to avoid false-positives). Good point, I think it's safe to drop the null check as we don't pass null as `expectedResult` anywhere. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/655 From jboes at openjdk.java.net Thu Feb 24 14:03:16 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 24 Feb 2022 14:03:16 GMT Subject: [foreign-preview] RFR: 8282210: Relax policy for restricted method invocation [v2] In-Reply-To: References: Message-ID: > This change adapts the policy for restricted method invocation, which is controlled via the --enable-native-access flag. > > As a transitional mode, access to restricted methods is allowed when the flag is not specified, with a runtime warning being omitted on first invocation. This mode supports applications and use cases where the flag cannot easily be specified. > > The behaviour for when the flag is specified remains unchanged. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: address PR comment and cleanup test ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/655/files - new: https://git.openjdk.java.net/panama-foreign/pull/655/files/70cf305a..00ebf4cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=655&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=655&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/655.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/655/head:pull/655 PR: https://git.openjdk.java.net/panama-foreign/pull/655 From jvernee at openjdk.java.net Thu Feb 24 15:53:32 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Feb 2022 15:53:32 GMT Subject: [foreign-preview] RFR: 8282210: Relax policy for restricted method invocation [v2] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 14:03:16 GMT, Julia Boes wrote: >> This change adapts the policy for restricted method invocation, which is controlled via the --enable-native-access flag. >> >> As a transitional mode, access to restricted methods is allowed when the flag is not specified, with a runtime warning being omitted on first invocation. This mode supports applications and use cases where the flag cannot easily be specified. >> >> The behaviour for when the flag is specified remains unchanged. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comment and cleanup test Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/655 From chegar at openjdk.java.net Thu Feb 24 23:20:32 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 24 Feb 2022 23:20:32 GMT Subject: [foreign-preview] RFR: 8282210: Relax policy for restricted method invocation [v2] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 14:03:16 GMT, Julia Boes wrote: >> This change adapts the policy for restricted method invocation, which is controlled via the --enable-native-access flag. >> >> As a transitional mode, access to restricted methods is allowed when the flag is not specified, with a runtime warning being omitted on first invocation. This mode supports applications and use cases where the flag cannot easily be specified. >> >> The behaviour for when the flag is specified remains unchanged. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comment and cleanup test LGTM ------------- Marked as reviewed by chegar (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/655 From sundar at openjdk.java.net Fri Feb 25 00:24:23 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 25 Feb 2022 00:24:23 GMT Subject: [foreign-preview] RFR: 8282210: Relax policy for restricted method invocation [v2] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 14:03:16 GMT, Julia Boes wrote: >> This change adapts the policy for restricted method invocation, which is controlled via the --enable-native-access flag. >> >> As a transitional mode, access to restricted methods is allowed when the flag is not specified, with a runtime warning being omitted on first invocation. This mode supports applications and use cases where the flag cannot easily be specified. >> >> The behaviour for when the flag is specified remains unchanged. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > address PR comment and cleanup test LGTM ------------- Marked as reviewed by sundar (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/655 From jboes at openjdk.java.net Fri Feb 25 08:26:34 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 25 Feb 2022 08:26:34 GMT Subject: [foreign-preview] Integrated: 8282210: Relax policy for restricted method invocation In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 11:13:57 GMT, Julia Boes wrote: > This change adapts the policy for restricted method invocation, which is controlled via the --enable-native-access flag. > > As a transitional mode, access to restricted methods is allowed when the flag is not specified, with a runtime warning being omitted on first invocation. This mode supports applications and use cases where the flag cannot easily be specified. > > The behaviour for when the flag is specified remains unchanged. This pull request has now been integrated. Changeset: 9247f980 Author: Julia Boes URL: https://git.openjdk.java.net/panama-foreign/commit/9247f9808dba0fdc23d300e6340a5c06ba3aa9ff Stats: 653 lines in 16 files changed: 351 ins; 246 del; 56 mod 8282210: Relax policy for restricted method invocation Reviewed-by: jvernee, chegar, sundar ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/655 From duke at openjdk.java.net Fri Feb 25 11:17:02 2022 From: duke at openjdk.java.net (duke) Date: Fri, 25 Feb 2022 11:17:02 GMT Subject: git: openjdk/panama-foreign: master: 68 new changesets Message-ID: <6de49a4c-7375-470b-9122-9071edcf9370@openjdk.org> Changeset: e3365041 Author: Jan Lahoda Date: 2022-02-18 11:04:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3365041bdef4dc09f3e5967124103e4364614fb 8280866: SuppressWarnings does not work properly in package-info and module-info Reviewed-by: darcy, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java + test/langtools/tools/javac/warnings/suppress/SuppressWarningsPackage.java Changeset: f5120b76 Author: Pavel Rappo Date: 2022-02-18 13:09:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5120b764c6f84776e7ea335d7ff59b16f6496b0 8282056: Clean up com.sun.tools.javac.util.GraphUtils Reviewed-by: jjg, mcimadamore, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java Changeset: cf6984dd Author: Magnus Ihse Bursie Date: 2022-02-18 14:49:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf6984ddaa5668e78d590c8ad1f2aec0632f0b28 8282086: Update jib profile to not set build to 0 Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 413bef68 Author: Dmitry Chuyko Date: 2022-02-18 16:02:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/413bef6890e9ba820590aa48017c4c7b1d691d24 8282049: AArch64: Use ZR for integer zero immediate volatile stores Reviewed-by: adinn, phh ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: cfbfd9bf Author: Daniel D. Daugherty Date: 2022-02-18 16:25:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cfbfd9bf4123452e8bcff0ef7fbc18b14be8638c 8282103: fix macosx-generic typo in ProblemList Reviewed-by: rriggs ! test/hotspot/jtreg/ProblemList.txt Changeset: 7ce75afb Author: Weijun Wang Date: 2022-02-18 16:34:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ce75afbbcca7635356c7377be7ddff15335e563 8255266: Update Public Suffix List to 3c213aa Reviewed-by: xuelei ! make/data/publicsuffixlist/VERSION ! make/data/publicsuffixlist/public_suffix_list.dat ! src/java.base/share/legal/public_suffix.md ! test/jdk/sun/security/util/RegisteredDomain/ParseNames.java ! test/jdk/sun/security/util/RegisteredDomain/tests.dat Changeset: 3943c89b Author: Yudi Zheng Committer: Vladimir Kozlov Date: 2022-02-18 18:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3943c89b9b71d8c1fda3ba88fd833f08723202f0 8282044: [JVMCI] Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler. Reviewed-by: kvn ! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: d3749de4 Author: Rajan Halade Date: 2022-02-18 20:17:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d3749de47832c6de4bcee9cf64a0b698e796b2f2 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022 Reviewed-by: weijun ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: d7f31d0d Author: Valerie Peng Date: 2022-02-19 06:40:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7f31d0d53bfec627edc83ceb75fc6202891e186 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error Reviewed-by: mikael ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c Changeset: d28b048f Author: Aleksey Shipilev Date: 2022-02-21 06:14:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d28b048f35d5893187076e853a4a898d5ca8b220 8281815: x86: Use short jumps in TIG::generate_slow_signature_handler Reviewed-by: rrich, dholmes, jiefu ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp Changeset: 8563d86f Author: Tobias Hartmann Date: 2022-02-21 07:02:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8563d86f2cce0dc9d1411bf9276a00bca0515efd 8282085: The REGISTER_DEFINITION macro is useless after JDK-8269122 Reviewed-by: jiefu, chagedorn, kvn - src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp - src/hotspot/cpu/arm/register_definitions_arm.cpp - src/hotspot/cpu/ppc/register_definitions_ppc.cpp - src/hotspot/cpu/s390/register_definitions_s390.cpp - src/hotspot/cpu/x86/register_definitions_x86.cpp ! src/hotspot/share/asm/register.hpp Changeset: 4e0b81c5 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-21 07:05:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 8281544: assert(VM_Version::supports_avx512bw()) failed for Tests jdk/incubator/vector/ Reviewed-by: kvn, neliasso, thartmann ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp ! test/jdk/jdk/incubator/vector/VectorMaxConversionTests.java Changeset: 52a85d80 Author: John Jiang Date: 2022-02-21 07:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52a85d80483f7fefbe26bed6fe3a2ce4bd1bc9fc 8282158: ECParameters InvalidParameterSpecException messages missed ECKeySizeParameterSpec Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/util/ECParameters.java Changeset: c5d9142a Author: Albert Mingkun Yang Date: 2022-02-21 08:14:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5d9142a8466fe00819afb76ebe68dc59061613e 8282096: G1: Remove redundant checks in G1CardSet::free_mem_object Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1CardSet.cpp Changeset: 34aae32d Author: John Jiang Date: 2022-02-21 08:27:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/34aae32de6c1eeaf268d62f20152f831cca5cd29 8282166: JDK-8282158 changed ECParameters' package by accident Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/util/ECParameters.java Changeset: 51f44207 Author: Andrey Turbanov Date: 2022-02-21 09:03:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51f4420711b8cace5733180b3291779f11291895 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers Reviewed-by: bpb, alanb ! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template Changeset: bdae1d87 Author: Manukumar V S Committer: Abdul Kolarkunnu Date: 2022-02-21 10:08:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdae1d87c16423878e4dcc8a0e87806d77bb5256 8282147: [TESTBUG] waitForIdle after creating frame in JSpinnerMouseAndKeyPressTest.java Reviewed-by: aivanov ! test/jdk/javax/swing/JSpinner/4515999/JSpinnerMouseAndKeyPressTest.java Changeset: d7a706a5 Author: Magnus Ihse Bursie Date: 2022-02-21 10:37:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7a706a54076109b1a600a4d963df54b6d3f86de 8253757: Add LLVM-based backend for hsdis Co-authored-by: Magnus Ihse Bursie Co-authored-by: Ludovic Henry Co-authored-by: Jorn Vernee Co-authored-by: Nick Gasson Reviewed-by: erikj, luhenry ! make/Hsdis.gmk ! make/autoconf/jdk-options.m4 ! src/utils/hsdis/README.md + src/utils/hsdis/llvm/hsdis-llvm.cpp Changeset: cc7cf812 Author: Maxim Kartashev Committer: Anton Tarasov Date: 2022-02-21 11:39:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a 8280861: Robot color picker broken on Linux with scaling above 100% Reviewed-by: serb ! src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.h ! test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java + test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java ! test/jdk/javax/swing/JPasswordField/TestSelectedTextBackgroundColor.java ! test/jdk/javax/swing/JProgressBar/TestJProgressBarHighlightColor.java ! test/jdk/javax/swing/JSlider/TestJSliderRendering.java ! test/jdk/javax/swing/JSpinner/TestSelectedTextBackgroundColor.java ! test/jdk/javax/swing/JTextPane/TestJTextPaneBackgroundColor.java ! test/jdk/javax/swing/JToolTip/TestTooltipBackgroundColor.java Changeset: e1c98bd1 Author: Daniel Jeli?ski Committer: Alexey Ivanov Date: 2022-02-21 17:40:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1c98bd1f2f57ddf47e4660038059117af87f938 8281523: Accessibility: Conversion from string literal loses const qualifier Reviewed-by: prr, aivanov, kizune ! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp ! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.h ! src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeEventHandler.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeJavaVMInstance.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeMessageQueue.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp ! src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp ! src/jdk.accessibility/windows/native/toolscommon/AccessInfo.h Changeset: e0b49629 Author: Jaikiran Pai Date: 2022-02-22 01:39:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0b49629e95c98aabe8b75ec2f7528e7fb6dcffc 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle Reviewed-by: dfuchs, rriggs, lancea, iris ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java Changeset: f9539521 Author: Manukumar V S Committer: Abdul Kolarkunnu Date: 2022-02-22 07:31:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9539521aee71e84cb052d3d0444c58ee88930f7 8281745: Create a regression test for JDK-4514331 Reviewed-by: serb + test/jdk/javax/swing/JTextArea/4514331/TabShiftsFocusToNextComponent.java Changeset: bc43320f Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-22 07:55:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc43320fd32debf863f37dc00ef7b95589f576ed 8281543: Remove unused code/headerfile dtraceAttacher.hpp Reviewed-by: thartmann ! src/hotspot/os/aix/attachListener_aix.cpp ! src/hotspot/os/bsd/attachListener_bsd.cpp ! src/hotspot/os/linux/attachListener_linux.cpp ! src/hotspot/os/windows/attachListener_windows.cpp - src/hotspot/share/services/dtraceAttacher.hpp Changeset: b95310b0 Author: John Jiang Date: 2022-02-22 09:35:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b95310b0908037c6743b937ae43d7bc97e1fb770 8282220: contentType should not be a PKCS7's member Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/pkcs/PKCS7.java Changeset: ab6d8e64 Author: Alexey Ivanov Date: 2022-02-22 13:19:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab6d8e6424aa478eb7661d1d38d543cccd38888f 8260328: Drop redundant CSS properties from java.desktop HTML files Reviewed-by: serb, dmarkov ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html Changeset: 022d8070 Author: Coleen Phillimore Date: 2022-02-22 13:42:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/022d80707c346f4b82ac1eb53e77c634769631e9 8271008: appcds/*/MethodHandlesAsCollectorTest.java tests time out because of excessive GC (CodeCache GC Threshold) in loom Reviewed-by: thartmann, eosterlund ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/sweeper.hpp Changeset: 41355e2d Author: Ian Graves Date: 2022-02-22 15:38:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/41355e2daa43fa8433bf77ed187979c49d453f4a 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java Reviewed-by: iris, bpb, lancea ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: e44d0670 Author: Magnus Ihse Bursie Date: 2022-02-22 16:06:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e44d0670a69a641b82a0ca50e06e85d807b473ea 8244593: Clean up GNM/NM after JEP 381 Reviewed-by: erikj ! make/autoconf/compare.sh.in ! make/autoconf/spec.gmk.in ! make/autoconf/toolchain.m4 Changeset: 957dae02 Author: Thomas Schatzl Date: 2022-02-22 16:25:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/957dae02b18b150cab8aec4846bc82086ee1e4da 8280958: G1/Parallel: Unify marking code structure Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp Changeset: 3cb38678 Author: Ian Graves Date: 2022-02-22 16:31:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cb38678aa7f03356421f5a17c1de4156e206d68 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception Reviewed-by: naoto ! src/java.base/share/classes/java/util/regex/Pattern.java ! test/jdk/java/util/regex/RegExTest.java Changeset: 58e1882f Author: Tyler Steele Committer: Naoto Sato Date: 2022-02-22 16:50:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58e1882f3ccc648c5f6d216d37cfd1805889b8d8 8282042: [testbug] FileEncodingTest.java depends on default encoding Adds expected encoding "ISO-8859-1" for AIX in FileEncodingTest.java Reviewed-by: naoto ! test/jdk/java/lang/System/FileEncodingTest.java Changeset: 7feabee4 Author: liach Committer: Mandy Chung Date: 2022-02-22 16:57:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7feabee4265787ea820c1925c0c531933cb0da50 8261407: ReflectionFactory.checkInitted() is not thread-safe Co-authored-by: Peter Levart Reviewed-by: dholmes, mchung, plevart ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java Changeset: 6445ee46 Author: Brian Burkhalter Date: 2022-02-22 17:24:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6445ee46b5c3d1a46f8154b6e867c25d495d76b1 5041655: (ch) FileLock: negative param and overflow issues Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/java.base/share/classes/java/nio/channels/FileChannel.java ! src/java.base/share/classes/java/nio/channels/FileLock.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/jdk/java/nio/channels/FileChannel/Lock.java + test/jdk/java/nio/channels/FileLock/Overlaps.java Changeset: 2557ef8a Author: Phil Race Date: 2022-02-22 20:27:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2557ef8a02fe19784bd5e605b11d6bd574cde2c2 8282276: Problem list failing two Robot Screen Capture tests Reviewed-by: dcubed ! test/jdk/ProblemList.txt Changeset: 6f882ded Author: Phil Race Date: 2022-02-23 01:03:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f882deddcc094777b45f0dacc7351dbc23993a4 8280964: [Linux aarch64] : drawImage dithers TYPE_BYTE_INDEXED images incorrectly Reviewed-by: serb, dmarkov ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.c ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.h ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/loops/ByteIndexed.h ! src/java.desktop/share/native/libawt/java2d/loops/UshortIndexed.h ! src/java.desktop/unix/native/common/awt/colordata.h ! src/java.desktop/windows/native/libawt/windows/colordata.h + test/jdk/java/awt/image/DrawImage/ByteIndexedDitherTest.java Changeset: e1060bee Author: Zhengyu Gu Date: 2022-02-23 03:04:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1060bee2adb9f2e07ca09309d0f89132db30f28 8281615: Deadlock caused by jdwp agent Reviewed-by: dholmes, cjplummer ! src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c Changeset: 378fa507 Author: Volker Simonis Date: 2022-02-23 08:36:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/378fa507a29f382e5534226612e154a37618ab91 8281962: Avoid unnecessary native calls in InflaterInputStream Reviewed-by: clanger, redestad, alanb, lancea ! src/java.base/share/classes/java/util/zip/InflaterInputStream.java + test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java Changeset: ecd85e6f Author: Andrew Haley Date: 2022-02-23 10:15:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ecd85e6f0f8906ad1e8aa0a53bf499e8c969ba73 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts registers Reviewed-by: shade, jiefu ! src/hotspot/cpu/x86/x86_32.ad Changeset: 93320717 Author: Vladimir Ivanov Date: 2022-02-23 10:17:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9332071784b7150512f7e27b07c290a356d43c2e 8282194: C1: Missing side effects of dynamic constant linkage Reviewed-by: kvn, thartmann ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_ValueMap.hpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciStreams.hpp Changeset: d017e988 Author: David Holmes Date: 2022-02-23 11:30:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d017e988562999295315778e232d71e477afb407 8255577: Possible issues with SR_initialize Reviewed-by: shade, stuefe ! src/hotspot/os/posix/signals_posix.cpp Changeset: aaab2cb4 Author: Aleksey Shipilev Date: 2022-02-23 12:34:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aaab2cb41666af8520fd01de70e2c4f9c87ef5fd 8282225: GHA: Allow one concurrent run per PR only Reviewed-by: ihse ! .github/workflows/submit.yml Changeset: 5035bf5e Author: Nils Eliasson Date: 2022-02-23 12:48:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5035bf5e6cb0ae2892e128b9a7c4014d01addb26 8282208: Reduce MachNode size Reviewed-by: kvn, thartmann, jiefu ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/node.hpp Changeset: 340a35d8 Author: Xue-Lei Andrew Fan Date: 2022-02-23 15:43:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/340a35d8358456620954ae0c668cf3d1d617bb88 8282279: Interpret case-insensitive string locale independently Reviewed-by: weijun ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java ! src/java.base/share/classes/sun/security/util/TlsChannelBinding.java Changeset: 35076af1 Author: Pavel Rappo Date: 2022-02-23 16:17:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35076af13acd1b9327d35ac67dc80c15bb1059c7 8281376: Consider polymorphic methods when looking for overrides Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java + test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg8/C.java + test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg8/GP.java + test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg8/P.java Changeset: 99b8ed9d Author: Jonathan Gibbons Date: 2022-02-23 16:49:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99b8ed9dbf88e21a42a8d2f6249bfab7176e7d42 8281217: Source file launch with security manager enabled fails Reviewed-by: sundar ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: a020b6ba Author: Lance Andersen Date: 2022-02-23 16:56:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a020b6ba8f38fe85fb26972a51e4c1068408b1c1 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() Reviewed-by: mullan, alanb ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/zip/ZipFile.java + test/jdk/java/util/zip/ZipFile/GetInputStreamNPETest.java Changeset: 7dc7184c Author: Xue-Lei Andrew Fan Date: 2022-02-23 18:32:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7dc7184c10fc8f7a02113056da979a9846a14cd4 8282309: Operation before upper case conversion Reviewed-by: valeriep, wetmore ! src/java.base/share/classes/sun/security/util/TlsChannelBinding.java Changeset: e540e0a8 Author: Michael McMahon Date: 2022-02-23 20:02:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e540e0a81b923cce8b2f2689e01703509a4df1de 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) Reviewed-by: dfuchs, lancea, bpb ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java Changeset: f86f38a8 Author: Vladimir Ivanov Date: 2022-02-23 20:29:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f86f38a8afd31c76039206f8f1f33371ad814396 8280901: MethodHandle::linkToNative stub is missing w/ -Xint Reviewed-by: shade, kvn ! src/hotspot/share/classfile/systemDictionary.cpp ! test/jdk/java/foreign/TestDowncall.java Changeset: 253cf785 Author: Chris Plummer Date: 2022-02-23 21:09:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/253cf7852f60ecf92e6d675ae2469e5f27425609 8282076: Merge some debug agent changes from the loom repo Reviewed-by: amenkov, lmesnik ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ! src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c Changeset: 43dc9ef6 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-23 21:13:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/43dc9ef619b823e033cb1e298bbc091eb5a50967 8281988: Create a regression test for JDK-4618767 Reviewed-by: aivanov + test/jdk/javax/swing/JList/4618767/JListSelectedElementTest.java Changeset: a6610031 Author: Chris Plummer Date: 2022-02-23 22:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6610031e2816156fa14876457e260282a88d478 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr Reviewed-by: dcubed, dholmes ! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java Changeset: cd3e59ef Author: Albert Mingkun Yang Date: 2022-02-24 09:16:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd3e59ef88bcc040f9d671c8c15370efaae3ffd8 8282299: Remove unused PartialArrayScanTask default constructor Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp Changeset: 379fd859 Author: Prasanta Sadhukhan Date: 2022-02-24 09:52:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/379fd85932e4b82e9a8e85f8ed8e63202f3cb9bc 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT orientation, arrow keys behaves opposite traversing through keyboard Reviewed-by: prr, naoto, serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java + test/jdk/javax/swing/JMenuBar/MenuBarRTLBug.java Changeset: 3cfffa4f Author: Andrey Turbanov Date: 2022-02-24 11:03:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cfffa4f8e5a0fff7f232130125c549f992b533b 8282188: Unused static field MathContext.DEFAULT_DIGITS Reviewed-by: darcy, bpb ! src/java.base/share/classes/java/math/MathContext.java Changeset: f4486a19 Author: Coleen Phillimore Date: 2022-02-24 12:59:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4486a190e38c57b7c10e6cff4622bd1b716a724 8262400: runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails in test_ame5_compiled_vtable_stub with wrapper Reviewed-by: dholmes, lmesnik ! test/hotspot/jtreg/runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java Changeset: 231e48fa Author: Johannes Bechberger Committer: Martin Doerr Date: 2022-02-24 14:32:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/231e48fa63aeb4e35c7c948f958695d62b7157ce 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 Reviewed-by: dholmes, mdoerr, kevinw ! src/hotspot/share/prims/forte.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 0796620b Author: Jonathan Gibbons Date: 2022-02-24 14:50:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0796620b07c6287a130ab0a3a7279d69b5d7b8a1 8281944: JavaDoc throws java.lang.IllegalStateException: ERRONEOUS Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java Changeset: abc0ce11 Author: Xue-Lei Andrew Fan Date: 2022-02-24 16:25:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abc0ce11dfa0a751a12925763cb168d1d3b4f44a 8282316: Operation before String case conversion Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/util/SignatureUtil.java Changeset: 6fab8a2d Author: Alan Hayward Committer: Andrew Dinn Date: 2022-02-24 16:38:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6fab8a2d6a97dbd2ffceca275716d020cb9f1eea 8277204: Implement PAC-RET branch protection on Linux/AArch64 Reviewed-by: erikj, ihse, adinn, ngasson ! doc/building.md ! make/autoconf/flags-cflags.m4 ! make/autoconf/spec.gmk.in ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/pauth_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp ! src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/pauth_linux_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/pauth_windows_aarch64.inline.hpp ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/java.base/share/man/java.1 ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src/jdk/vm/ci/aarch64/AArch64.java ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/CodeInstallationTest.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestHotSpotVMConfig.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/aarch64/AArch64TestAssembler.java Changeset: 0b6862e8 Author: Albert Mingkun Yang Date: 2022-02-24 17:47:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b6862e803a03cf7f722f4f58b657712e74723fb 8282348: Remove unused CardTable::dirty_card_iterate Reviewed-by: kbarrett ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp Changeset: 20e78f7a Author: Albert Mingkun Yang Date: 2022-02-24 17:48:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20e78f7a8e2e589bc4fb7f0c928176048bd9172a 8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 23995f82 Author: Daniel Jeli?ski Committer: Daniel Fuchs Date: 2022-02-24 18:18:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23995f822e540d799eb4bbc969229422257fbb08 8281525: Enable Zc:strictStrings flag in Visual Studio build Reviewed-by: dholmes, ihse ! make/autoconf/flags-cflags.m4 ! src/hotspot/os/windows/os_windows.cpp ! src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp ! src/jdk.jpackage/windows/native/libwixhelper/libwixhelper.cpp ! test/hotspot/gtest/runtime/test_os_windows.cpp Changeset: b6843a16 Author: Yi-Fan Tsai Committer: Paul Hohensee Date: 2022-02-24 19:42:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6843a162411b0fa32271592d8f3a6f241a54384 8005885: enhance PrintCodeCache to print more data Reviewed-by: xliu, phh ! src/hotspot/share/code/codeCache.cpp + test/hotspot/jtreg/compiler/codecache/CheckCodeCacheInfo.java Changeset: bf19fc65 Author: Roger Riggs Date: 2022-02-24 20:12:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf19fc65c71cba8cb4383d714fe8993acd01be0a 8280357: user.home = "?" when running with systemd DynamicUser=true Reviewed-by: naoto, alanb ! src/java.base/unix/native/libjava/java_props_md.c Changeset: cd36be42 Author: Kevin Walls Date: 2022-02-25 07:56:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd36be42c2eb3eacdb3625e87510eb15acac3230 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use Reviewed-by: msheppar, amenkov ! test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java Changeset: 3efd6aa4 Author: Claes Redestad Date: 2022-02-25 08:55:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3efd6aa4c9b6420520709281ab1ca46ba4242c87 8282347: AARCH64: Untaken branch in has_negatives stub Reviewed-by: aph, haosun, thartmann ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 7e0ce62c Author: duke Date: 2022-02-25 11:05:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e0ce62cba9dc45534bbdba8bd82ad804cb8b13c Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Feb 25 11:20:46 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 25 Feb 2022 11:20:46 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: <6qGdlRMYPmWgbKJzNCDl1fVhpjvfJDhT9FoYxgAsUuI=.6c43d268-f737-427e-92d9-2d91ad12fca1@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 68 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: The following file contains merge conflicts: - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. # Ensure target branch is up to date $ git checkout foreign-memaccess+abi $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi # Fetch and checkout the branch for this pull request $ git fetch https://github.com/openjdk-bot/panama-foreign.git +115:openjdk-bot-115 $ git checkout openjdk-bot-115 # Merge the target branch $ git merge foreign-memaccess+abi When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: $ git add paths/to/files/with/conflicts $ git commit -m 'Merge master' When you have created the merge commit, run the following command to push the merge commit to this pull request: $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-115:115 _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. Thanks, J. Duke ------------- Commit messages: - Automatic merge of jdk:master into master - 8282347: AARCH64: Untaken branch in has_negatives stub - 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use - 8280357: user.home = "?" when running with systemd DynamicUser=true - 8005885: enhance PrintCodeCache to print more data - 8281525: Enable Zc:strictStrings flag in Visual Studio build - 8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor - 8282348: Remove unused CardTable::dirty_card_iterate - 8277204: Implement PAC-RET branch protection on Linux/AArch64 - 8282316: Operation before String case conversion - ... and 58 more: https://git.openjdk.java.net/panama-foreign/compare/cd3b60d5...7e0ce62c The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=656&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/656/files Stats: 8056 lines in 192 files changed: 5290 ins; 1119 del; 1647 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/656.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/656/head:pull/656 PR: https://git.openjdk.java.net/panama-foreign/pull/656 From duke at openjdk.java.net Fri Feb 25 11:20:59 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 25 Feb 2022 11:20:59 GMT Subject: [foreign-preview] RFR: Merge master Message-ID: <0yIXTzywhdpECgGc16PS0HdRTCeXdBhVKFPiFX-mi9s=.056aed18-ece0-4ef3-a5eb-87e27defb203@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 68 commits from the branch `master`that can **not** be merged into the branch `foreign-preview`: The following file contains merge conflicts: - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. # Ensure target branch is up to date $ git checkout foreign-preview $ git pull https://github.com/openjdk/panama-foreign.git foreign-preview # Fetch and checkout the branch for this pull request $ git fetch https://github.com/openjdk-bot/panama-foreign.git +116:openjdk-bot-116 $ git checkout openjdk-bot-116 # Merge the target branch $ git merge foreign-preview When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: $ git add paths/to/files/with/conflicts $ git commit -m 'Merge master' When you have created the merge commit, run the following command to push the merge commit to this pull request: $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-116:116 _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. Thanks, J. Duke ------------- Commit messages: - Automatic merge of jdk:master into master - 8282347: AARCH64: Untaken branch in has_negatives stub - 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use - 8280357: user.home = "?" when running with systemd DynamicUser=true - 8005885: enhance PrintCodeCache to print more data - 8281525: Enable Zc:strictStrings flag in Visual Studio build - 8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor - 8282348: Remove unused CardTable::dirty_card_iterate - 8277204: Implement PAC-RET branch protection on Linux/AArch64 - 8282316: Operation before String case conversion - ... and 58 more: https://git.openjdk.java.net/panama-foreign/compare/cd3b60d5...7e0ce62c The webrev contains the conflicts with foreign-preview: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=657&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/657/files Stats: 8056 lines in 192 files changed: 5290 ins; 1119 del; 1647 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/657.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/657/head:pull/657 PR: https://git.openjdk.java.net/panama-foreign/pull/657 From duke at openjdk.java.net Fri Feb 25 13:03:03 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 25 Feb 2022 13:03:03 GMT Subject: [foreign-preview] RFR: Merge master [v2] In-Reply-To: <0yIXTzywhdpECgGc16PS0HdRTCeXdBhVKFPiFX-mi9s=.056aed18-ece0-4ef3-a5eb-87e27defb203@github.com> References: <0yIXTzywhdpECgGc16PS0HdRTCeXdBhVKFPiFX-mi9s=.056aed18-ece0-4ef3-a5eb-87e27defb203@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 68 commits from the branch `master`that can **not** be merged into the branch `foreign-preview`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-preview > $ git pull https://github.com/openjdk/panama-foreign.git foreign-preview > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +116:openjdk-bot-116 > $ git checkout openjdk-bot-116 > > # Merge the target branch > $ git merge foreign-preview > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-116:116 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits: - Merge branch 'foreign-preview' into 116 - Automatic merge of jdk:master into master - 8282347: AARCH64: Untaken branch in has_negatives stub Reviewed-by: aph, haosun, thartmann - 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use Reviewed-by: msheppar, amenkov - 8280357: user.home = "?" when running with systemd DynamicUser=true Reviewed-by: naoto, alanb - 8005885: enhance PrintCodeCache to print more data Reviewed-by: xliu, phh - 8281525: Enable Zc:strictStrings flag in Visual Studio build Reviewed-by: dholmes, ihse - 8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor Reviewed-by: tschatzl, kbarrett - 8282348: Remove unused CardTable::dirty_card_iterate Reviewed-by: kbarrett - 8277204: Implement PAC-RET branch protection on Linux/AArch64 Reviewed-by: erikj, ihse, adinn, ngasson - ... and 59 more: https://git.openjdk.java.net/panama-foreign/compare/9247f980...9eb3b0b9 ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/657/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=657&range=01 Stats: 8055 lines in 192 files changed: 5290 ins; 1119 del; 1646 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/657.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/657/head:pull/657 PR: https://git.openjdk.java.net/panama-foreign/pull/657 From duke at openjdk.java.net Fri Feb 25 13:46:15 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 25 Feb 2022 13:46:15 GMT Subject: [foreign-preview] Integrated: Merge master In-Reply-To: <0yIXTzywhdpECgGc16PS0HdRTCeXdBhVKFPiFX-mi9s=.056aed18-ece0-4ef3-a5eb-87e27defb203@github.com> References: <0yIXTzywhdpECgGc16PS0HdRTCeXdBhVKFPiFX-mi9s=.056aed18-ece0-4ef3-a5eb-87e27defb203@github.com> Message-ID: On Fri, 25 Feb 2022 11:06:30 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 68 commits from the branch `master`that can **not** be merged into the branch `foreign-preview`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-preview > $ git pull https://github.com/openjdk/panama-foreign.git foreign-preview > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +116:openjdk-bot-116 > $ git checkout openjdk-bot-116 > > # Merge the target branch > $ git merge foreign-preview > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-116:116 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke This pull request has now been integrated. Changeset: 78d60e58 Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/78d60e58161ae65911a9a167e8fdc94564c02beb Stats: 8055 lines in 192 files changed: 5290 ins; 1119 del; 1646 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/657 From jbhateja at openjdk.java.net Fri Feb 25 16:33:43 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 25 Feb 2022 16:33:43 GMT Subject: [vectorIntrinsics] RFR: Post mainline merge fixes Message-ID: - Post-merge fixes. - Updating JMH micros post merge since some of the Perf templates are not part of mainline branch and depends on Unit-Test Kernels which may have been modified in mainline. - Fixing Long*VectorTests.java tests for X86 target. ------------- Commit messages: - Changing file permissions - Merge panama-vector:master fixes. Changes: https://git.openjdk.java.net/panama-vector/pull/175/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=175&range=00 Stats: 3282 lines in 37 files changed: 2585 ins; 336 del; 361 mod Patch: https://git.openjdk.java.net/panama-vector/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/175/head:pull/175 PR: https://git.openjdk.java.net/panama-vector/pull/175 From sviswanathan at openjdk.java.net Fri Feb 25 17:00:30 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 25 Feb 2022 17:00:30 GMT Subject: [vectorIntrinsics] RFR: Post mainline merge fixes In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 16:13:33 GMT, Jatin Bhateja wrote: > - Post-merge fixes. > - Updating JMH micros post merge since some of the Perf templates are not part of mainline branch and depends on Unit-Test Kernels which may have been modified in mainline. > - Fixing Long*VectorTests.java tests for X86 target. Marked as reviewed by sviswanathan (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/175 From jbhateja at openjdk.java.net Fri Feb 25 17:07:26 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 25 Feb 2022 17:07:26 GMT Subject: [vectorIntrinsics] Integrated: Post mainline merge fixes In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 16:13:33 GMT, Jatin Bhateja wrote: > - Post-merge fixes. > - Updating JMH micros post merge since some of the Perf templates are not part of mainline branch and depends on Unit-Test Kernels which may have been modified in mainline. > - Fixing Long*VectorTests.java tests for X86 target. This pull request has now been integrated. Changeset: 499efe63 Author: Jatin Bhateja URL: https://git.openjdk.java.net/panama-vector/commit/499efe6343780d3083099875c8a3d3d2f68534e3 Stats: 3282 lines in 37 files changed: 2585 ins; 336 del; 361 mod Post mainline merge fixes Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/175 From duke at openjdk.java.net Fri Feb 25 17:25:18 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 25 Feb 2022 17:25:18 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: <6qGdlRMYPmWgbKJzNCDl1fVhpjvfJDhT9FoYxgAsUuI=.6c43d268-f737-427e-92d9-2d91ad12fca1@github.com> References: <6qGdlRMYPmWgbKJzNCDl1fVhpjvfJDhT9FoYxgAsUuI=.6c43d268-f737-427e-92d9-2d91ad12fca1@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 68 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +115:openjdk-bot-115 > $ git checkout openjdk-bot-115 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-115:115 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits: - Merge branch 'foreign-memaccess+abi' into 115 - Automatic merge of jdk:master into master - 8282347: AARCH64: Untaken branch in has_negatives stub Reviewed-by: aph, haosun, thartmann - 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use Reviewed-by: msheppar, amenkov - 8280357: user.home = "?" when running with systemd DynamicUser=true Reviewed-by: naoto, alanb - 8005885: enhance PrintCodeCache to print more data Reviewed-by: xliu, phh - 8281525: Enable Zc:strictStrings flag in Visual Studio build Reviewed-by: dholmes, ihse - 8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor Reviewed-by: tschatzl, kbarrett - 8282348: Remove unused CardTable::dirty_card_iterate Reviewed-by: kbarrett - 8277204: Implement PAC-RET branch protection on Linux/AArch64 Reviewed-by: erikj, ihse, adinn, ngasson - ... and 59 more: https://git.openjdk.java.net/panama-foreign/compare/6af29ab1...a2f60d24 ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/656/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=656&range=01 Stats: 8056 lines in 192 files changed: 5290 ins; 1119 del; 1647 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/656.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/656/head:pull/656 PR: https://git.openjdk.java.net/panama-foreign/pull/656 From duke at openjdk.java.net Fri Feb 25 17:43:50 2022 From: duke at openjdk.java.net (J.Duke) Date: Fri, 25 Feb 2022 17:43:50 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: <6qGdlRMYPmWgbKJzNCDl1fVhpjvfJDhT9FoYxgAsUuI=.6c43d268-f737-427e-92d9-2d91ad12fca1@github.com> References: <6qGdlRMYPmWgbKJzNCDl1fVhpjvfJDhT9FoYxgAsUuI=.6c43d268-f737-427e-92d9-2d91ad12fca1@github.com> Message-ID: On Fri, 25 Feb 2022 11:06:01 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 68 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +115:openjdk-bot-115 > $ git checkout openjdk-bot-115 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-115:115 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke This pull request has now been integrated. Changeset: 3fcce092 Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/3fcce092349c77dccd26f5540116e1676590b9ad Stats: 8056 lines in 192 files changed: 5290 ins; 1119 del; 1647 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/656 From mcimadamore at openjdk.java.net Fri Feb 25 17:44:29 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 25 Feb 2022 17:44:29 GMT Subject: [foreign-preview] Integrated: 8282061: Improve support for deterministic closure of shared scopes In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 16:11:52 GMT, Maurizio Cimadamore wrote: > This patch improves the logic for closing shared resource scopes, by using the following algorithm: > > 1. move the scope from ALIVE to CLOSED - no new thread can access segments associated with the scope > 2. do an initial handshake, to collect all threads that are accessing the scope concurrently > 3. if no thread is found, finish > 4. if some threads T1, T2 ... Tn are found, keep doing handshakes (only against these threads) then go back to (3). > > Note that the logic no longer require *three* states for shared segment, and also this logic always succeeds - that is the close operation can never fail because of a spurious access found during an handshake. > > Note that the logic converges quickly, because handshaked threads are deoptimized - meaning that they will have to re-load the liveness state of the resource they are accessing (at which point they will just throw an exception). > > Implementation-wise, when looking over the code with @fisk , we realized that it is possible for multiple threads to run the handhshake closure concurrently. To collect all the problematic thread, we used a lock free stack (which was already implemented in the hotspot code). Also, to keep problematic threads alive during multiple rounds of handshaking, we use a ThreadHandleList (this is also required to be able to handshake on a specific thread). This pull request has now been integrated. Changeset: 5eec2e24 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/5eec2e24f4d15e3a7577fa27597f0a78f78f6d88 Stats: 96 lines in 6 files changed: 52 ins; 14 del; 30 mod 8282061: Improve support for deterministic closure of shared scopes Reviewed-by: psandoz, jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/643 From duke at openjdk.java.net Fri Feb 25 17:51:08 2022 From: duke at openjdk.java.net (duke) Date: Fri, 25 Feb 2022 17:51:08 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 70 new changesets Message-ID: <946f6bbd-3b18-44a4-9e62-8a5f00b615d1@openjdk.org> Changeset: e3365041 Author: Jan Lahoda Date: 2022-02-18 11:04:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3365041bdef4dc09f3e5967124103e4364614fb 8280866: SuppressWarnings does not work properly in package-info and module-info Reviewed-by: darcy, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java + test/langtools/tools/javac/warnings/suppress/SuppressWarningsPackage.java Changeset: f5120b76 Author: Pavel Rappo Date: 2022-02-18 13:09:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5120b764c6f84776e7ea335d7ff59b16f6496b0 8282056: Clean up com.sun.tools.javac.util.GraphUtils Reviewed-by: jjg, mcimadamore, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java Changeset: cf6984dd Author: Magnus Ihse Bursie Date: 2022-02-18 14:49:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf6984ddaa5668e78d590c8ad1f2aec0632f0b28 8282086: Update jib profile to not set build to 0 Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 413bef68 Author: Dmitry Chuyko Date: 2022-02-18 16:02:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/413bef6890e9ba820590aa48017c4c7b1d691d24 8282049: AArch64: Use ZR for integer zero immediate volatile stores Reviewed-by: adinn, phh ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: cfbfd9bf Author: Daniel D. Daugherty Date: 2022-02-18 16:25:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cfbfd9bf4123452e8bcff0ef7fbc18b14be8638c 8282103: fix macosx-generic typo in ProblemList Reviewed-by: rriggs ! test/hotspot/jtreg/ProblemList.txt Changeset: 7ce75afb Author: Weijun Wang Date: 2022-02-18 16:34:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ce75afbbcca7635356c7377be7ddff15335e563 8255266: Update Public Suffix List to 3c213aa Reviewed-by: xuelei ! make/data/publicsuffixlist/VERSION ! make/data/publicsuffixlist/public_suffix_list.dat ! src/java.base/share/legal/public_suffix.md ! test/jdk/sun/security/util/RegisteredDomain/ParseNames.java ! test/jdk/sun/security/util/RegisteredDomain/tests.dat Changeset: 3943c89b Author: Yudi Zheng Committer: Vladimir Kozlov Date: 2022-02-18 18:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3943c89b9b71d8c1fda3ba88fd833f08723202f0 8282044: [JVMCI] Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler. Reviewed-by: kvn ! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: d3749de4 Author: Rajan Halade Date: 2022-02-18 20:17:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d3749de47832c6de4bcee9cf64a0b698e796b2f2 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022 Reviewed-by: weijun ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: d7f31d0d Author: Valerie Peng Date: 2022-02-19 06:40:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7f31d0d53bfec627edc83ceb75fc6202891e186 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error Reviewed-by: mikael ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c Changeset: d28b048f Author: Aleksey Shipilev Date: 2022-02-21 06:14:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d28b048f35d5893187076e853a4a898d5ca8b220 8281815: x86: Use short jumps in TIG::generate_slow_signature_handler Reviewed-by: rrich, dholmes, jiefu ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp Changeset: 8563d86f Author: Tobias Hartmann Date: 2022-02-21 07:02:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8563d86f2cce0dc9d1411bf9276a00bca0515efd 8282085: The REGISTER_DEFINITION macro is useless after JDK-8269122 Reviewed-by: jiefu, chagedorn, kvn - src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp - src/hotspot/cpu/arm/register_definitions_arm.cpp - src/hotspot/cpu/ppc/register_definitions_ppc.cpp - src/hotspot/cpu/s390/register_definitions_s390.cpp - src/hotspot/cpu/x86/register_definitions_x86.cpp ! src/hotspot/share/asm/register.hpp Changeset: 4e0b81c5 Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-21 07:05:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319 8281544: assert(VM_Version::supports_avx512bw()) failed for Tests jdk/incubator/vector/ Reviewed-by: kvn, neliasso, thartmann ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp ! test/jdk/jdk/incubator/vector/VectorMaxConversionTests.java Changeset: 52a85d80 Author: John Jiang Date: 2022-02-21 07:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52a85d80483f7fefbe26bed6fe3a2ce4bd1bc9fc 8282158: ECParameters InvalidParameterSpecException messages missed ECKeySizeParameterSpec Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/util/ECParameters.java Changeset: c5d9142a Author: Albert Mingkun Yang Date: 2022-02-21 08:14:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5d9142a8466fe00819afb76ebe68dc59061613e 8282096: G1: Remove redundant checks in G1CardSet::free_mem_object Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1CardSet.cpp Changeset: 34aae32d Author: John Jiang Date: 2022-02-21 08:27:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/34aae32de6c1eeaf268d62f20152f831cca5cd29 8282166: JDK-8282158 changed ECParameters' package by accident Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/util/ECParameters.java Changeset: 51f44207 Author: Andrey Turbanov Date: 2022-02-21 09:03:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51f4420711b8cace5733180b3291779f11291895 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers Reviewed-by: bpb, alanb ! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template Changeset: bdae1d87 Author: Manukumar V S Committer: Abdul Kolarkunnu Date: 2022-02-21 10:08:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdae1d87c16423878e4dcc8a0e87806d77bb5256 8282147: [TESTBUG] waitForIdle after creating frame in JSpinnerMouseAndKeyPressTest.java Reviewed-by: aivanov ! test/jdk/javax/swing/JSpinner/4515999/JSpinnerMouseAndKeyPressTest.java Changeset: d7a706a5 Author: Magnus Ihse Bursie Date: 2022-02-21 10:37:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7a706a54076109b1a600a4d963df54b6d3f86de 8253757: Add LLVM-based backend for hsdis Co-authored-by: Magnus Ihse Bursie Co-authored-by: Ludovic Henry Co-authored-by: Jorn Vernee Co-authored-by: Nick Gasson Reviewed-by: erikj, luhenry ! make/Hsdis.gmk ! make/autoconf/jdk-options.m4 ! src/utils/hsdis/README.md + src/utils/hsdis/llvm/hsdis-llvm.cpp Changeset: cc7cf812 Author: Maxim Kartashev Committer: Anton Tarasov Date: 2022-02-21 11:39:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cc7cf81256ed4d74493472017b1c4df20fa2208a 8280861: Robot color picker broken on Linux with scaling above 100% Reviewed-by: serb ! src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.h ! test/jdk/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java + test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java ! test/jdk/javax/swing/JPasswordField/TestSelectedTextBackgroundColor.java ! test/jdk/javax/swing/JProgressBar/TestJProgressBarHighlightColor.java ! test/jdk/javax/swing/JSlider/TestJSliderRendering.java ! test/jdk/javax/swing/JSpinner/TestSelectedTextBackgroundColor.java ! test/jdk/javax/swing/JTextPane/TestJTextPaneBackgroundColor.java ! test/jdk/javax/swing/JToolTip/TestTooltipBackgroundColor.java Changeset: e1c98bd1 Author: Daniel Jeli?ski Committer: Alexey Ivanov Date: 2022-02-21 17:40:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1c98bd1f2f57ddf47e4660038059117af87f938 8281523: Accessibility: Conversion from string literal loses const qualifier Reviewed-by: prr, aivanov, kizune ! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp ! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.h ! src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeEventHandler.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeJavaVMInstance.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeMessageQueue.cpp ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp ! src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp ! src/jdk.accessibility/windows/native/toolscommon/AccessInfo.h Changeset: e0b49629 Author: Jaikiran Pai Date: 2022-02-22 01:39:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0b49629e95c98aabe8b75ec2f7528e7fb6dcffc 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle Reviewed-by: dfuchs, rriggs, lancea, iris ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java Changeset: f9539521 Author: Manukumar V S Committer: Abdul Kolarkunnu Date: 2022-02-22 07:31:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9539521aee71e84cb052d3d0444c58ee88930f7 8281745: Create a regression test for JDK-4514331 Reviewed-by: serb + test/jdk/javax/swing/JTextArea/4514331/TabShiftsFocusToNextComponent.java Changeset: bc43320f Author: Emanuel Peter Committer: Tobias Hartmann Date: 2022-02-22 07:55:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc43320fd32debf863f37dc00ef7b95589f576ed 8281543: Remove unused code/headerfile dtraceAttacher.hpp Reviewed-by: thartmann ! src/hotspot/os/aix/attachListener_aix.cpp ! src/hotspot/os/bsd/attachListener_bsd.cpp ! src/hotspot/os/linux/attachListener_linux.cpp ! src/hotspot/os/windows/attachListener_windows.cpp - src/hotspot/share/services/dtraceAttacher.hpp Changeset: b95310b0 Author: John Jiang Date: 2022-02-22 09:35:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b95310b0908037c6743b937ae43d7bc97e1fb770 8282220: contentType should not be a PKCS7's member Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/pkcs/PKCS7.java Changeset: ab6d8e64 Author: Alexey Ivanov Date: 2022-02-22 13:19:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab6d8e6424aa478eb7661d1d38d543cccd38888f 8260328: Drop redundant CSS properties from java.desktop HTML files Reviewed-by: serb, dmarkov ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html Changeset: 022d8070 Author: Coleen Phillimore Date: 2022-02-22 13:42:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/022d80707c346f4b82ac1eb53e77c634769631e9 8271008: appcds/*/MethodHandlesAsCollectorTest.java tests time out because of excessive GC (CodeCache GC Threshold) in loom Reviewed-by: thartmann, eosterlund ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/sweeper.hpp Changeset: 41355e2d Author: Ian Graves Date: 2022-02-22 15:38:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/41355e2daa43fa8433bf77ed187979c49d453f4a 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java Reviewed-by: iris, bpb, lancea ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: e44d0670 Author: Magnus Ihse Bursie Date: 2022-02-22 16:06:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e44d0670a69a641b82a0ca50e06e85d807b473ea 8244593: Clean up GNM/NM after JEP 381 Reviewed-by: erikj ! make/autoconf/compare.sh.in ! make/autoconf/spec.gmk.in ! make/autoconf/toolchain.m4 Changeset: 957dae02 Author: Thomas Schatzl Date: 2022-02-22 16:25:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/957dae02b18b150cab8aec4846bc82086ee1e4da 8280958: G1/Parallel: Unify marking code structure Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp Changeset: 3cb38678 Author: Ian Graves Date: 2022-02-22 16:31:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cb38678aa7f03356421f5a17c1de4156e206d68 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception Reviewed-by: naoto ! src/java.base/share/classes/java/util/regex/Pattern.java ! test/jdk/java/util/regex/RegExTest.java Changeset: 58e1882f Author: Tyler Steele Committer: Naoto Sato Date: 2022-02-22 16:50:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58e1882f3ccc648c5f6d216d37cfd1805889b8d8 8282042: [testbug] FileEncodingTest.java depends on default encoding Adds expected encoding "ISO-8859-1" for AIX in FileEncodingTest.java Reviewed-by: naoto ! test/jdk/java/lang/System/FileEncodingTest.java Changeset: 7feabee4 Author: liach Committer: Mandy Chung Date: 2022-02-22 16:57:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7feabee4265787ea820c1925c0c531933cb0da50 8261407: ReflectionFactory.checkInitted() is not thread-safe Co-authored-by: Peter Levart Reviewed-by: dholmes, mchung, plevart ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java Changeset: 6445ee46 Author: Brian Burkhalter Date: 2022-02-22 17:24:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6445ee46b5c3d1a46f8154b6e867c25d495d76b1 5041655: (ch) FileLock: negative param and overflow issues Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/java.base/share/classes/java/nio/channels/FileChannel.java ! src/java.base/share/classes/java/nio/channels/FileLock.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/jdk/java/nio/channels/FileChannel/Lock.java + test/jdk/java/nio/channels/FileLock/Overlaps.java Changeset: 2557ef8a Author: Phil Race Date: 2022-02-22 20:27:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2557ef8a02fe19784bd5e605b11d6bd574cde2c2 8282276: Problem list failing two Robot Screen Capture tests Reviewed-by: dcubed ! test/jdk/ProblemList.txt Changeset: 6f882ded Author: Phil Race Date: 2022-02-23 01:03:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f882deddcc094777b45f0dacc7351dbc23993a4 8280964: [Linux aarch64] : drawImage dithers TYPE_BYTE_INDEXED images incorrectly Reviewed-by: serb, dmarkov ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.c ! src/java.desktop/share/native/libawt/awt/image/cvutils/img_globals.h ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/loops/ByteIndexed.h ! src/java.desktop/share/native/libawt/java2d/loops/UshortIndexed.h ! src/java.desktop/unix/native/common/awt/colordata.h ! src/java.desktop/windows/native/libawt/windows/colordata.h + test/jdk/java/awt/image/DrawImage/ByteIndexedDitherTest.java Changeset: e1060bee Author: Zhengyu Gu Date: 2022-02-23 03:04:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1060bee2adb9f2e07ca09309d0f89132db30f28 8281615: Deadlock caused by jdwp agent Reviewed-by: dholmes, cjplummer ! src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c Changeset: 378fa507 Author: Volker Simonis Date: 2022-02-23 08:36:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/378fa507a29f382e5534226612e154a37618ab91 8281962: Avoid unnecessary native calls in InflaterInputStream Reviewed-by: clanger, redestad, alanb, lancea ! src/java.base/share/classes/java/util/zip/InflaterInputStream.java + test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java Changeset: ecd85e6f Author: Andrew Haley Date: 2022-02-23 10:15:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ecd85e6f0f8906ad1e8aa0a53bf499e8c969ba73 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts registers Reviewed-by: shade, jiefu ! src/hotspot/cpu/x86/x86_32.ad Changeset: 93320717 Author: Vladimir Ivanov Date: 2022-02-23 10:17:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9332071784b7150512f7e27b07c290a356d43c2e 8282194: C1: Missing side effects of dynamic constant linkage Reviewed-by: kvn, thartmann ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_ValueMap.hpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/ci/ciStreams.hpp Changeset: d017e988 Author: David Holmes Date: 2022-02-23 11:30:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d017e988562999295315778e232d71e477afb407 8255577: Possible issues with SR_initialize Reviewed-by: shade, stuefe ! src/hotspot/os/posix/signals_posix.cpp Changeset: aaab2cb4 Author: Aleksey Shipilev Date: 2022-02-23 12:34:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aaab2cb41666af8520fd01de70e2c4f9c87ef5fd 8282225: GHA: Allow one concurrent run per PR only Reviewed-by: ihse ! .github/workflows/submit.yml Changeset: 5035bf5e Author: Nils Eliasson Date: 2022-02-23 12:48:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5035bf5e6cb0ae2892e128b9a7c4014d01addb26 8282208: Reduce MachNode size Reviewed-by: kvn, thartmann, jiefu ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/node.hpp Changeset: 340a35d8 Author: Xue-Lei Andrew Fan Date: 2022-02-23 15:43:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/340a35d8358456620954ae0c668cf3d1d617bb88 8282279: Interpret case-insensitive string locale independently Reviewed-by: weijun ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java ! src/java.base/share/classes/sun/security/util/TlsChannelBinding.java Changeset: 35076af1 Author: Pavel Rappo Date: 2022-02-23 16:17:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35076af13acd1b9327d35ac67dc80c15bb1059c7 8281376: Consider polymorphic methods when looking for overrides Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java + test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg8/C.java + test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg8/GP.java + test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg8/P.java Changeset: 99b8ed9d Author: Jonathan Gibbons Date: 2022-02-23 16:49:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99b8ed9dbf88e21a42a8d2f6249bfab7176e7d42 8281217: Source file launch with security manager enabled fails Reviewed-by: sundar ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: a020b6ba Author: Lance Andersen Date: 2022-02-23 16:56:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a020b6ba8f38fe85fb26972a51e4c1068408b1c1 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() Reviewed-by: mullan, alanb ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/zip/ZipFile.java + test/jdk/java/util/zip/ZipFile/GetInputStreamNPETest.java Changeset: 7dc7184c Author: Xue-Lei Andrew Fan Date: 2022-02-23 18:32:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7dc7184c10fc8f7a02113056da979a9846a14cd4 8282309: Operation before upper case conversion Reviewed-by: valeriep, wetmore ! src/java.base/share/classes/sun/security/util/TlsChannelBinding.java Changeset: e540e0a8 Author: Michael McMahon Date: 2022-02-23 20:02:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e540e0a81b923cce8b2f2689e01703509a4df1de 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) Reviewed-by: dfuchs, lancea, bpb ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java Changeset: f86f38a8 Author: Vladimir Ivanov Date: 2022-02-23 20:29:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f86f38a8afd31c76039206f8f1f33371ad814396 8280901: MethodHandle::linkToNative stub is missing w/ -Xint Reviewed-by: shade, kvn ! src/hotspot/share/classfile/systemDictionary.cpp ! test/jdk/java/foreign/TestDowncall.java Changeset: 253cf785 Author: Chris Plummer Date: 2022-02-23 21:09:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/253cf7852f60ecf92e6d675ae2469e5f27425609 8282076: Merge some debug agent changes from the loom repo Reviewed-by: amenkov, lmesnik ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ! src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c Changeset: 43dc9ef6 Author: Manukumar V S Committer: Alexey Ivanov Date: 2022-02-23 21:13:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/43dc9ef619b823e033cb1e298bbc091eb5a50967 8281988: Create a regression test for JDK-4618767 Reviewed-by: aivanov + test/jdk/javax/swing/JList/4618767/JListSelectedElementTest.java Changeset: a6610031 Author: Chris Plummer Date: 2022-02-23 22:55:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6610031e2816156fa14876457e260282a88d478 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr Reviewed-by: dcubed, dholmes ! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java Changeset: cd3e59ef Author: Albert Mingkun Yang Date: 2022-02-24 09:16:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd3e59ef88bcc040f9d671c8c15370efaae3ffd8 8282299: Remove unused PartialArrayScanTask default constructor Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp Changeset: 379fd859 Author: Prasanta Sadhukhan Date: 2022-02-24 09:52:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/379fd85932e4b82e9a8e85f8ed8e63202f3cb9bc 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT orientation, arrow keys behaves opposite traversing through keyboard Reviewed-by: prr, naoto, serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java + test/jdk/javax/swing/JMenuBar/MenuBarRTLBug.java Changeset: 3cfffa4f Author: Andrey Turbanov Date: 2022-02-24 11:03:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cfffa4f8e5a0fff7f232130125c549f992b533b 8282188: Unused static field MathContext.DEFAULT_DIGITS Reviewed-by: darcy, bpb ! src/java.base/share/classes/java/math/MathContext.java Changeset: f4486a19 Author: Coleen Phillimore Date: 2022-02-24 12:59:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4486a190e38c57b7c10e6cff4622bd1b716a724 8262400: runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails in test_ame5_compiled_vtable_stub with wrapper Reviewed-by: dholmes, lmesnik ! test/hotspot/jtreg/runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java Changeset: 231e48fa Author: Johannes Bechberger Committer: Martin Doerr Date: 2022-02-24 14:32:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/231e48fa63aeb4e35c7c948f958695d62b7157ce 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 Reviewed-by: dholmes, mdoerr, kevinw ! src/hotspot/share/prims/forte.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 0796620b Author: Jonathan Gibbons Date: 2022-02-24 14:50:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0796620b07c6287a130ab0a3a7279d69b5d7b8a1 8281944: JavaDoc throws java.lang.IllegalStateException: ERRONEOUS Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java Changeset: abc0ce11 Author: Xue-Lei Andrew Fan Date: 2022-02-24 16:25:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abc0ce11dfa0a751a12925763cb168d1d3b4f44a 8282316: Operation before String case conversion Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/util/SignatureUtil.java Changeset: 6fab8a2d Author: Alan Hayward Committer: Andrew Dinn Date: 2022-02-24 16:38:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6fab8a2d6a97dbd2ffceca275716d020cb9f1eea 8277204: Implement PAC-RET branch protection on Linux/AArch64 Reviewed-by: erikj, ihse, adinn, ngasson ! doc/building.md ! make/autoconf/flags-cflags.m4 ! make/autoconf/spec.gmk.in ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/pauth_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp ! src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/pauth_linux_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/pauth_windows_aarch64.inline.hpp ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/java.base/share/man/java.1 ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.aarch64/src/jdk/vm/ci/aarch64/AArch64.java ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/CodeInstallationTest.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestHotSpotVMConfig.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/aarch64/AArch64TestAssembler.java Changeset: 0b6862e8 Author: Albert Mingkun Yang Date: 2022-02-24 17:47:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b6862e803a03cf7f722f4f58b657712e74723fb 8282348: Remove unused CardTable::dirty_card_iterate Reviewed-by: kbarrett ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp Changeset: 20e78f7a Author: Albert Mingkun Yang Date: 2022-02-24 17:48:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20e78f7a8e2e589bc4fb7f0c928176048bd9172a 8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 23995f82 Author: Daniel Jeli?ski Committer: Daniel Fuchs Date: 2022-02-24 18:18:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23995f822e540d799eb4bbc969229422257fbb08 8281525: Enable Zc:strictStrings flag in Visual Studio build Reviewed-by: dholmes, ihse ! make/autoconf/flags-cflags.m4 ! src/hotspot/os/windows/os_windows.cpp ! src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp ! src/jdk.jpackage/windows/native/libwixhelper/libwixhelper.cpp ! test/hotspot/gtest/runtime/test_os_windows.cpp Changeset: b6843a16 Author: Yi-Fan Tsai Committer: Paul Hohensee Date: 2022-02-24 19:42:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6843a162411b0fa32271592d8f3a6f241a54384 8005885: enhance PrintCodeCache to print more data Reviewed-by: xliu, phh ! src/hotspot/share/code/codeCache.cpp + test/hotspot/jtreg/compiler/codecache/CheckCodeCacheInfo.java Changeset: bf19fc65 Author: Roger Riggs Date: 2022-02-24 20:12:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf19fc65c71cba8cb4383d714fe8993acd01be0a 8280357: user.home = "?" when running with systemd DynamicUser=true Reviewed-by: naoto, alanb ! src/java.base/unix/native/libjava/java_props_md.c Changeset: cd36be42 Author: Kevin Walls Date: 2022-02-25 07:56:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd36be42c2eb3eacdb3625e87510eb15acac3230 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use Reviewed-by: msheppar, amenkov ! test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java Changeset: 3efd6aa4 Author: Claes Redestad Date: 2022-02-25 08:55:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3efd6aa4c9b6420520709281ab1ca46ba4242c87 8282347: AARCH64: Untaken branch in has_negatives stub Reviewed-by: aph, haosun, thartmann ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 7e0ce62c Author: duke Date: 2022-02-25 11:05:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e0ce62cba9dc45534bbdba8bd82ad804cb8b13c Automatic merge of jdk:master into master Changeset: 3fcce092 Author: J. Duke Committer: Jorn Vernee Date: 2022-02-25 17:40:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3fcce092349c77dccd26f5540116e1676590b9ad Merge master ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/share/code/codeCache.cpp ! test/jdk/ProblemList.txt ! test/jdk/java/foreign/TestDowncall.java ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/share/code/codeCache.cpp ! test/jdk/ProblemList.txt ! test/jdk/java/foreign/TestDowncall.java Changeset: dd37acba Author: duke Date: 2022-02-25 17:41:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd37acba057eaecfa928dd9ac9d010569edc8c4a Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js From duke at openjdk.java.net Fri Feb 25 19:05:41 2022 From: duke at openjdk.java.net (Swati Sharma) Date: Fri, 25 Feb 2022 19:05:41 GMT Subject: [vectorIntrinsics] RFR: 8282389: Add new vector operations to count leading and trailing zeros. Message-ID: Hi All, Added support for new vector operations CLZ (count number of leading zeros) and CTZ (could number of trailing zeros) for all the integral vector types(Byte/Short/Integer/Long). Added validation and performance tests corresponding the these operations in existing VectorAPI JTREG/JMH suite. Kindly review and share your feedback. Thanks and Regards, Swati Sharma Intel ------------- Commit messages: - 8282389: Add new vector operations to count leading and trailing zeros. Changes: https://git.openjdk.java.net/panama-vector/pull/176/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=176&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282389 Stats: 3937 lines in 80 files changed: 3926 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/176.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/176/head:pull/176 PR: https://git.openjdk.java.net/panama-vector/pull/176 From notzed at gmail.com Fri Feb 25 22:11:16 2022 From: notzed at gmail.com (Michael Zucchi) Date: Sat, 26 Feb 2022 08:41:16 +1030 Subject: musinig on close actions In-Reply-To: <5903b39a-b728-253f-63d7-9d0edcbbc69c@oracle.com> References: <5903b39a-b728-253f-63d7-9d0edcbbc69c@oracle.com> Message-ID: Morning Maurizio, FWIW I've been busy with summer of late and taking a break from this stuff.? And as a result I haven't yet explored the previously discussed ideas fully so my comments might not be worth a lot. But my initial thought on this is 'looks like it should work but it seems a bit over-engineered'. I guess my overall feeling on scopes is that they're "almost right" but one always seems to end up hitting cases that don't match how they operate and this just seems to be another special casing of one of those.? I can see in general the problem is difficult due to java vs native lifecycle differences.? Even where Java has existing explicit close such as with AutoClosable and Closeable there are implementation complexities, mostly due to those also being native resources. I did have some thoughts on a problem related to the nested-ish-scopes of opencl and vulkan, but I didn't get around to fleshing them out enough to articulate it properly.? Like it would be nice to have some sort of ligtweight/threaded/nested scope that could apply to individual or small groups of objects, but i vaguely remember scopes used to work like a bit like this initially but it got changed due to complexity and/or inflexibility.? But again this seems like another case of impedance mismatch with the resourcescope as-it-is-currently-defined. Regards, ?Michael On 19/2/22 05:56, Maurizio Cimadamore wrote: > Hi, > I wanted to capture some thoughts on scope close actions, which > originated from the good discussions we had in [1]. > > Basically, the status quo is that a close action is called _after_ the > scope is closed. This is a forced move: when we execute the close > action, we already have determined that e.g. the scope is not accessed > by any other thread. If resources were still accessible by close > actions, then closing a scope would not be safe (as they could be > leaked to other threads). > > There is a minor inconvenience with this approach: if a close action > needs to refer to some of the resources associated with the scope > (e.g. a segment), the action needs to work on the resource using its > memory address, thus losing safety and also expressiveness (e.g. to > use var handles you need a memory segment). This was the issue pointed > out in [1] with the FFmpeg API. There are other situations in which > working on segments, rather than addresses, might be preferrable: for > instance, one can come up with an API which turns an heap segment into > an off-heap segment, inside a given scope (e.g. pinning). In certain > cases where pinning is not supported directly by the GC, it might be > required to copy the contents of the native segment back to the > on-heap segment once the scope is closed. But if the segment is not > alive after close, there's no way to do the copy. > > I've been toying with an idea, which builds upon the following two > observations: > > 1. Resource-specific close actions are likely to arise when using the > `MemorySegment::ofAddress` methods (or any of the `XYZ::ofAddress` > factories) > > 2. A close action could safely operate on a *view* of the half-alive > resource based on a "closingScope" which is confined on the thread > that does the closing > > The API move that I have in mind is this: let's assume that we added > an overload to `MemorySegment`, as follows: > > ``` > static MemorySegment ofAddress(MemoryAddress addr, long size, > MemorySession session, Consumer cleanupAction) > ``` > > Which can be used as follows: > > ``` > MemoryAddress addr = .... > MemorySegment segment = MemorySegment.ofAddress(addr, 10L, session, > ???????????????? segmentView -> println(segmentView.get(JAVA_DOUBLE, > offset))); > ``` > > How does this work? After a scope transitions into the closed state, > but _before_ cleanup actions are called, the scope would spawn a _new_ > _confined_ scope, owned by the thread from which cleanup action are > called. That scope is then used to create resource views that will be > passed to the close actions. The new session is then closed after > _all_ the close actions have been executed. > Crucially, since all views are confined and cannot? be accessed after > `MemorySession::close()` completes, this works out ok safety-wise, I > believe. In a way, this is a restricted form of safe handoff of a > resource, from one scope to another. This allows clients to express > close actions at the right level of abstraction, without the need to > give up safety/expressiveness and drop down to `MemoryAddress`. > > Please note that I'm not proposing to drop support for "global" close > actions (e.g. the `MemorySession::addCloseAction` method). These are > still useful in many cases, as we've seen for pooled allocators [2]. > So the above mechanism would be an addition to the API, rather than a > replacement (and one that can also be considered at a later point, if > needs be). > > Any thoughts on whether something like this could help? > > Cheers > Maurizio > > [1] - > https://mail.openjdk.java.net/pipermail/panama-dev/2022-February/016173.html > [2] - https://github.com/openjdk/panama-foreign/pull/509 From jbhateja at openjdk.java.net Mon Feb 28 08:20:07 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 28 Feb 2022 08:20:07 GMT Subject: [vectorIntrinsics] RFR: 8282389: Add new vector operations to count leading and trailing zeros. In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 18:59:34 GMT, Swati Sharma wrote: > Hi All, > > Added support for new vector operations CLZ (count number of leading zeros) and CTZ (could number of trailing zeros) for all the integral vector types(Byte/Short/Integer/Long). > Added validation and performance tests corresponding the these operations in existing VectorAPI JTREG/JMH suite. > > Kindly review and share your feedback. > > Thanks and Regards, > Swati Sharma > Intel LGTM. ------------- Marked as reviewed by jbhateja (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/176 From eliu at openjdk.java.net Mon Feb 28 09:09:07 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 28 Feb 2022 09:09:07 GMT Subject: [vectorIntrinsics] RFR: 8282389: Add new vector operations to count leading and trailing zeros. In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 18:59:34 GMT, Swati Sharma wrote: > Hi All, > > Added support for new vector operations CLZ (count number of leading zeros) and CTZ (could number of trailing zeros) for all the integral vector types(Byte/Short/Integer/Long). > Added validation and performance tests corresponding the these operations in existing VectorAPI JTREG/JMH suite. > > Kindly review and share your feedback. > > Thanks and Regards, > Swati Sharma > Intel src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java line 1632: > 1630: > 1631: > 1632: Please remove these lines. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/176 From xgong at openjdk.java.net Mon Feb 28 09:19:02 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 28 Feb 2022 09:19:02 GMT Subject: [vectorIntrinsics] RFR: 8282389: Add new vector operations to count leading and trailing zeros. In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 18:59:34 GMT, Swati Sharma wrote: > Hi All, > > Added support for new vector operations CLZ (count number of leading zeros) and CTZ (could number of trailing zeros) for all the integral vector types(Byte/Short/Integer/Long). > Added validation and performance tests corresponding the these operations in existing VectorAPI JTREG/JMH suite. > > Kindly review and share your feedback. > > Thanks and Regards, > Swati Sharma > Intel Could you please update the copyright year to "2022" for all the modified files? Thanks! src/hotspot/share/prims/vectorSupport.hpp line 59: > 57: VECTOR_OP_BIT_COUNT = 3, > 58: VECTOR_OP_CTZ = 29, > 59: VECTOR_OP_CLZ = 30, Seems weird, could you please either move these two to the end of this enum or set the number to "4, 5"? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 1798: > 1796: > 1797: static int numberOfTrailingZeros(byte a) { > 1798: return a != 0 ? Integer.numberOfTrailingZeros(a) : 8; Integer.numberOfTrailingZeros((int)a & 0xFF) ? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/176 From xgong at openjdk.java.net Mon Feb 28 09:28:17 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 28 Feb 2022 09:28:17 GMT Subject: [vectorIntrinsics] RFR: 8282389: Add new vector operations to count leading and trailing zeros. In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 18:59:34 GMT, Swati Sharma wrote: > Hi All, > > Added support for new vector operations CLZ (count number of leading zeros) and CTZ (could number of trailing zeros) for all the integral vector types(Byte/Short/Integer/Long). > Added validation and performance tests corresponding the these operations in existing VectorAPI JTREG/JMH suite. > > Kindly review and share your feedback. > > Thanks and Regards, > Swati Sharma > Intel test/jdk/jdk/incubator/vector/Byte128VectorTests.java line 5323: > 5321: > 5322: static byte CTZ(byte a) { > 5323: return (byte)(CTZ_scalar(a)); Why not directly `return (byte) (a != 0 ? Integer.numberOfTrailingZeros(a) : 8);` in this method? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/176 From psandoz at openjdk.java.net Mon Feb 28 21:37:02 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 28 Feb 2022 21:37:02 GMT Subject: [vectorIntrinsics] RFR: 8282389: Add new vector operations to count leading and trailing zeros. In-Reply-To: References: Message-ID: <8EcJ7rrmIKl_PPK79QgA30h1pl5-ZoFnGMCb_AdrRt4=.8c4feafc-98b4-423a-80cb-c3d7f806a7de@github.com> On Fri, 25 Feb 2022 18:59:34 GMT, Swati Sharma wrote: > Hi All, > > Added support for new vector operations CLZ (count number of leading zeros) and CTZ (could number of trailing zeros) for all the integral vector types(Byte/Short/Integer/Long). > Added validation and performance tests corresponding the these operations in existing VectorAPI JTREG/JMH suite. > > Kindly review and share your feedback. > > Thanks and Regards, > Swati Sharma > Intel src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 456: > 454: public static final Unary BIT_COUNT = unary("BIT_COUNT", "bitCount", VectorSupport.VECTOR_OP_BIT_COUNT, VO_NOFP); > 455: /** Produce {@code numberOfTrailingZeros(a)} */ > 456: public static final Unary CTZ = unary("CTZ", "numberOfTrailingZeros", VectorSupport.VECTOR_OP_CTZ, VO_NOFP); I think we should be more verbose in the names, as they will not be well understood by developers. Specifically `TRAILING_ZEROS_COUNT` and `LEADING_ZEROS_COUNT`, and be consistent in other places. Internally we could shorten to `VECTOR_OP_TZ_COUNT` etc. to reduce the horizontal width. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/176